Patchwork & patch handling improvements

Patchwork & patch handling improvements

[Paul Eggleton]

Hi all,

Over the past several years one of the regular complaints people have made 
about our project has been that patches sometimes take a long time to make it 
into master, and it's not always clear what the state of a patch is during 
that time. On the other side of things, maintainers are finding it increasingly 
hard to keep up with testing and integrating incoming patches. Additionally, 
trivial mistakes sometimes creep in that would be fairly easy to catch with an 
automated process. We've been talking about this for a while and now I'd like 
to propose a plan to finally address this:

1) Upgrade the OE Patchwork instance [0] to a newer release; this should fix 
some of the problems we are having [1] plus give us additional features. I 
propose using the fork that freedesktop.org are using [2] [3] which is moving 
a bit faster than upstream Patchwork; whilst the changes there may eventually 
make it upstream (and work is ongoing there) we have a much greater ability to 
influence the fork given that it's being worked on by one of my colleagues who 
is pushing it in the direction we need it to go e.g. proper support for series 
as opposed to treating every patch individually, improved UI, etc.

2) Trigger automatic testing of submitted patches from Patchwork. We'd have a 
script look at the contents of a patch and first check that the expected style 
has been adhered to; second it would do some quick tests to verify that the 
patch hasn't caused any immediately obvious regressions. I've filed some bugs 
to cover this in more detail [4].

3) Provide a means to easily schedule an overnight build on the autobuilder 
for the set of patches that have passed the initial testing, as well as 
present the results in a form that's easier to review for maintainers. For OE-
Core this would be tied into the Yocto Project autobuilder, but I expect the 
tools could be made flexible.

At all stages through this process the patch status in patchwork will be kept 
up-to-date so it's clear to everyone what's happening. I'm also thinking we 
could do email notifications to the submitter (opt-in) though that would be a 
later add-on.

Whilst the initial plan covers only OE-Core, once we get them working the 
tools and scripts used should be just as applicable to other layers. 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.

Please let me know your thoughts on the above, most importantly on the 
patchwork upgrade, since most of this hinges on that; I don't believe we can 
practically base it on the version of Patchwork we are using now. 

[Note that this email is cross-posted - it may be best to reply on OE-Core 
only to save people's inboxes.]

Thanks,
Paul

[0] http://patchwork.openembedded.org/
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7657#c21
[2] http://patchwork.freedesktop.org/ 
[3] https://github.com/dlespiau/patchwork
[4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8648

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Patchwork & patch handling improvements

[Burton, Ross]

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

On 26 November 2015 at 21:00, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:

> Please let me know your thoughts on the above, most importantly on the
> patchwork upgrade, since most of this hinges on that; I don't believe we
> can
> practically base it on the version of Patchwork we are using now.
>

Yes, yes, and again yes.  :)

Ross

[-- Attachment #2: Type: text/html, Size: 773 bytes --]

Re: Patchwork & patch handling improvements

[akuster808]

Paul,

On 11/26/2015 01:00 PM, Paul Eggleton wrote:
> Hi all,
> 

Thanks for taking the time to look into this.

> Over the past several years one of the regular complaints people have made 
> about our project has been that patches sometimes take a long time to make it 
> into master, and it's not always clear what the state of a patch is during 
> that time. On the other side of things, maintainers are finding it increasingly 
> hard to keep up with testing and integrating incoming patches.

This is not all the result of the patchwork. As a maintainer I rarely
use the patchwork in work flow as I have no access to the state change
bits. So its harder to integrate patchwork into my workflow.

Since the rules are to wait for changes to hit Master before moving them
down the line adds time to merging patches to the stable branches. The
Patchwork does not have an impact on that delay.

What adds to the challenge of integrating patches is that a layer
maintainer may shoot a patch directly into the stable branch so if I had
that patch queued, I now have to back it out.

Also, I do this work all on my free time so I do my work in batches with
leads to some delay. I could probably do a better job at communication
where things are in the process.

 Additionally,
> trivial mistakes sometimes creep in that would be fairly easy to catch with an 
> automated process. We've been talking about this for a while and now I'd like 
> to propose a plan to finally address this:
> 
> 1) Upgrade the OE Patchwork instance [0] to a newer release; this should fix 
> some of the problems we are having [1] plus give us additional features. I 
> propose using the fork that freedesktop.org are using [2] [3] which is moving 
> a bit faster than upstream Patchwork; whilst the changes there may eventually 
> make it upstream (and work is ongoing there) we have a much greater ability to 
> influence the fork given that it's being worked on by one of my colleagues who 
> is pushing it in the direction we need it to go e.g. proper support for series 
> as opposed to treating every patch individually, improved UI, etc.

Yes please.

> 
> 2) Trigger automatic testing of submitted patches from Patchwork. We'd have a 
> script look at the contents of a patch and first check that the expected style 
> has been adhered to; second it would do some quick tests to verify that the 
> patch hasn't caused any immediately obvious regressions. I've filed some bugs 
> to cover this in more detail [4].

