[Buildroot] Patchwork cleanup: proposal

[Buildroot] Patchwork cleanup: proposal

[Thomas De Schampheleire]

Hi all,

The current patchwork cleanup sessions were organized as follows: every two weeks I would send a mail with the 10 oldest patches, asking the authors and the community whether the patch was still relevant or not. This would result in either of: rejection, acceptance, resend to the list.

Although this approach has worked fine so far, the biggest disadvantage of it is its slowness: with 10 patches every two weeks, and given two months of feature development during a buildroot release, this means that only about 40 patches can be closed this way per release.

My observation of these cleanup sessions is that there is some initial response when the mail is sent, then there is quiet time, and then again some response around the reminder mail and the final decision mail, with quietness in between. This leads to quite some lost time.
Moreover, while originally I thought we would resend the acceptable patches to the list during these two weeks, in practice it doesn't happen that way.

During the Buildroot developer days at FOSDEM last February, Thomas Petazzoni and I spent some time triaging the patchwork list as well. This went very well: on a very short time frame (a few hours) we were able to triage many patches, at a much faster rate than with the regular patchwork cleanup sessions.
At the same time, some other people, like Samuel and Maxime, were taking in the patches that we triaged, refreshing and resending them.

I would like to adjust the patchwork cleanup sessions based on this experience: instead of having fixed-duration, sequential sessions of two weeks, where the final triaging decision is taken at the end based on input of the submitters, I would like to propose the following:

- a triaging proposal for a number of patches is sent to the list when time permits. As I'm currently leading these cleanup sessions this would be done by me, but others could help here too. There is no limit on the amount of patches that can be triaged in a given timeframe.

- the triaging proposal is reviewed by other Buildroot developers. This agreement/disagreement phase shouldn't take long.

- the output of this triaging can be:
    A. We want this patch and someone should refresh and resend it.
    B. We don't want this patch as it goes against Buildroot principles.
    C. we're not sure and want to know if the submitter is still interested in pursuing this patch.

- In case A, ideally the original submitter refreshes the patch and resends it. If not, it ends up on the todo list.
- In case B, there is nothing to be done.
- In case C, the submitter (and other developers) get two weeks to provide feedback. When no feedback is provided, the patch is rejected.

In a separate mail than the one with the triaging proposal, submitters are notified of this decision.


The biggest advantage of this way of working would be the possibility to triage more patches in each release, while still providing submitters sufficient time to react.

Let me know what you think of this...

Best regards,
Thomas

[Buildroot] Patchwork cleanup: proposal

[Thomas De Schampheleire]

On Thu, Mar 6, 2014 at 9:59 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi all,
>
> The current patchwork cleanup sessions were organized as follows: every two weeks I would send a mail with the 10 oldest patches, asking the authors and the community whether the patch was still relevant or not. This would result in either of: rejection, acceptance, resend to the list.
>
> Although this approach has worked fine so far, the biggest disadvantage of it is its slowness: with 10 patches every two weeks, and given two months of feature development during a buildroot release, this means that only about 40 patches can be closed this way per release.
>
> My observation of these cleanup sessions is that there is some initial response when the mail is sent, then there is quiet time, and then again some response around the reminder mail and the final decision mail, with quietness in between. This leads to quite some lost time.
> Moreover, while originally I thought we would resend the acceptable patches to the list during these two weeks, in practice it doesn't happen that way.
>
> During the Buildroot developer days at FOSDEM last February, Thomas Petazzoni and I spent some time triaging the patchwork list as well. This went very well: on a very short time frame (a few hours) we were able to triage many patches, at a much faster rate than with the regular patchwork cleanup sessions.
> At the same time, some other people, like Samuel and Maxime, were taking in the patches that we triaged, refreshing and resending them.
>
> I would like to adjust the patchwork cleanup sessions based on this experience: instead of having fixed-duration, sequential sessions of two weeks, where the final triaging decision is taken at the end based on input of the submitters, I would like to propose the following:
>
> - a triaging proposal for a number of patches is sent to the list when time permits. As I'm currently leading these cleanup sessions this would be done by me, but others could help here too. There is no limit on the amount of patches that can be triaged in a given timeframe.
>
> - the triaging proposal is reviewed by other Buildroot developers. This agreement/disagreement phase shouldn't take long.
>
> - the output of this triaging can be:
>     A. We want this patch and someone should refresh and resend it.
>     B. We don't want this patch as it goes against Buildroot principles.
>     C. we're not sure and want to know if the submitter is still interested in pursuing this patch.
>
> - In case A, ideally the original submitter refreshes the patch and resends it. If not, it ends up on the todo list.
> - In case B, there is nothing to be done.
> - In case C, the submitter (and other developers) get two weeks to provide feedback. When no feedback is provided, the patch is rejected.
>
> In a separate mail than the one with the triaging proposal, submitters are notified of this decision.
>
>
> The biggest advantage of this way of working would be the possibility to triage more patches in each release, while still providing submitters sufficient time to react.
>
> Let me know what you think of this...

