[U-Boot] Application of patch submitted during the previous Merge Window

[U-Boot] Application of patch submitted during the previous Merge Window

[Graeme Russ]

Hi Wolfgang,

With the next release pending and the next Merge Window about to open, I
thought I might take the opportunity to ask a question that's been on my
mind...What is the 'procedure' (for want of a better word) you use for
patches applied during the merge window?

Now I know maintainers typically keep a 'next' branch which they can
quickly rebase and issue a pull request for, but you don't seem to keep
such a branch for the 'generic' patches (well, there is one, but it is now
nine months old)

Just wondering how we should be tracking said patches - Do you want us to
ping you when the Merge Window opens, or do you have them nicely piled up
in Patchwork ready to apply?

Personnaly, I like the idea of the next branch more than Patchwork, just
to be consistent with the maintainers

Regards,

Graeme

[U-Boot] Application of patch submitted during the previous Merge Window

[Wolfgang Denk]

Dear Graeme Russ,

In message <CALButCL9Cee9pZRvyUZqF0wp1Wh5XabhV-Tm8ywLKErU1r+vOw@mail.gmail.com> you wrote:
> 
> With the next release pending and the next Merge Window about to open, I
> thought I might take the opportunity to ask a question that's been on my
> mind...What is the 'procedure' (for want of a better word) you use for
> patches applied during the merge window?
> 
> Now I know maintainers typically keep a 'next' branch which they can
> quickly rebase and issue a pull request for, but you don't seem to keep
> such a branch for the 'generic' patches (well, there is one, but it is now
> nine months old)

In theory I create a new next branch when we have -rc1, but frequently
(like during this release) I then find that we're already very late in
the schedule, so we can as well wait another week or two and then
start with the next release.

> Just wondering how we should be tracking said patches - Do you want us to
> ping you when the Merge Window opens, or do you have them nicely piled up
> in Patchwork ready to apply?

Also in theory, most of the patches should go through the respective
custodians, so only a minimal remainder should be on my stack.


Also, many of the patches are RFC's, that go through several
iterations, and it is not always clear (to me) when they reach a state
when they should be applied.


I have to admit that I am disappointed about patchwork.  Only very few
of the custodians actually use it.  Normally they should "grab"
(assign to themself) patches that fall into their responsibility.
Normally everybody should marks patches where they request changes oin
the ML as "Changes Requested".  They should set patches to "accepted"
or "Waiting upstream" or ... when they deal with them.  They should
also occasionally go through the list and mark superseded patches etc.
as such.

Very few ever do.  Occasionally I try to raise some awareness when I
send another round of 20 or so mails "please change the status in
patchwork when you request changes", but this does not help much.

In the result, a huge patch list is piling up, and dealing with this
becomes more and more frustrating.


> Personnaly, I like the idea of the next branch more than Patchwork, just
> to be consistent with the maintainers

What Patchwork really does well is to automatically take care of
Acked-By: or Tested-By: comments.


I'm not really satisfied with the current process myself either.  Any
suggestions for improvement would be welcome.

Also any volunteers to help out.  There are many areas where help
could be needed.

- We need a new network custodian.

- We could need some "trivial patch monkeys" that pick up trivial
  patches (like cosmetic changes cleaning up coding style things etc.,
  documentation changes etc.) so I just can pull that stuff.

- We could need more testers.  We have a growing number of cases where
  patches get checked in that later turn out to cause problems.  Our
  test coverage is far from satisfactory.

- I would appreciate if custdians make more active use of patchwork,
  so the pile of patches there was shrinking instead of ever growing.

etc. etc.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I paid too much for it, but its worth it.

[U-Boot] Application of patch submitted during the previous Merge Window

[Graeme Russ]

Hi Wolfgang,

On 23/09/11 17:25, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <CALButCL9Cee9pZRvyUZqF0wp1Wh5XabhV-Tm8ywLKErU1r+vOw@mail.gmail.com> you wrote:
>>
>> With the next release pending and the next Merge Window about to open, I
>> thought I might take the opportunity to ask a question that's been on my
>> mind...What is the 'procedure' (for want of a better word) you use for
>> patches applied during the merge window?
>>
>> Now I know maintainers typically keep a 'next' branch which they can
>> quickly rebase and issue a pull request for, but you don't seem to keep
>> such a branch for the 'generic' patches (well, there is one, but it is now
>> nine months old)
> 
> In theory I create a new next branch when we have -rc1, but frequently
> (like during this release) I then find that we're already very late in
> the schedule, so we can as well wait another week or two and then
> start with the next release.

Ah, OK - I figured it must be related to the increased load you seem to be
under lately

>> Just wondering how we should be tracking said patches - Do you want us to
>> ping you when the Merge Window opens, or do you have them nicely piled up
>> in Patchwork ready to apply?
> 
> Also in theory, most of the patches should go through the respective
> custodians, so only a minimal remainder should be on my stack.
> 
> 
> Also, many of the patches are RFC's, that go through several
> iterations, and it is not always clear (to me) when they reach a state
> when they should be applied.