sounds good.
> 
> 3) Provide a means to easily schedule an overnight build on the autobuilder 
> for the set of patches that have passed the initial testing, as well as 
> present the results in a form that's easier to review for maintainers. For OE-
> Core this would be tied into the Yocto Project autobuilder, but I expect the 
> tools could be made flexible.
> 
> At all stages through this process the patch status in patchwork will be kept 
> up-to-date so it's clear to everyone what's happening. I'm also thinking we 
> could do email notifications to the submitter (opt-in) though that would be a 
> later add-on.
> 
> Whilst the initial plan covers only OE-Core, once we get them working the 
> tools and scripts used should be just as applicable to other layers. 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.

Yes, I would like to use this with meta-oe
> 
> Please let me know your thoughts on the above, most importantly on the 
> patchwork upgrade, since most of this hinges on that; I don't believe we can 
> practically base it on the version of Patchwork we are using now. 
> 

Yes we should enhance any tools that improve our workflow and quality of
work.

Kind regards and thanks again Paul.
armin
> [Note that this email is cross-posted - it may be best to reply on OE-Core 
> only to save people's inboxes.]
> 
> Thanks,
> Paul
> 
> [0] http://patchwork.openembedded.org/
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7657#c21
> [2] http://patchwork.freedesktop.org/ 
> [3] https://github.com/dlespiau/patchwork
> [4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8648
> 

Re: Patchwork & patch handling improvements

[Paul Eggleton]

Hi Armin,

On Friday 27 November 2015 09:15:39 akuster808 wrote:
> On 11/26/2015 01:00 PM, Paul Eggleton wrote:
> > Over the past several years one of the regular complaints people have made
> > about our project has been that patches sometimes take a long time to make
> > it into master, and it's not always clear what the state of a patch is
> > during that time. On the other side of things, maintainers are finding it
> > increasingly hard to keep up with testing and integrating incoming
> > patches.
> 
> This is not all the result of the patchwork. As a maintainer I rarely
> use the patchwork in work flow as I have no access to the state change
> bits. So its harder to integrate patchwork into my workflow.

So I would argue you should have access to that and we should arrange it; 
having said that though my idea is any manual status updates with Patchwork 
should be minimal - we should pick up as much as we can from other actions 
you're already carrying out e.g. pushing the patch to your staging branch, 
running that through the autobuilder, etc. About the only ones where we can't 
pick something up would be where the patch is rejected, deferred, or master 
has moved on or the patch overlaps with another person's patch such that you 
ask the submitter to rebase; in those cases someone will need to mark the 
patch in patchwork by hand. Thinking aloud though it's possible we could do 
this via email if we embedded some kind of directive to patchwork in the reply 
to the mailing list; not sure how people feel about that idea but I think it's 
at least a possibility.

> Since the rules are to wait for changes to hit Master before moving them
> down the line adds time to merging patches to the stable branches. The
> Patchwork does not have an impact on that delay.

Not directly, but my hope is that automating a lot of this is going to smooth 
the flow of patches into master so that that part of the delay is minimised.

> What adds to the challenge of integrating patches is that a layer
> maintainer may shoot a patch directly into the stable branch so if I had
> that patch queued, I now have to back it out.

I agree that would generate a bit more work, but shouldn't it be as 
straightforward as a rebase though?

> Also, I do this work all on my free time so I do my work in batches with
> leads to some delay. I could probably do a better job at communication
> where things are in the process.

As far as I've seen you've been pretty proactive as far as communicating 
things goes, and it's definitely appreciated :)

>  Additionally,
> 
> > trivial mistakes sometimes creep in that would be fairly easy to catch
> > with an automated process. We've been talking about this for a while and
> > now I'd like to propose a plan to finally address this:
> > 
> > 1) Upgrade the OE Patchwork instance [0] to a newer release; this should
> > fix some of the problems we are having [1] plus give us additional
> > features. I propose using the fork that freedesktop.org are using [2] [3]
> > which is moving a bit faster than upstream Patchwork; whilst the changes
> > there may eventually make it upstream (and work is ongoing there) we have
> > a much greater ability to influence the fork given that it's being worked
> > on by one of my colleagues who is pushing it in the direction we need it
> > to go e.g. proper support for series as opposed to treating every patch
> > individually, improved UI, etc.
>
> Yes please.
> 
> > 2) Trigger automatic testing of submitted patches from Patchwork. We'd
> > have a script look at the contents of a patch and first check that the
> > expected style has been adhered to; second it would do some quick tests
> > to verify that the patch hasn't caused any immediately obvious
> > regressions. I've filed some bugs to cover this in more detail [4].
> 
> sounds good.
> 
> > 3) Provide a means to easily schedule an overnight build on the
> > autobuilder
> > for the set of patches that have passed the initial testing, as well as
> > present the results in a form that's easier to review for maintainers. For
> > OE- Core this would be tied into the Yocto Project autobuilder, but I
> > expect the tools could be made flexible.
> > 
> > At all stages through this process the patch status in patchwork will be
> > kept up-to-date so it's clear to everyone what's happening. I'm also
> > thinking we could do email notifications to the submitter (opt-in) though
> > that would be a later add-on.
> > 
> > Whilst the initial plan covers only OE-Core, once we get them working the
> > tools and scripts used should be just as applicable to other layers. 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.
> 
> Yes, I would like to use this with meta-oe
> 
> > Please let me know your thoughts on the above, most importantly on the
> > patchwork upgrade, since most of this hinges on that; I don't believe we
> > can practically base it on the version of Patchwork we are using now.
> 
> Yes we should enhance any tools that improve our workflow and quality of
> work.
> 
> Kind regards and thanks again Paul.