Ping?

[Buildroot] Patchwork cleanup: proposal

[Yann E. MORIN]

Thomas, All,

On 2014-03-06 21:59 +0100, Thomas De Schampheleire spake thusly:
[--SNIP--]
> I would like to adjust the patchwork cleanup sessions based on this
> experience: instead of having fixed-duration, sequential sessions of
> two weeks, where the final triaging decision is taken at the end
> based on input of the submitters, I would like to propose the
> following:
> 
> - a triaging proposal for a number of patches is sent to the list
>   when time permits. As I'm currently leading these cleanup sessions
>   this would be done by me, but others could help here too. There is
>   no limit on the amount of patches that can be triaged in a given
>   timeframe.
> 
> - the triaging proposal is reviewed by other Buildroot developers.
>   This agreement/disagreement phase shouldn't take long.
> 
> - the output of this triaging can be:
>     A. We want this patch and someone should refresh and resend it.
>     B. We don't want this patch as it goes against Buildroot principles.
>     C. we're not sure and want to know if the submitter is still
>     interested in pursuing this patch.
> 
> - In case A, ideally the original submitter refreshes the patch and
>   resends it. If not, it ends up on the todo list.
> - In case B, there is nothing to be done.
> - In case C, the submitter (and other developers) get two weeks to
>   provide feedback. When no feedback is provided, the patch is rejected.
> 
> In a separate mail than the one with the triaging proposal, submitters
> are notified of this decision.
> 
> 
> The biggest advantage of this way of working would be the possibility
> to triage more patches in each release, while still providing submitters
> sufficient time to react.
> 
> Let me know what you think of this...

I fail to see how it differs from the previous sessions. But if you find
it will make it easier, let's give it a spin. ;-)

From my experience, I found it tedious to look at patches, unless I had
a special interest in them.

May I suggest that:
  - people that send a list of patches do so with the ones they care about
  - we vote A/B/C as explained above

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Patchwork cleanup: proposal

[Thomas De Schampheleire]

On Sat, Mar 15, 2014 at 10:53 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, All,
>
> On 2014-03-06 21:59 +0100, Thomas De Schampheleire spake thusly:
> [--SNIP--]
>> I would like to adjust the patchwork cleanup sessions based on this
>> experience: instead of having fixed-duration, sequential sessions of
>> two weeks, where the final triaging decision is taken at the end
>> based on input of the submitters, I would like to propose the
>> following:
>>
>> - a triaging proposal for a number of patches is sent to the list
>>   when time permits. As I'm currently leading these cleanup sessions
>>   this would be done by me, but others could help here too. There is
>>   no limit on the amount of patches that can be triaged in a given
>>   timeframe.
>>
>> - the triaging proposal is reviewed by other Buildroot developers.
>>   This agreement/disagreement phase shouldn't take long.
>>
>> - the output of this triaging can be:
>>     A. We want this patch and someone should refresh and resend it.
>>     B. We don't want this patch as it goes against Buildroot principles.
>>     C. we're not sure and want to know if the submitter is still
>>     interested in pursuing this patch.
>>
>> - In case A, ideally the original submitter refreshes the patch and
>>   resends it. If not, it ends up on the todo list.
>> - In case B, there is nothing to be done.
>> - In case C, the submitter (and other developers) get two weeks to
>>   provide feedback. When no feedback is provided, the patch is rejected.
>>
>> In a separate mail than the one with the triaging proposal, submitters
>> are notified of this decision.
>>
>>
>> The biggest advantage of this way of working would be the possibility
>> to triage more patches in each release, while still providing submitters
>> sufficient time to react.
>>
>> Let me know what you think of this...
>
> I fail to see how it differs from the previous sessions. But if you find
> it will make it easier, let's give it a spin. ;-)