Well my two console patches are ready for the next merge window - I notice
you have not claimed them, so I'll ping you when it opens

> I have to admit that I am disappointed about patchwork.  Only very few
> of the custodians actually use it.  Normally they should "grab"
> (assign to themself) patches that fall into their responsibility.
> Normally everybody should marks patches where they request changes oin
> the ML as "Changes Requested".  They should set patches to "accepted"
> or "Waiting upstream" or ... when they deal with them.  They should
> also occasionally go through the list and mark superseded patches etc.
> as such.

Well I have a few niggles with Patchwork:
 - It failed to see one patch in one of my multi-patch series
 - Even though I kept the 'in-reply-to' chain intact, it still has the
   individual versions of my console patches (it should just update the
   existing patch)
 - I cannot even find phylib: remove a couple of redundant code lines
   (submitted 06/09/11 by Vladimir Zapolskiy <vz@mleia.com>)

> Very few ever do.  Occasionally I try to raise some awareness when I
> send another round of 20 or so mails "please change the status in
> patchwork when you request changes", but this does not help much.
> 
> In the result, a huge patch list is piling up, and dealing with this
> becomes more and more frustrating.

Well my theory on that would be that if the take-up of a process is not
naturally organic, then forcing the issue probably won't work either

>> Personnaly, I like the idea of the next branch more than Patchwork, just
>> to be consistent with the maintainers
> 
> What Patchwork really does well is to automatically take care of
> Acked-By: or Tested-By: comments.

Maybe so, but keeping in-reply-to: intact (which any decent mailer will do
with the reply button) make it easy for a maintainer to scan through and
pick them up as well - YMMV. And if it's creating a huge backlog, maybe the
ends don't justify the means

> I'm not really satisfied with the current process myself either.  Any
> suggestions for improvement would be welcome.

I think you have made far more ground on enforcing good in-reply-to:
adherence and patch revision commenting than getting everyone on board with
Patchwork. Even for large patch sets I'm happy to make sure I get the
in-reply-to: correct

> Also any volunteers to help out.  There are many areas where help
> could be needed.
> 
> - We need a new network custodian.
> 
> - We could need some "trivial patch monkeys" that pick up trivial
>   patches (like cosmetic changes cleaning up coding style things etc.,
>   documentation changes etc.) so I just can pull that stuff.

Maybe the load can be spread here - maintainers can put these in designated
branches in their repositories. I know this will cause the odd conflict,
but we (the maintainers) could also periodically sync between each other.
Another alternative is to create a new repo that all the custodians have
access to...

> - We could need more testers.  We have a growing number of cases where
>   patches get checked in that later turn out to cause problems.  Our
>   test coverage is far from satisfactory.

Noted - A few architectural fixups (driver framework anyone) will help a
long way here as well

> - I would appreciate if custdians make more active use of patchwork,
>   so the pile of patches there was shrinking instead of ever growing.

As mentioned above - I do wonder...

> etc. etc.

et. al.

Regards,

Graeme

[U-Boot] Application of patch submitted during the previous Merge Window

[Stefano Babic]

On 09/23/2011 11:21 AM, Graeme Russ wrote:

>>> Just wondering how we should be tracking said patches - Do you want us to
>>> ping you when the Merge Window opens, or do you have them nicely piled up
>>> in Patchwork ready to apply?
>>
>> Also in theory, most of the patches should go through the respective
>> custodians, so only a minimal remainder should be on my stack.
>>
>>
>> Also, many of the patches are RFC's, that go through several
>> iterations, and it is not always clear (to me) when they reach a state
>> when they should be applied.
> 
> Well my two console patches are ready for the next merge window - I notice
> you have not claimed them, so I'll ping you when it opens
> 
>> I have to admit that I am disappointed about patchwork.  Only very few
>> of the custodians actually use it.  Normally they should "grab"
>> (assign to themself) patches that fall into their responsibility.
>> Normally everybody should marks patches where they request changes oin
>> the ML as "Changes Requested".  They should set patches to "accepted"
>> or "Waiting upstream" or ... when they deal with them.  They should
>> also occasionally go through the list and mark superseded patches etc.
>> as such.

Maybe we have to start updating patchwork directly after sending our
answers to the ML to maintain the tool synchron. I was used to update
patchwork after answering several messages to the ML and, well, it is
common to forget to update some patches to the new status. It take more
time, but the only way that works with me is to update patchwork after
each answer, and not at the end...

> 
> Well I have a few niggles with Patchwork:
>  - It failed to see one patch in one of my multi-patch series
>  - Even though I kept the 'in-reply-to' chain intact, it still has the
>    individual versions of my console patches (it should just update the
>    existing patch)
>  - I cannot even find phylib: remove a couple of redundant code lines
>    (submitted 06/09/11 by Vladimir Zapolskiy <vz@mleia.com>)