Thank you!

> > [Note that this email is cross-posted - it may be best to reply on OE-Core
> > only to save people's inboxes.]
> > 
> > Thanks,
> > Paul
> > 
> > [0] http://patchwork.openembedded.org/
> > [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=7657#c21
> > [2] http://patchwork.freedesktop.org/
> > [3] https://github.com/dlespiau/patchwork
> > [4] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8648

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Patchwork & patch handling improvements

[Koen Kooi]

Op 26-11-15 om 22:00 schreef Paul Eggleton:
> Hi all,
> 
> Over the past several years one of the regular complaints people have made 
> about our project has been that patches sometimes take a long time to make it 
> into master, and it's not always clear what the state of a patch is during 
> that time. On the other side of things, maintainers are finding it increasingly 
> hard to keep up with testing and integrating incoming patches. Additionally, 
> trivial mistakes sometimes creep in that would be fairly easy to catch with an 
> automated process. We've been talking about this for a while and now I'd like 
> to propose a plan to finally address this:
> 
> 1) Upgrade the OE Patchwork instance [0] to a newer release; this should fix 
> some of the problems we are having [1] plus give us additional features. I 
> propose using the fork that freedesktop.org are using [2] [3] which is moving 
> a bit faster than upstream Patchwork; whilst the changes there may eventually 
> make it upstream (and work is ongoing there) we have a much greater ability to 
> influence the fork given that it's being worked on by one of my colleagues who 
> is pushing it in the direction we need it to go e.g. proper support for series 
> as opposed to treating every patch individually, improved UI, etc.

I very much support upgrading patchwork to the fdo version, the set-aware
feature removes a lot of visual clutter.

regards,

Koen

Re: Patchwork & patch handling improvements

[Trevor Woerner]

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?

Instead of cross-posting, maybe this would be a good email for the new
architecture list (CC'ed)?

Re: [OE-core] Patchwork & patch handling improvements

[Trevor Woerner]

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?

Instead of cross-posting, maybe this would be a good email for the new
architecture list (CC'ed)?

Re: Patchwork & patch handling improvements

[Paul Eggleton]

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.

> Instead of cross-posting, maybe this would be a good email for the new
> architecture list (CC'ed)?

Perhaps yes; I'm a bit concerned that list still doesn't have that many 
subscribers though (currently 28, two of which are the same person).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] Patchwork & patch handling improvements

[Paul Eggleton]

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.

> Instead of cross-posting, maybe this would be a good email for the new
> architecture list (CC'ed)?

Perhaps yes; I'm a bit concerned that list still doesn't have that many 
subscribers though (currently 28, two of which are the same person).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Patchwork & patch handling improvements

[Martin Jansa]

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

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.

Regards,

> > Instead of cross-posting, maybe this would be a good email for the new
> > architecture list (CC'ed)?
> 
> Perhaps yes; I'm a bit concerned that list still doesn't have that many 
> subscribers though (currently 28, two of which are the same person).
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

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

Re: [OE-core] Patchwork & patch handling improvements

[Martin Jansa]

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

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.

Regards,

> > Instead of cross-posting, maybe this would be a good email for the new
> > architecture list (CC'ed)?
> 
> Perhaps yes; I'm a bit concerned that list still doesn't have that many 
> subscribers though (currently 28, two of which are the same person).
> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

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

Re: Patchwork & patch handling improvements

[Paul Eggleton]

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?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [OE-core] Patchwork & patch handling improvements

[Paul Eggleton]

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?

Thanks,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Patchwork & patch handling improvements

[Martin Jansa]

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

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

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 including bundles 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@gmail.com

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

Re: [OE-core] Patchwork & patch handling improvements

[Martin Jansa]

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

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

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 including bundles 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@gmail.com

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

Re: Patchwork & patch handling improvements

[Richard Purdie]

On Mon, 2015-11-30 at 10:19 -0500, 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?
> 
> Instead of cross-posting, maybe this would be a good email for the new
> architecture list (CC'ed)?

I think the areas where there are disagreements are comparatively small,
really just on shell whitespace. Where they do exist, they are
problematic, not least as some layers effectively ignored an agreement
made by the TSC simply because they didn't agree with it. It basically
means the OE TSC only applies to OE-Core as far as I can tell, which is
sad but is the decision that was made. This also means the TSC has no
real influence over any proposed coding style being used outside
OE-Core.

I do still believe shell whitespace changes would cause significant
patch compatibility issues, I know I disagree on Martin over that. I
still don't like the idea of people blindly running a formatting script
since we'll than start seeing patches every time there is a single space
in the wrong place. We simply don't want that amount of churn on the
metadata.

I can imagine several people replying and saying that patch churn is not
an issue but having seen the things people send patches for, I believe
it will be. I don't want to encourage such things as I believe there are
better things to do with our time (mine included as I'd have to review
them, even to just say 'no').

The maintainers file is a different problem and its one of maintenance,
and more specifically what being listed means, who can be listed, how
that listing can be changed and so on. The Yocto Project has some notion
of maintainer and there its easy, Ross and I can made decisions on who
is listed and what those people are expected to do and we can make it
work (its how we ensure things get upgraded with some regularity). For
OE, who would do this and what would the maintainer file mean? If
someone patches something, are they required to cc the maintainer on
patches for example? (that would imply workflow overhead) What if they
don't cc a maintainer? Should we be forced to revert such a patch?

In many ways its like the "what is a stable branch?" question. Some
people want to use a maintainers file as a way of having a veto on
certain patches. Others want to use it as a way of finding people to fix
bugs. Others again want it to help review patches. The uses vary and you
need a clear definition about what its being used for to make it work.

If someone wants to put together a proposal about which problem this
solves, with clear definitions/charter about how it would all work,
great, but I've seen a lot of problems with such files and I worry it
creates more problems than it would solve.

Cheers,

Richard

Re: [OE-core] Patchwork & patch handling improvements

[Richard Purdie]

On Mon, 2015-11-30 at 10:19 -0500, 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?
> 
> Instead of cross-posting, maybe this would be a good email for the new
> architecture list (CC'ed)?

I think the areas where there are disagreements are comparatively small,
really just on shell whitespace. Where they do exist, they are
problematic, not least as some layers effectively ignored an agreement
made by the TSC simply because they didn't agree with it. It basically
means the OE TSC only applies to OE-Core as far as I can tell, which is
sad but is the decision that was made. This also means the TSC has no
real influence over any proposed coding style being used outside
OE-Core.

I do still believe shell whitespace changes would cause significant
patch compatibility issues, I know I disagree on Martin over that. I
still don't like the idea of people blindly running a formatting script
since we'll than start seeing patches every time there is a single space
in the wrong place. We simply don't want that amount of churn on the
metadata.

I can imagine several people replying and saying that patch churn is not
an issue but having seen the things people send patches for, I believe
it will be. I don't want to encourage such things as I believe there are
better things to do with our time (mine included as I'd have to review
them, even to just say 'no').

The maintainers file is a different problem and its one of maintenance,
and more specifically what being listed means, who can be listed, how
that listing can be changed and so on. The Yocto Project has some notion
of maintainer and there its easy, Ross and I can made decisions on who
is listed and what those people are expected to do and we can make it
work (its how we ensure things get upgraded with some regularity). For
OE, who would do this and what would the maintainer file mean? If
someone patches something, are they required to cc the maintainer on
patches for example? (that would imply workflow overhead) What if they
don't cc a maintainer? Should we be forced to revert such a patch?

In many ways its like the "what is a stable branch?" question. Some
people want to use a maintainers file as a way of having a veto on
certain patches. Others want to use it as a way of finding people to fix
bugs. Others again want it to help review patches. The uses vary and you
need a clear definition about what its being used for to make it work.

If someone wants to put together a proposal about which problem this
solves, with clear definitions/charter about how it would all work,
great, but I've seen a lot of problems with such files and I worry it
creates more problems than it would solve.

Cheers,

Richard

Re: Patchwork & patch handling improvements

[Barros Pena, Belen]

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


>
>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 including bundles 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@gmail.com

Re: Patchwork & patch handling improvements

[Barros Pena, Belen]

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. 

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@gmail.com
>
>-- 
>_______________________________________________
>Openembedded-core mailing list
>Openembedded-core@lists.openembedded.org
>http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Patchwork & patch handling improvements

[Martin Jansa]

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

Re: [Openembedded-architecture] Patchwork & patch handling improvements

[Burton, Ross]

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

On 2 December 2015 at 18:04, Martin Jansa <martin.jansa@gmail.com> wrote:

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

Sounds like instead of bundles the new patchworks needs the ability for a
single list to represent multiple projects (so there'd be a meta-oe,
meta-python, etc), and more status values.

Ross

[-- Attachment #2: Type: text/html, Size: 977 bytes --]

Re: [Openembedded-architecture] Patchwork & patch handling improvements

[Tim Orling]

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

On Wed, Dec 2, 2015 at 10:43 AM, Burton, Ross <ross.burton@intel.com> wrote:

>
> On 2 December 2015 at 18:04, Martin Jansa <martin.jansa@gmail.com> wrote:
>
>> 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.
>>
>
> Sounds like instead of bundles the new patchworks needs the ability for a
> single list to represent multiple projects (so there'd be a meta-oe,
> meta-python, etc), and more status values.
>
> I agree with Ross that if we can get the functionality we truly need into
Patchwork--and JaMa can live with the result or help guide the
functionality--that we have a better path into the future.

Also, for what it's worth I vote for spaces only. We can provide editor
templates/settings to make it easy on the end users. There are languages
that require tabs, there are languages that require spaces. Deal with the
required tabs when the necessary evil arises.

--Tim

>
>

[-- Attachment #2: Type: text/html, Size: 2031 bytes --]

Re: Patchwork & patch handling improvements

[Barros Pena, Belen]

On 02/12/2015 18:04, "Martin Jansa" <martin.jansa@gmail.com> wrote:

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

I've been told that database migration will work from the version of
Patchwork OE is currently using to the version of Patchwork being used by
FDO. 

>>>>including bundles

Yes, 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.

Fair enough. Maybe we should consider keeping bundles then.

Cheers

Belén

Re: [Openembedded-architecture] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 02/12/2015 18:43, "Burton, Ross" <ross.burton@intel.com> wrote:

>
>On 2 December 2015 at 18:04, Martin Jansa
><martin.jansa@gmail.com> wrote:
>
>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.
>
>
>
>
>Sounds like instead of bundles the new patchworks needs the ability for a
>single list to represent multiple projects (so there'd be a meta-oe,
>meta-python, etc),

That's already in place

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

>and more status values.

You can add status values (to the db directly or via the Django admin
interface), but they will apply to all projects in the Patchwork instance.
Ideally you should be able to set a list of status values per project I
guess. 

Cheers

Belén

>
>
>Ross
>

Re: [Openembedded-architecture] Patchwork & patch handling improvements

[Burton, Ross]

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

On 3 December 2015 at 11:43, Barros Pena, Belen <belen.barros.pena@intel.com
> wrote:

> >and more status values.
>
> You can add status values (to the db directly or via the Django admin
> interface), but they will apply to all projects in the Patchwork instance.
> Ideally you should be able to set a list of status values per project I
> guess.
>

Well it depends on what the extra values are.  Martin, what values do you
use?  A "merged in staging" value would be useful for everyone.

Ross

[-- Attachment #2: Type: text/html, Size: 939 bytes --]

Re: [Openembedded-architecture] Patchwork & patch handling improvements

[Martin Jansa]

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

On Thu, Dec 03, 2015 at 12:51:22PM +0000, Burton, Ross wrote:
> On 3 December 2015 at 11:43, Barros Pena, Belen <belen.barros.pena@intel.com
> > wrote:
> 
> > >and more status values.
> >
> > You can add status values (to the db directly or via the Django admin
> > interface), but they will apply to all projects in the Patchwork instance.
> > Ideally you should be able to set a list of status values per project I
> > guess.
> >
> 
> Well it depends on what the extra values are.  Martin, what values do you
> use?  A "merged in staging" value would be useful for everyone.

The list of bundles is in:
http://www.openembedded.org/wiki/Patchwork#Multiple_layers_sharing_the_same_oe_project_on_patchwork

Once the patches are added to correct bundles I mark them as archived to
know which ones were sorted (the main page gets empty).

Advantage of bundles (something similar can probably work with tags) is
that the same patch can be in multiple bundles, e.g. I can include some
change in master-next branch and bundle while also adding it to
meta-networking bundle for Joe to merge it when ready.

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

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

Re: [Openembedded-architecture] Patchwork & patch handling improvements

[Barros Pena, Belen]

On 03/12/2015 12:51, "Burton, Ross" <ross.burton@intel.com> wrote:

>On 3 December 2015 at 11:43, Barros Pena, Belen
><belen.barros.pena@intel.com> wrote:
>
>>and more status values.
>
>You can add status values (to the db directly or via the Django admin
>interface), but they will apply to all projects in the Patchwork instance.
>Ideally you should be able to set a list of status values per project I
>guess.
>
>
>
>
>Well it depends on what the extra values are.

Heh, I meant that's how Patchwork works at the moment, independently of
what we do for OE


> Martin, what values do you use?  A "merged in staging" value would be
>useful for everyone.
>
>
>Ross
>