The proposal differs in following ways:
- while originally we handled maximum 10 patches per two weeks, the
proposal allows to handle unlimited patches in a given timeframe.

- the patch submitters are only involved when the community has
finished the triaging. They can still contest the decision, or in case
C provide feedback, but we don't take their input as primary feedback.
For many patches, we can make an assessment without input.

>
> From my experience, I found it tedious to look at patches, unless I had
> a special interest in them
>
> May I suggest that:
>   - people that send a list of patches do so with the ones they care about
>   - we vote A/B/C as explained above

It would certainly be very useful if some contributors would do
triaging of patches they care about. It will help reduce the backlog
even faster, so yes please!

At the same time, I do think that we need a garbage collector that
looks at all remaining patches, even for those he or she does not
particularly care about. After all, this is the only way to cleanup
the list.

Best regards,
Thomas

[Buildroot] Patchwork cleanup: proposal

[Yann E. MORIN]

Thomas, All,

On 2014-03-16 08:29 +0100, Thomas De Schampheleire spake thusly:
> It would certainly be very useful if some contributors would do
> triaging of patches they care about. It will help reduce the backlog
> even faster, so yes please!
> 
> At the same time, I do think that we need a garbage collector that
> looks at all remaining patches, even for those he or she does not
> particularly care about. After all, this is the only way to cleanup
> the list.

For the records, Maxime Hadjinlian, Samuel MArtin and I will be meeting
2014-04-10 (Thursday in two weeks from now) for a Pathwork party.

The goal is to spend the whole evening looking at the PAtchwork, and
apply the triaging as per your proposal in this thread.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Patchwork cleanup: proposal

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sat, 29 Mar 2014 15:11:30 +0100, Yann E. MORIN wrote:

> On 2014-03-16 08:29 +0100, Thomas De Schampheleire spake thusly:
> > It would certainly be very useful if some contributors would do
> > triaging of patches they care about. It will help reduce the backlog
> > even faster, so yes please!
> > 
> > At the same time, I do think that we need a garbage collector that
> > looks at all remaining patches, even for those he or she does not
> > particularly care about. After all, this is the only way to cleanup
> > the list.
> 
> For the records, Maxime Hadjinlian, Samuel MArtin and I will be meeting
> 2014-04-10 (Thursday in two weeks from now) for a Pathwork party.
> 
> The goal is to spend the whole evening looking at the PAtchwork, and
> apply the triaging as per your proposal in this thread.

As we discussed on IRC, I'll try to be online on Thursday evening to
maybe discuss some patchwork entries and take decisions about them.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Patchwork cleanup: proposal

[Thomas De Schampheleire]

Hi guys,

On Sun, Apr 6, 2014 at 2:07 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Yann E. MORIN,
>
> On Sat, 29 Mar 2014 15:11:30 +0100, Yann E. MORIN wrote:
>
>> On 2014-03-16 08:29 +0100, Thomas De Schampheleire spake thusly:
>> > It would certainly be very useful if some contributors would do
>> > triaging of patches they care about. It will help reduce the backlog
>> > even faster, so yes please!
>> >
>> > At the same time, I do think that we need a garbage collector that
>> > looks at all remaining patches, even for those he or she does not
>> > particularly care about. After all, this is the only way to cleanup
>> > the list.
>>
>> For the records, Maxime Hadjinlian, Samuel MArtin and I will be meeting
>> 2014-04-10 (Thursday in two weeks from now) for a Pathwork party.
>>
>> The goal is to spend the whole evening looking at the PAtchwork, and
>> apply the triaging as per your proposal in this thread.
>
> As we discussed on IRC, I'll try to be online on Thursday evening to
> maybe discuss some patchwork entries and take decisions about them.
>