I cannot see this patch on the mailing list, too. I can see a patch with
the same name submitted a day before at 05/09/11. And I can find it in
patchwork:

http://patchwork.ozlabs.org/patch/113414/

>> Also any volunteers to help out.  There are many areas where help
>> could be needed.
>>
>> - We need a new network custodian.
>>
>> - We could need some "trivial patch monkeys" that pick up trivial
>>   patches (like cosmetic changes cleaning up coding style things etc.,
>>   documentation changes etc.) so I just can pull that stuff.
> 
> Maybe the load can be spread here - maintainers can put these in designated
> branches in their repositories. I know this will cause the odd conflict,
> but we (the maintainers) could also periodically sync between each other.
> Another alternative is to create a new repo that all the custodians have
> access to...

This makes things more complicated.....

Best regards,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] Application of patch submitted during the previous Merge Window

[Graeme Russ]

Hi Stefano,

On 23/09/11 20:04, Stefano Babic wrote:
> On 09/23/2011 11:21 AM, Graeme Russ wrote:

> Maybe we have to start updating patchwork directly after sending our
> answers to the ML to maintain the tool synchron. I was used to update
> patchwork after answering several messages to the ML and, well, it is
> common to forget to update some patches to the new status. It take more
> time, but the only way that works with me is to update patchwork after
> each answer, and not at the end...

I must admit, as a sole developer/custodian, I really do not know how much
work it is to update Patchwork in sync with the ML

>> Well I have a few niggles with Patchwork:
>>  - It failed to see one patch in one of my multi-patch series
>>  - Even though I kept the 'in-reply-to' chain intact, it still has the
>>    individual versions of my console patches (it should just update the
>>    existing patch)
>>  - I cannot even find phylib: remove a couple of redundant code lines
>>    (submitted 06/09/11 by Vladimir Zapolskiy <vz@mleia.com>)
> 
> I cannot see this patch on the mailing list, too. I can see a patch with
> the same name submitted a day before at 05/09/11. And I can find it in
> patchwork:
> 
> http://patchwork.ozlabs.org/patch/113414/

Ah, I see now - it has been accepted. Silly me :)

>>> Also any volunteers to help out.  There are many areas where help
>>> could be needed.
>>>
>>> - We need a new network custodian.
>>>
>>> - We could need some "trivial patch monkeys" that pick up trivial
>>>   patches (like cosmetic changes cleaning up coding style things etc.,
>>>   documentation changes etc.) so I just can pull that stuff.
>>
>> Maybe the load can be spread here - maintainers can put these in designated
>> branches in their repositories. I know this will cause the odd conflict,
>> but we (the maintainers) could also periodically sync between each other.
>> Another alternative is to create a new repo that all the custodians have
>> access to...
> 
> This makes things more complicated.....

Probably true. But we really need to collect these little patches somehow -
Wolfgang is just too busy and they fly right past him

Regards,

Graeme

[U-Boot] Application of patch submitted during the previous Merge Window

[Wolfgang Denk]

Dear Stefano Babic,

In message <4E7C59B4.50900@denx.de> you wrote:
>
> Maybe we have to start updating patchwork directly after sending our
> answers to the ML to maintain the tool synchron. I was used to update

I think the main problem is if this is indeed two separate steps. As
soon as it becomes additional work, and probably even the need to
change tools and interfaces, it becomes a pain and people will stop
doing it.  That's how it works with me, at least.

I have asked before if we could get patchwork to acto on X- mail
headers - then it would be sufficient to add a line

	X-PATCHWORK-STATUS: Changes Reuested

or similar.

I for  myself have added a button to my MUA which automatically
locates the current message in PW and changes it's state.  This helps
a lot.  I have no ide if other MUAs (like Thunderbird, for example)
allow for similar extensions.

> > Well I have a few niggles with Patchwork:
> >  - It failed to see one patch in one of my multi-patch series

This is a known problem.  It is typical for problems with UTF encoding
issues.  This should be solved by now after we changed all to UTF.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A door is what a dog is perpetually on the wrong side of.
                                                        - Ogden Nash

[U-Boot] Application of patch submitted during the previous Merge Window

[stefano babic]

Am 23/09/2011 12:23, schrieb Wolfgang Denk:
> Dear Stefano Babic,
> 

Hi Wolfgang,

> In message <4E7C59B4.50900@denx.de> you wrote:
>>
> 
> I have asked before if we could get patchwork to acto on X- mail
> headers - then it would be sufficient to add a line
> 
> 	X-PATCHWORK-STATUS: Changes Reuested
> 
> or similar.

This helps, sure. However, I have tried and it does not work, at least
for me.vThe answer I sent have two custom headers:

