[OE-core] Patchwork & patch handling improvements

Wed Dec 2 10:59:17 UTC 2015

On 02/12/2015 10:54, "openembedded-core-bounces at lists.openembedded.org on
behalf of Barros Pena, Belen"
<openembedded-core-bounces at lists.openembedded.org on behalf of
belen.barros.pena at intel.com> wrote:

>
>
>On 02/12/2015 08:17, "openembedded-core-bounces at lists.openembedded.org on
>behalf of Martin Jansa" <openembedded-core-bounces at lists.openembedded.org
>on behalf of martin.jansa at gmail.com> wrote:
>
>>On Wed, Dec 02, 2015 at 04:01:40PM +1300, Paul Eggleton wrote:
>>> On Tue, 01 Dec 2015 11:47:20 Martin Jansa wrote:
>>> > On Tue, Dec 01, 2015 at 07:49:50AM +1300, Paul Eggleton wrote:
>>> > > Hi Trevor,
>>> > > 
>>> > > On Mon, 30 Nov 2015 10:19:35 Trevor Woerner wrote:
>>> > > > On 11/26/15 16:00, Paul Eggleton wrote:
>>> > > > > I'm also
>>> > > > > trying to ensure that the patch validation is generic enough so
>>>it can
>>> > > > > live in OE-Core, and thus we can easily update and refine it
>>>over time
>>> > > > > in
>>> > > > > line with the code itself as well as encourage submitters to
>>>use the
>>> > > > > script on their own changes before sending.
>>> > > > 
>>> > > > This all sounds like an improvement and is therefore a step in
>>>the right
>>> > > > direction :-)
>>> > > > 
>>> > > > A while back I had the idea of "porting" the kernel's
>>>"checkpatch.pl" to
>>> > > > The Yocto Project (it was around the same time that I was trying
>>>to
>>> > > > float the whole "Maintainers File" idea too, since I was also
>>>trying to
>>> > > > re-purpose "get-maintainer.pl" as well). About one minute into
>>>that
>>> > > > effort I realized the existing *.bb files were all over the place
>>>in
>>> > > > 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,
>>>and
>>> > > > another one from The Yocto Project, each of which described a
>>>slightly
>>> > > > 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
>>>there's
>>> > > > the potential for feathers to be ruffled on both sides if someone
>>>tries
>>> > > > to produce a definitive style guide for recipe files and then
>>>enforces
>>> > > > it in an automated way. Since it is the OpenEmbedded Project's
>>>job to
>>> > > > provide the recipes for The Yocto Project, I'm guessing this
>>>question
>>> > > > needs to be decided by them? If that sounds reasonable, then
>>>maybe The
>>> > > > 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
>>>was
>>> > > you
>>> > > that raised it at the time but the issue of having two style guides
>>>did
>>> > > get
>>> > > rectified - I changed the one on the Yocto Project wiki to simply
>>>be a
>>> > > link to the OE style guide in June last year. It certainly didn't
>>>come
>>> > > about through a conscious decision to have a different style.
>>> > > 
>>> > > However there is a minor disagreement over indentation for shell
>>>functions
>>> > > between OE-Core and other layers - this persists because of the
>>> > > backporting
>>> > > pain a blanket replacement would potentially lead to. As I recall
>>>this did
>>> > > get discussed at the OE TSC level. I think that's one thing we
>>>could just
>>> > > not evaluate (or make an option) until such time as we resolve the
>>> > > difference - and I do mean to see it resolved at some point in the
>>> > > future.
>>> > 
>>> > Using consistent indentation (4 spaces) at least for new metadata
>>>would
>>> > be step in right direction.
>>> > 
>>> > With the amount of changes which are backported to older releases I
>>> > still don't see this "backporting pain" argument. Doing it just
>>>before
>>> > the release is of course useful, because e.g. now more changes will
>>>be
>>> > backported to Jethro than to Fido or Dizzy. So having consistent
>>> > indentation in Jethro and master would prevent 95% of "backporting
>>> > pain". Maybe some Yocto 10.0 will finally get the meaning of
>>> > "consistent" indentation.
>>> 
>>> I agree it's not ideal. I said above, I do want to see it resolved.
>>> 
>>> Leaving indentation aside for a moment do you have any comments on my
>>> proposal?
>>
>>I'm not familiar with FDO fork, so I don't know how it looks and
>>behaves,
>
>This is how it looks like currently
>
>http://patchwork.freedesktop.org/project/intel-gfx/patches/
>
>> but any improvement on patchwork side is definitely welcome and
>>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?
>
>Mmm, you might not like this, but we are thinking of getting rid of
>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

sorry: pressed 'send' too soon :/ As I was saying, tagging

https://github.com/dlespiau/patchwork/issues/36

Or supporting several projects within the same mailing list (in your case,
one per layer)

https://github.com/dlespiau/patchwork/issues/77

>
>
>>
>>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

I don't know, but I can find out.

>>including bundles

If we remove the bundles, then I guess the migration might not keep the
bundles. 

Belén

>>as they are or do you
>>plan to set FDO version in parallel at least for some transition period?
>>Currently I have many patches in flight, because jenkins is running full
>>test-dependencies job for last 11 and based on progress it will take
>>14-21 more days to finish.
>>
>>Regards,
>>
>>-- 
>>Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>
>-- 
>_______________________________________________
>Openembedded-core mailing list
>Openembedded-core at lists.openembedded.org
>http://lists.openembedded.org/mailman/listinfo/openembedded-core