Re: Patchwork & patch handling improvements

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 6933 bytes --]

On Wed, Dec 02, 2015 at 10:59:17AM +0000, Barros Pena, Belen wrote:
> 
> 
> On 02/12/2015 10:54, "openembedded-core-bounces@lists.openembedded.org on
> behalf of Barros Pena, Belen"
> <openembedded-core-bounces@lists.openembedded.org on behalf of
> belen.barros.pena@intel.com> wrote:
> 
> >
> >
> >On 02/12/2015 08:17, "openembedded-core-bounces@lists.openembedded.org on
> >behalf of Martin Jansa" <openembedded-core-bounces@lists.openembedded.org
> >on behalf of martin.jansa@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. 

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.

Regards,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]