X-Patchwork-Delegate: sbabic
X-Patchwork-Status: Rejected

But the status of the patch was not changed.

> 
> I for  myself have added a button to my MUA which automatically
> locates the current message in PW and changes it's state.  This helps
> a lot.  I have no ide if other MUAs (like Thunderbird, for example)
> allow for similar extensions.

For the Thunderbird users, if someone uses the same MUA: it should be
enough to add the following line to your profile's prefs.js

user_pref("mail.compose.other.header",
"X-Patchwork-Delegate,X-Patchwork-Status");

The headers are added to the e-mail - rather, as I said, the patch's
status was not changed. Probably I missed something...

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] Application of patch submitted during the previous Merge Window

[Wolfgang Denk]

Dear Graeme Russ,

In message <4E7C4F80.6070904@gmail.com> you wrote:
> 
> Well my two console patches are ready for the next merge window - I notice
> you have not claimed them, so I'll ping you when it opens

Just add them to my ToDo list by assigning them to me...

> > In the result, a huge patch list is piling up, and dealing with this
> > becomes more and more frustrating.
> 
> Well my theory on that would be that if the take-up of a process is not
> naturally organic, then forcing the issue probably won't work either

Agreed.  But many people have asked for the tool, and it appears we
don't have a better one.

> Maybe the load can be spread here - maintainers can put these in designated
> branches in their repositories. I know this will cause the odd conflict,

If you script this (based on pwapply) you can bail out early if the
patch is no longer in state "New".

> but we (the maintainers) could also periodically sync between each other.
> Another alternative is to create a new repo that all the custodians have
> access to...

That would be easy to do...


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10"  will
parse  and  generate  code  creating  a  variable, DO10I, as follows:
"DO10I = 1.10" If that doesn't terrify you, it should.

[U-Boot] Application of patch submitted during the previous Merge Window

[Graeme Russ]

On 23/09/11 20:18, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <4E7C4F80.6070904@gmail.com> you wrote:
>>
>> Well my two console patches are ready for the next merge window - I notice
>> you have not claimed them, so I'll ping you when it opens
> 
> Just add them to my ToDo list by assigning them to me...

Done - They are still 'New' (didn't know if you wanted that changed)

>>> In the result, a huge patch list is piling up, and dealing with this
>>> becomes more and more frustrating.
>>
>> Well my theory on that would be that if the take-up of a process is not
>> naturally organic, then forcing the issue probably won't work either
> 
> Agreed.  But many people have asked for the tool, and it appears we
> don't have a better one.

Coreboot switched from SVN to git and gerrit

>> Maybe the load can be spread here - maintainers can put these in designated
>> branches in their repositories. I know this will cause the odd conflict,
> 
> If you script this (based on pwapply) you can bail out early if the
> patch is no longer in state "New".
> 
>> but we (the maintainers) could also periodically sync between each other.
>> Another alternative is to create a new repo that all the custodians have
>> access to...
> 
> That would be easy to do...

Maybe that's what we do - Once a patch reaches maturity (a revision with an
Ack and maybe a Tested-by) any maintainer can just put it in the 'next'
repo - You can always veto it and not pull it into mainline anyway, but at
least it gives everyone a semi-stable platform to base patches for the next
merge window

Regards,

Graeme

[U-Boot] Application of patch submitted during the previous Merge Window

[Wolfgang Denk]

Dear Graeme Russ,

In message <4E7C63A0.5050005@gmail.com> you wrote:
>
> > Just add them to my ToDo list by assigning them to me...
> 
> Done - They are still 'New' (didn't know if you wanted that changed)

Thanks.  "New" is ok - it's what I expect for patche that  have not
been applied anywhere yet.

> Coreboot switched from SVN to git and gerrit

Switching to git makes perfect sense to me.

Using gerrit?  Hm... All my work in this context is e-mail based, and
I think many others work in a similar way.  Web-based tools may be
more "modern", but I have to admit that I am not convinced that they
are any more helpful or efficient.

> > That would be easy to do...
> 
> Maybe that's what we do - Once a patch reaches maturity (a revision with an
> Ack and maybe a Tested-by) any maintainer can just put it in the 'next'
> repo - You can always veto it and not pull it into mainline anyway, but at
> least it gives everyone a semi-stable platform to base patches for the next
> merge window

OK, let's try it out.  Which name should we use? [I don't want to use
"next" for this - we already use this name, in other context.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
That was the thing about deserts. They had their  own  gravity.  They
sucked you into the centre.           - Terry Pratchett, _Small Gods_

[U-Boot] Application of patch submitted during the previous Merge Window

[Graeme Russ]

Hi Wolfgang,