How did this go?

I never really replied to express my gratitude for this initiative, I
should have.

Best regards,
Thomas

[Buildroot] Patchwork cleanup: proposal

[Yann E. MORIN]

Thomas DS, All,

On 2014-04-13 08:10 +0200, Thomas De Schampheleire spake thusly:
> On Sun, Apr 6, 2014 at 2:07 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Dear Yann E. MORIN,
> >
> > On Sat, 29 Mar 2014 15:11:30 +0100, Yann E. MORIN wrote:
> >
> >> On 2014-03-16 08:29 +0100, Thomas De Schampheleire spake thusly:
> >> > It would certainly be very useful if some contributors would do
> >> > triaging of patches they care about. It will help reduce the backlog
> >> > even faster, so yes please!
> >> >
> >> > At the same time, I do think that we need a garbage collector that
> >> > looks at all remaining patches, even for those he or she does not
> >> > particularly care about. After all, this is the only way to cleanup
> >> > the list.
> >>
> >> For the records, Maxime Hadjinlian, Samuel MArtin and I will be meeting
> >> 2014-04-10 (Thursday in two weeks from now) for a Pathwork party.
> >>
> >> The goal is to spend the whole evening looking at the PAtchwork, and
> >> apply the triaging as per your proposal in this thread.
> >
> > As we discussed on IRC, I'll try to be online on Thursday evening to
> > maybe discuss some patchwork entries and take decisions about them.
> 
> How did this go?

Well, not that good I'm afraid. We started quite late, I was rather
pretty tired after a long (and borring) day at work. So we only skimmed
the patchwork for the low-hanging fruits. I managed to mark one patch as
Superseded, but Thomas P. alone seems to have fared far better than us...

<sad>So, I'm afraid that initiative fizzled out.</sad>

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] Patchwork cleanup: proposal

[Thomas De Schampheleire]

Hi Yann,

On Sun, Apr 13, 2014 at 4:16 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas DS, All,
>
> On 2014-04-13 08:10 +0200, Thomas De Schampheleire spake thusly:
>> On Sun, Apr 6, 2014 at 2:07 PM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>> > Dear Yann E. MORIN,
>> >
>> > On Sat, 29 Mar 2014 15:11:30 +0100, Yann E. MORIN wrote:
>> >
>> >> On 2014-03-16 08:29 +0100, Thomas De Schampheleire spake thusly:
>> >> > It would certainly be very useful if some contributors would do
>> >> > triaging of patches they care about. It will help reduce the backlog
>> >> > even faster, so yes please!
>> >> >
>> >> > At the same time, I do think that we need a garbage collector that
>> >> > looks at all remaining patches, even for those he or she does not
>> >> > particularly care about. After all, this is the only way to cleanup
>> >> > the list.
>> >>
>> >> For the records, Maxime Hadjinlian, Samuel MArtin and I will be meeting
>> >> 2014-04-10 (Thursday in two weeks from now) for a Pathwork party.
>> >>
>> >> The goal is to spend the whole evening looking at the PAtchwork, and
>> >> apply the triaging as per your proposal in this thread.
>> >
>> > As we discussed on IRC, I'll try to be online on Thursday evening to
>> > maybe discuss some patchwork entries and take decisions about them.
>>
>> How did this go?
>
> Well, not that good I'm afraid. We started quite late, I was rather
> pretty tired after a long (and borring) day at work. So we only skimmed
> the patchwork for the low-hanging fruits. I managed to mark one patch as
> Superseded, but Thomas P. alone seems to have fared far better than us...
>
> <sad>So, I'm afraid that initiative fizzled out.</sad>

Ok, thanks for the feedback, better luck next time...
Thanks for organizing it all the same!

Best regards,
Thomas