On Wed, Dec 02, 2015 at 10:59:17AM +0000, Barros Pena, Belen wrote:
On 02/12/2015 10:54, "openembedded-core-bounces@... on
behalf of Barros Pena, Belen"
<openembedded-core-bounces@... on behalf of
sorry: pressed 'send' too soon :/ As I was saying, tagging
On 02/12/2015 08:17, "openembedded-core-bounces@... on
behalf of Martin Jansa" <openembedded-core-bounces@...
on behalf of martin.jansa@...> wrote:
On Wed, Dec 02, 2015 at 04:01:40PM +1300, Paul Eggleton wrote:This is how it looks like currently
On Tue, 01 Dec 2015 11:47:20 Martin Jansa wrote:I'm not familiar with FDO fork, so I don't know how it looks and
On Tue, Dec 01, 2015 at 07:49:50AM +1300, Paul Eggleton wrote:it can
On Mon, 30 Nov 2015 10:19:35 Trevor Woerner wrote:
On 11/26/15 16:00, Paul Eggleton wrote:
trying to ensure that the patch validation is generic enough so
live in OE-Core, and thus we can easily update and refine it
line with the code itself as well as encourage submitters to
script on their own changes before sending.This all sounds like an improvement and is therefore a step in
A while back I had the idea of "porting" the kernel's
The Yocto Project (it was around the same time that I was trying
float the whole "Maintainers File" idea too, since I was also
re-purpose "get-maintainer.pl" as well). About one minute into
effort I realized the existing *.bb files were all over the place
terms of the order of statements and the order of the blocks of
statements. At that time I found one recipe style guide from OE,
another one from The Yocto Project, each of which described a
different preference. So I asked on the mailing list and quickly
discovered that both groups prefer a different style.
I'm not saying this job isn't worth doing, but I am pointing out
the potential for feathers to be ruffled on both sides if someone
to produce a definitive style guide for recipe files and then
it in an automated way. Since it is the OpenEmbedded Project's
provide the recipes for The Yocto Project, I'm guessing this
needs to be decided by them? If that sounds reasonable, then
Yocto Project needs to acquiesce to OE's decision?I don't think there's that much of a division. I don't recall if it
that raised it at the time but the issue of having two style guides
rectified - I changed the one on the Yocto Project wiki to simply
link to the OE style guide in June last year. It certainly didn't
about through a conscious decision to have a different style.
However there is a minor disagreement over indentation for shell
between OE-Core and other layers - this persists because of the
pain a blanket replacement would potentially lead to. As I recall
get discussed at the OE TSC level. I think that's one thing we
not evaluate (or make an option) until such time as we resolve theUsing consistent indentation (4 spaces) at least for new metadata
difference - and I do mean to see it resolved at some point in the
be step in right direction.before
With the amount of changes which are backported to older releases I
still don't see this "backporting pain" argument. Doing it just
the release is of course useful, because e.g. now more changes willbe
backported to Jethro than to Fido or Dizzy. So having consistentI agree it's not ideal. I said above, I do want to see it resolved.
indentation in Jethro and master would prevent 95% of "backporting
pain". Maybe some Yocto 10.0 will finally get the meaning of
Leaving indentation aside for a moment do you have any comments on my
but any improvement on patchwork side is definitely welcome andMmm, you might not like this, but we are thinking of getting rid of
I appreciate it.
Does it support e.g. moving the patches to given bundle based on some
substring in subject? To sort e.g. meta-networking, meta-java,
meta-browser, .. patches automatically?
bundles. Basically, we assumed bundles were a manual way of creating patch
series. The new Patchwork can identify series, so we thought: great!
Bundles no longer needed.
There are other features been considered that might be an alternative to
bundles, like tagging
Or supporting several projects within the same mailing list (in your case,
one per layer)
I don't know, but I can find out.
I don't expect FDO fork to provide other features I'm used to from
gerrit like cherry-picking to selected branch from the UI or doing the
review there. But still if we're stuck with patchwork forever (because
some people hate gerrit), then any improvement is really appreciated,
thanks for looking into it.
My only concern is about migrating current database, do you know if the
migration will keep the database
If we remove the bundles, then I guess the migration might not keep the
OK, then can we please postpone this upgrade (or run both patchworks in
parallel) until these 2 features are implemented and working?
I'm depending on bundles heavily, to "mark" the patches for layers with
dedicated maintainer and also for extra "status" like merged in
"master-next" branch for jenkins build, because standard status values
aren't fine-grained enough.
Martin 'JaMa' Jansa jabber: Martin.Jansa@...