On Monday, September 26, 2011, Wolfgang Denk <wd@denx.de> wrote:
> Dear Graeme Russ,
>
> In message <4E7C63A0.5050005@gmail.com> you wrote:
>>
>> > That would be easy to do...
>>
>> Maybe that's what we do - Once a patch reaches maturity (a revision with
an
>> Ack and maybe a Tested-by) any maintainer can just put it in the 'next'
>> repo - You can always veto it and not pull it into mainline anyway, but
at
>> least it gives everyone a semi-stable platform to base patches for the
next
>> merge window
>
> OK, let's try it out.  Which name should we use? [I don't want to use
> "next" for this - we already use this name, in other context.]

How about 'staging'

Regards,

Graeme

[U-Boot] Application of patch submitted during the previous Merge Window

[Mike Frysinger]

On Sunday, September 25, 2011 15:55:07 Wolfgang Denk wrote:
> Using gerrit?  Hm... All my work in this context is e-mail based, and
> I think many others work in a similar way.  Web-based tools may be
> more "modern", but I have to admit that I am not convinced that they
> are any more helpful or efficient.

gerrit is also pretty bad at a few critical things:
 - patch dependencies
 - keeping feedback visible across patchsets
 - retaining formatting of messages
 - the status e-mail's that get sent out

i'm not a general gerrit hater (there are things it does well), i just find 
these bits to not work well for development styles that are heavily based on 
e-mail lists
-mike

[U-Boot] [STATUS] Help needed - urgently

[Wolfgang Denk]

Hello all,

I guess most of you will already have noticed that my activity on the
mailing list has significantly declined recently. I'm sorry for that,
but I find myself in a situation where I have even less time
available for U-Boot than usually. In the result, the number of
unapplied (and sometimes unreviewed) patches is growing and growing.

I need your help. we need to find a way to distribute the workload
for "general" patches (i. e. those that don't fall obviously into the
responsibility of a specific custodian) across more shoulders than
just mine. Pressure on me has been building up already for some time,
and now we've reached the point where we need to find a solution.


One possible approach has been suggested before:

> >> Maybe the load can be spread here - maintainers can put these in
> >> designated
> >> branches in their repositories. I know this will cause the odd
> >> conflict,
> > 
> > If you script this (based on pwapply) you can bail out early if the
> > patch is no longer in state "New".
> > 
> >> but we (the maintainers) could also periodically sync between each
> >> other.
> >> Another alternative is to create a new repo that all the
> >> custodians have
> >> access to...
> > 
> > That would be easy to do...
> 
> Maybe that's what we do - Once a patch reaches maturity (a revision
> with an Ack and maybe a Tested-by) any maintainer can just put it in
> the 'next' repo - You can always veto it and not pull it into
> mainline anyway, but at least it gives everyone a semi-stable
> platform to base patches for the next merge window

I would like to try this out now, taking effect immediately.

I have created a new repository "u-boot-staging", where all current
custodians (should) have write access to.

My proposal is as follows (please feel free to comment):

- Any custodian is able (and encouraged) to pick up unapplied patches
  that have "reached maturity" (ideally an Ack and maybe a
  Tested-by), but at least no negative feedback on the mailing list,
  and re-review these. If they are considered OK and do not cause any
  new build issues, they can be applied.  Please don't forget to
  update the entries in Patchwork.

- To ensure quality, no custodian should apply his own patches.

- After reviewing and build testing (MAKEALL for at least two
  different architectures) the stuff can be pushed into a _branch_ of
  the "u-boot-staging" repository.  I suggest to use the custodian's
  e-mail address as branch name.

- After that, the custodian can send a pull request to me.


Please let's try if this works.  If you have any suggestions how to
help better, please don't hesitate to tell us.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The important thing about being a leader is not being right or wrong,
but being *certain*.                    - Terry Pratchett, _Truckers_

[U-Boot] [STATUS] Custodians - please lend a hand

[Wolfgang Denk]

Hm...

it seems a subject as "Help needed - urgently" ends in too many spam
filters, so I'm reposting.  This is actually serious.


In message <20111115150119.1F8E41689FB3@gemini.denx.de> I wrote:
>
> Hello all,
> 
> I guess most of you will already have noticed that my activity on the
> mailing list has significantly declined recently. I'm sorry for that,
> but I find myself in a situation where I have even less time
> available for U-Boot than usually. In the result, the number of
> unapplied (and sometimes unreviewed) patches is growing and growing.
> 
> I need your help. we need to find a way to distribute the workload
> for "general" patches (i. e. those that don't fall obviously into the
> responsibility of a specific custodian) across more shoulders than
> just mine. Pressure on me has been building up already for some time,
> and now we've reached the point where we need to find a solution.
> 
> 
> One possible approach has been suggested before:
> 
> > >> Maybe the load can be spread here - maintainers can put these in
> > >> designated
> > >> branches in their repositories. I know this will cause the odd
> > >> conflict,
> > > 
> > > If you script this (based on pwapply) you can bail out early if the
> > > patch is no longer in state "New".
> > > 
> > >> but we (the maintainers) could also periodically sync between each
> > >> other.
> > >> Another alternative is to create a new repo that all the
> > >> custodians have
> > >> access to...
> > > 
> > > That would be easy to do...
> > 
> > Maybe that's what we do - Once a patch reaches maturity (a revision
> > with an Ack and maybe a Tested-by) any maintainer can just put it in
> > the 'next' repo - You can always veto it and not pull it into
> > mainline anyway, but at least it gives everyone a semi-stable
> > platform to base patches for the next merge window
> 
> I would like to try this out now, taking effect immediately.
> 
> I have created a new repository "u-boot-staging", where all current
> custodians (should) have write access to.
> 
> My proposal is as follows (please feel free to comment):
> 
> - Any custodian is able (and encouraged) to pick up unapplied patches
>   that have "reached maturity" (ideally an Ack and maybe a
>   Tested-by), but at least no negative feedback on the mailing list,
>   and re-review these. If they are considered OK and do not cause any
>   new build issues, they can be applied.  Please don't forget to
>   update the entries in Patchwork.
> 
> - To ensure quality, no custodian should apply his own patches.
> 
> - After reviewing and build testing (MAKEALL for at least two
>   different architectures) the stuff can be pushed into a _branch_ of
>   the "u-boot-staging" repository.  I suggest to use the custodian's
>   e-mail address as branch name.
> 
> - After that, the custodian can send a pull request to me.
> 
> 
> Please let's try if this works.  If you have any suggestions how to
> help better, please don't hesitate to tell us.
> 
> Thanks.
> 
> Best regards,
> 
> Wolfgang Denk
> 
> -- 
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> The important thing about being a leader is not being right or wrong,
> but being *certain*.                    - Terry Pratchett, _Truckers_

[U-Boot] [STATUS] Custodians - please lend a hand

[Stefano Babic]

On 11/16/2011 07:51 PM, Wolfgang Denk wrote:

Wolfgang,

>>
>> Please let's try if this works.  If you have any suggestions how to
>> help better, please don't hesitate to tell us.

I have tried with a couple of patches (network related), and then I 
wanted to test if push works. As u-boot-staging should be open for all 
custodians, I was expecting I should use the same mechanism, and then I 
tried with:


git push ssh://gu-imx at git.denx.de/u-boot-staging sbabic at denx.de

...but the new branch sbabic at denx.de is now part of u-boot-imx, not 
u-boot-staging ! Where is the mistake ?

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [STATUS] Custodians - please lend a hand

[Wolfgang Denk]

Dear Stefano Babic,

In message <4EC4102D.2020903@denx.de> you wrote:
>
> I have tried with a couple of patches (network related), and then I 
> wanted to test if push works. As u-boot-staging should be open for all 
> custodians, I was expecting I should use the same mechanism, and then I 
> tried with:
> 
> 
> git push ssh://gu-imx at git.denx.de/u-boot-staging sbabic at denx.de
> 
> ...but the new branch sbabic at denx.de is now part of u-boot-imx, not 
> u-boot-staging ! Where is the mistake ?

The command did actually work?  Hm...

Please try instead pushign as user "gu-staging", i. e.

git push ssh://gu-staging at git.denx.de/u-boot-staging <your_branch>:sbabic at denx.de


And _thanks_ !!!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Disc space - the final frontier!

[U-Boot] [STATUS] Custodians - please lend a hand

[Detlev Zundel]

Hi Stefano,

> On 11/16/2011 07:51 PM, Wolfgang Denk wrote:
>
> Wolfgang,
>
>>>
>>> Please let's try if this works.  If you have any suggestions how to
>>> help better, please don't hesitate to tell us.
>
> I have tried with a couple of patches (network related), and then I 
> wanted to test if push works. As u-boot-staging should be open for all 
> custodians, I was expecting I should use the same mechanism, and then I 
> tried with:
>
>
> git push ssh://gu-imx at git.denx.de/u-boot-staging sbabic at denx.de
>
> ...but the new branch sbabic at denx.de is now part of u-boot-imx, not 
> u-boot-staging ! Where is the mistake ?

Indeed - this is because of the setup of the custodian trees.  The git
action is directly coupled to the user account so the account gu-imx
will _only_ be able to work inside that tree.  Effectively, the
directory part of the URL is discarded...

The correct usage is of course as Wolfgang points out through the
gu-staging user.

Best wishes
  Detlev

-- 
Due to the change in scope, STUN has also been renamed from "Simple Traversal
of UDP through NAT" to  "Session  Traversal Utilities for NAT".   The acronym
remains STUN, which is all anyone ever remembers anyway.    -- rfc5389
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [STATUS] Custodians - please lend a hand

[Andy Fleming]

On Thu, Nov 17, 2011 at 12:19 PM, Detlev Zundel <dzu@denx.de> wrote:
> Hi Stefano,
>
>> On 11/16/2011 07:51 PM, Wolfgang Denk wrote:
>>
>> Wolfgang,
>>
>>>>
>>>> Please let's try if this works. ?If you have any suggestions how to
>>>> help better, please don't hesitate to tell us.
>>
>> I have tried with a couple of patches (network related), and then I
>> wanted to test if push works. As u-boot-staging should be open for all
>> custodians, I was expecting I should use the same mechanism, and then I
>> tried with:
>>
>>
>> git push ssh://gu-imx at git.denx.de/u-boot-staging sbabic at denx.de
>>
>> ...but the new branch sbabic at denx.de is now part of u-boot-imx, not
>> u-boot-staging ! Where is the mistake ?
>
> Indeed - this is because of the setup of the custodian trees. ?The git
> action is directly coupled to the user account so the account gu-imx
> will _only_ be able to work inside that tree. ?Effectively, the
> directory part of the URL is discarded...
>
> The correct usage is of course as Wolfgang points out through the
> gu-staging user.
>

Might I humbly suggest that the custodians just push changes to a
separate branch in their own trees? It should be effectively the same,
but without everyone possibly hitting the same repository at the same
time...

Andy

[U-Boot] [STATUS] Custodians - please lend a hand

[Wolfgang Denk]

Dear Andy,

In message <CAKWjMd4Anjg05fMrs+DhmzQ6K-rnALWVkp2-y5t5pujyaszyWQ@mail.gmail.com> you wrote:
>
> Might I humbly suggest that the custodians just push changes to a
> separate branch in their own trees? It should be effectively the same,

I'd prefer to have it in one central location.  This also makes it
easier for others to check what's already present there.

> but without everyone possibly hitting the same repository at the same
> time...

On the day where you see performance problems because too many
custodians try to push too many patches to u-boot-staging
simultaneously I will rent a faster server.  Promised :-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
As a general rule, the freedom of any people can  be  judged  by  the
volume of their laughter.

[U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 15, 2011, at 9:01 AM, Wolfgang Denk wrote:

> Hello all,
> 
> I guess most of you will already have noticed that my activity on the
> mailing list has significantly declined recently. I'm sorry for that,
> but I find myself in a situation where I have even less time
> available for U-Boot than usually. In the result, the number of
> unapplied (and sometimes unreviewed) patches is growing and growing.
> 
> I need your help. we need to find a way to distribute the workload
> for "general" patches (i. e. those that don't fall obviously into the
> responsibility of a specific custodian) across more shoulders than
> just mine. Pressure on me has been building up already for some time,
> and now we've reached the point where we need to find a solution.
> 
> 
> One possible approach has been suggested before:
> 
>>>> Maybe the load can be spread here - maintainers can put these in
>>>> designated
>>>> branches in their repositories. I know this will cause the odd
>>>> conflict,
>>> 
>>> If you script this (based on pwapply) you can bail out early if the
>>> patch is no longer in state "New".
>>> 
>>>> but we (the maintainers) could also periodically sync between each
>>>> other.
>>>> Another alternative is to create a new repo that all the
>>>> custodians have
>>>> access to...
>>> 
>>> That would be easy to do...
>> 
>> Maybe that's what we do - Once a patch reaches maturity (a revision
>> with an Ack and maybe a Tested-by) any maintainer can just put it in
>> the 'next' repo - You can always veto it and not pull it into
>> mainline anyway, but at least it gives everyone a semi-stable
>> platform to base patches for the next merge window
> 
> I would like to try this out now, taking effect immediately.
> 
> I have created a new repository "u-boot-staging", where all current
> custodians (should) have write access to.
> 
> My proposal is as follows (please feel free to comment):
> 
> - Any custodian is able (and encouraged) to pick up unapplied patches
>  that have "reached maturity" (ideally an Ack and maybe a
>  Tested-by), but at least no negative feedback on the mailing list,
>  and re-review these. If they are considered OK and do not cause any
>  new build issues, they can be applied.  Please don't forget to
>  update the entries in Patchwork.
> 
> - To ensure quality, no custodian should apply his own patches.
> 
> - After reviewing and build testing (MAKEALL for at least two
>  different architectures) the stuff can be pushed into a _branch_ of
>  the "u-boot-staging" repository.  I suggest to use the custodian's
>  e-mail address as branch name.
> 
> - After that, the custodian can send a pull request to me.
> 
> 
> Please let's try if this works.  If you have any suggestions how to
> help better, please don't hesitate to tell us.

On suggestion I'd have is we improve our use of patchworks.  Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers.

- k

[U-Boot] [STATUS] Help needed - urgently

[Wolfgang Denk]

Dear Kumar Gala,

In message <D75BA016-4E89-4CEA-ACEC-CC322FF58A1F@kernel.crashing.org> you wrote:
> 
> 
> > Please let's try if this works.  If you have any suggestions how to
> > help better, please don't hesitate to tell us.
> 
> On suggestion I'd have is we improve our use of patchworks.  Right now
> there is way too much 'stale' on patchworks so its difficult to extract
> what needs to be looked at from what might be owned by existing
> maintainers.

As a first step this requires someone who is brave enought oclean up
the existing state, which is indeed a mess.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.

[U-Boot] [STATUS] Help needed - urgently

[Stefano Babic]

On 11/16/2011 10:35 PM, Wolfgang Denk wrote:
> Dear Kumar Gala,
> 
> In message <D75BA016-4E89-4CEA-ACEC-CC322FF58A1F@kernel.crashing.org> you wrote:
>>
>>
>>> Please let's try if this works.  If you have any suggestions how to
>>> help better, please don't hesitate to tell us.
>>
>> On suggestion I'd have is we improve our use of patchworks.  Right now
>> there is way too much 'stale' on patchworks so its difficult to extract
>> what needs to be looked at from what might be owned by existing
>> maintainers.
> 
> As a first step this requires someone who is brave enought oclean up
> the existing state, which is indeed a mess.

Sure, but anyway to avoid conflicts I suggest that who takes care of a
patch *firstly* sets his name as delegate into patchwork before doing
something.

Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de
=====================================================================

[U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 17, 2011, at 6:40 AM, Stefano Babic wrote:

> On 11/16/2011 10:35 PM, Wolfgang Denk wrote:
>> Dear Kumar Gala,
>> 
>> In message <D75BA016-4E89-4CEA-ACEC-CC322FF58A1F@kernel.crashing.org> you wrote:
>>> 
>>> 
>>>> Please let's try if this works.  If you have any suggestions how to
>>>> help better, please don't hesitate to tell us.
>>> 
>>> On suggestion I'd have is we improve our use of patchworks.  Right now
>>> there is way too much 'stale' on patchworks so its difficult to extract
>>> what needs to be looked at from what might be owned by existing
>>> maintainers.
>> 
>> As a first step this requires someone who is brave enought oclean up
>> the existing state, which is indeed a mess.
> 
> Sure, but anyway to avoid conflicts I suggest that who takes care of a
> patch *firstly* sets his name as delegate into patchwork before doing
> something.

Agreed, my thinking was that for the non-maintained patches, the maintainer that pulls a patch in to their tree would mark themselves as the delegate of the patch.

- k

[U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 16, 2011, at 3:35 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <D75BA016-4E89-4CEA-ACEC-CC322FF58A1F@kernel.crashing.org> you wrote:
>> 
>> 
>>> Please let's try if this works.  If you have any suggestions how to
>>> help better, please don't hesitate to tell us.
>> 
>> On suggestion I'd have is we improve our use of patchworks.  Right now
>> there is way too much 'stale' on patchworks so its difficult to extract
>> what needs to be looked at from what might be owned by existing
>> maintainers.
> 
> As a first step this requires someone who is brave enought oclean up
> the existing state, which is indeed a mess.

Can we say no new patches are going into upstream (your tree) until maintainers go cleanup patchworks?  Such that the # of non-delegated patches is only one or two pages worth, rather than 11.

- k

[U-Boot] [STATUS] Help needed - urgently

[Wolfgang Denk]

Dear Kumar Gala,

In message <DEC2DBE6-D658-4504-B157-7B57BB637296@kernel.crashing.org> you wrote:
> 
> > As a first step this requires someone who is brave enought oclean up
> > the existing state, which is indeed a mess.
> 
> Can we say no new patches are going into upstream (your tree) until
> maintainers go cleanup patchworks?  Such that the # of non-delegated
> patches is only one or two pages worth, rather than 11.

With "no new patches" you mean that I will stop applying already
posted patches, or new postings to the ML?

I'm fine with both...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Be careful what you wish for. You never know who will be listening.
                                      - Terry Pratchett, _Soul Music_

[U-Boot] [STATUS] Help needed - urgently

[Kumar Gala]

On Nov 17, 2011, at 8:10 AM, Wolfgang Denk wrote:

> Dear Kumar Gala,
> 
> In message <DEC2DBE6-D658-4504-B157-7B57BB637296@kernel.crashing.org> you wrote:
>> 
>>> As a first step this requires someone who is brave enought oclean up
>>> the existing state, which is indeed a mess.
>> 
>> Can we say no new patches are going into upstream (your tree) until
>> maintainers go cleanup patchworks?  Such that the # of non-delegated
>> patches is only one or two pages worth, rather than 11.
> 
> With "no new patches" you mean that I will stop applying already
> posted patches, or new postings to the ML?
> 
> I'm fine with both...

I meant the stop applying patches? not sure how we'd stop people posting new patches to the ML ;)

- k