[Buildroot] Worried about patches not being merged?

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

Hello,

If you're worried about patches not being merged, or taking too long to
get merged, here is a quick statistic I made.

On http://patchwork.ozlabs.org/project/buildroot/list/, on a total of
356 pending patches at the time of my testing, only 22 patches had a
Acked-by, Reviewed-by or Tested-by tag. All of the other 334 patches
have not been given any of these tags.

If you would like to help getting patches merged more quickly, then
please help by reviewing and testing patches!

Thanks for your help,

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

[Buildroot] Worried about patches not being merged?

[Jörg Krause]

Dear Thomas,

On Mi, 2015-03-04 at 23:21 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> If you're worried about patches not being merged, or taking too long to
> get merged, here is a quick statistic I made.
> 
> On http://patchwork.ozlabs.org/project/buildroot/list/, on a total of
> 356 pending patches at the time of my testing, only 22 patches had a
> Acked-by, Reviewed-by or Tested-by tag. All of the other 334 patches
> have not been given any of these tags.
> 
> If you would like to help getting patches merged more quickly, then
> please help by reviewing and testing patches!

Are there any guidelines for reviewing? It's a pitty that GSoC did not
accepted Buildroot this year. The testing scripts would be a nice
feature.

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

J?rg,

On Wed, 18 Mar 2015 21:01:06 +0100, J?rg Krause wrote:

> Are there any guidelines for reviewing?

Not really. Just pick patches touching things you are a bit comfortable
with, give them some testing, and do some comments if needed. On the
other hand, if you think the patch is fine, simply reply with a
Reviewed-by tag.

Of course, reviewing simple package bumps or hash file additions is not
very useful, since I tend to apply such patches quickly: there is not
much potential trouble with such patches.

> It's a pitty that GSoC did not accepted Buildroot this year. The
> testing scripts would be a nice feature.

Yes, it is a pitty, but hopefully someone will pick up the task and
work on improving our QA tooling :)

Best regards,

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

[Buildroot] Worried about patches not being merged?

[Jörg Krause]

Hi Thomas,

On Do, 2015-03-19 at 09:20 +0100, Thomas Petazzoni wrote:
> J?rg,
> 
> On Wed, 18 Mar 2015 21:01:06 +0100, J?rg Krause wrote:
> 
> > Are there any guidelines for reviewing?
> 
> Not really. Just pick patches touching things you are a bit comfortable
> with, give them some testing, and do some comments if needed. On the
> other hand, if you think the patch is fine, simply reply with a
> Reviewed-by tag.

To be honest, I'm only looking for packages I'm currently using or which
seems to be interesting to me. I must confess I don't have the time to
review/test patches I don't care about or which looks to complex.

Following the mailing list for some months now I noticed that there is a
team of five to ten main contributers which do the most reviews and
tests. Maybe a section in the documentation  

I think patches should be classified as you mentioned in another mail. I
like the idea have having tags like "infrastructure", "new package",
"version bump", ..., to get a quick overview.

> Of course, reviewing simple package bumps or hash file additions is not
> very useful, since I tend to apply such patches quickly: there is not
> much potential trouble with such patches.
> 
> > It's a pitty that GSoC did not accepted Buildroot this year. The
> > testing scripts would be a nice feature.
> 
> Yes, it is a pitty, but hopefully someone will pick up the task and
> work on improving our QA tooling :)

Hopefully!

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

J?rg,

On Fri, 20 Mar 2015 16:33:16 +0100, J?rg Krause wrote:

> To be honest, I'm only looking for packages I'm currently using or which
> seems to be interesting to me. I must confess I don't have the time to
> review/test patches I don't care about or which looks to complex.

Yes, this is fine: if everyone takes care of patches touching packages
he is interested in, it would already help a lot.

For example, there are many systemd patches waiting for someone
knowledgeable in systemd stuff to look at them. We used to have Eric Le
Bihan taking care of such patches, but he is no longer active.
Fortunately, Mike Williams and Steven Noonan have appeared and seem to
be interested in systemd, which is great!

> Following the mailing list for some months now I noticed that there is a
> team of five to ten main contributers which do the most reviews and
> tests.

Correct, but as you can see by looking at the patch queue, it's not
enough.

> Maybe a section in the documentation  

Incomplete sentence?

> I think patches should be classified as you mentioned in another mail. I
> like the idea have having tags like "infrastructure", "new package",
> "version bump", ..., to get a quick overview.

True, but on the other hand, someone will have to add those tags
manually for each patch.

Thanks,

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

[Buildroot] Worried about patches not being merged?

[Angelo Compagnucci]

Dear Thomas Petazzoni,

I think think we have two major problems in Buildroot backlog management imho.

The first on is the impossibility to prioritize patches to be
reviewed. Nobody really cares to go to months old threads only to find
an important patch passed unobserved. We should have a way to tag that
patch as high/low priority just at the time of arrival, so reviewers
could choose in a pool of important patches. This way the project
could add important features and bug fixes more easily.
To me, it's not that important that my new shiny sysdig package will
enter buildroot in a couple of major releases, it's more important to
have the makedevs recursive option applied cause it's really a killer
feature (this is only an example from my backlog).

The second one is to have the ability to comment patches directly on
web. Nobody wants to dig his email client looking for that two months
old thread to be reviewed. Having a simple way to comment on web could
accelerate patch review considerably, cause I can filter patches
matching a certain criteria and review them one by one. I can choose
to review patches from older to younger, or patches that pertain to my
field of knowledge.

My two cents.

Sincerely, Angelo.

2015-03-18 21:01 GMT+01:00 J?rg Krause <joerg.krause@embedded.rocks>:
> Dear Thomas,
>
> On Mi, 2015-03-04 at 23:21 +0100, Thomas Petazzoni wrote:
>> Hello,
>>
>> If you're worried about patches not being merged, or taking too long to
>> get merged, here is a quick statistic I made.
>>
>> On http://patchwork.ozlabs.org/project/buildroot/list/, on a total of
>> 356 pending patches at the time of my testing, only 22 patches had a
>> Acked-by, Reviewed-by or Tested-by tag. All of the other 334 patches
>> have not been given any of these tags.
>>
>> If you would like to help getting patches merged more quickly, then
>> please help by reviewing and testing patches!
>
> Are there any guidelines for reviewing? It's a pitty that GSoC did not
> accepted Buildroot this year. The testing scripts would be a nice
> feature.
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

Angelo,

(Please don't use top-posting, top-posting is bad.)

On Thu, 19 Mar 2015 09:35:31 +0100, Angelo Compagnucci wrote:

> The first on is the impossibility to prioritize patches to be
> reviewed. Nobody really cares to go to months old threads only to find
> an important patch passed unobserved. We should have a way to tag that
> patch as high/low priority just at the time of arrival, so reviewers
> could choose in a pool of important patches. This way the project
> could add important features and bug fixes more easily.
> To me, it's not that important that my new shiny sysdig package will
> enter buildroot in a couple of major releases, it's more important to
> have the makedevs recursive option applied cause it's really a killer
> feature (this is only an example from my backlog).

Indeed, patchwork could offer more features to "classify" patches.
There are some big series like the SELinux stuff or the per-package
staging directory that are really "advanced/in-progress" work that
isn't at the same level as many other patches in the list.

Patchwork is an open-source project, the code base is pretty small and
easy, so feel free to contribute improvements!

> The second one is to have the ability to comment patches directly on
> web. Nobody wants to dig his email client looking for that two months
> old thread to be reviewed. Having a simple way to comment on web could
> accelerate patch review considerably, cause I can filter patches
> matching a certain criteria and review them one by one. I can choose
> to review patches from older to younger, or patches that pertain to my
> field of knowledge.

On this one however I believe you'll face the opposition of many of the
old timers, who are very much used to e-mail based review. I do think
that e-mail based review encourages more people to review because
everyone gets to see the review e-mails, it's not buried deep in an
obscure web interface.

And anyway, what are the available options? The Gerrit web interface is
absolutely terrible, it's a huge mess of buttons/links all over the
place, totally unusable IMO.

What you could do however, since patchwork has the complete e-mails, is
create a "Reply" button next to each patch in patchwork, that would
open up the patch and format a reply to it so that you can review the
patch. This would at least simplify the process of finding back in your
e-mail client the relevant e-mail (which, to be honest, isn't that
complicated: just copy/paste the Subject of the patch as given by
patchwork into your e-mail client, and it'll return you just that one
patch).

Also, often people complaining about e-mail and wanting to use
web-based stuff instead is because their e-mail client or e-mail setup
in general sucks. Do you have a good and efficient e-mail client? If
you don't, then the issue might be here.

Best regards,

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

[Buildroot] Worried about patches not being merged?

[Angelo Compagnucci]

Dear Thomas,

2015-03-19 10:16 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Angelo,
>
> (Please don't use top-posting, top-posting is bad.)

Sorry for the top post, it was a mistake.

> On Thu, 19 Mar 2015 09:35:31 +0100, Angelo Compagnucci wrote:
>
>> The first on is the impossibility to prioritize patches to be
>> reviewed. Nobody really cares to go to months old threads only to find
>> an important patch passed unobserved. We should have a way to tag that
>> patch as high/low priority just at the time of arrival, so reviewers
>> could choose in a pool of important patches. This way the project
>> could add important features and bug fixes more easily.
>> To me, it's not that important that my new shiny sysdig package will
>> enter buildroot in a couple of major releases, it's more important to
>> have the makedevs recursive option applied cause it's really a killer
>> feature (this is only an example from my backlog).
>
> Indeed, patchwork could offer more features to "classify" patches.
> There are some big series like the SELinux stuff or the per-package
> staging directory that are really "advanced/in-progress" work that
> isn't at the same level as many other patches in the list.
>
> Patchwork is an open-source project, the code base is pretty small and
> easy, so feel free to contribute improvements!

Why not, I will try to take a look, I'm really acquainted to web
programming with various web frameworks.

>> The second one is to have the ability to comment patches directly on
>> web. Nobody wants to dig his email client looking for that two months
>> old thread to be reviewed. Having a simple way to comment on web could
>> accelerate patch review considerably, cause I can filter patches
>> matching a certain criteria and review them one by one. I can choose
>> to review patches from older to younger, or patches that pertain to my
>> field of knowledge.
>
> On this one however I believe you'll face the opposition of many of the
> old timers, who are very much used to e-mail based review. I do think
> that e-mail based review encourages more people to review because
> everyone gets to see the review e-mails, it's not buried deep in an
> obscure web interface.

Absolutely! What I'm saying is that having a way to post comments on
patches directly from web it's easier than dig into really old
threads, especially if your patches becomes categorized and ordered.
Obviously, the email based workflow must stay in place.

> And anyway, what are the available options? The Gerrit web interface is
> absolutely terrible, it's a huge mess of buttons/links all over the
> place, totally unusable IMO.

I totally hate all that it's not email based. Pull requests are
absolutely terrible, and complicating things like in gerrit will move
away users.

> What you could do however, since patchwork has the complete e-mails, is
> create a "Reply" button next to each patch in patchwork, that would
> open up the patch and format a reply to it so that you can review the
> patch.

Yes, this is exactly what I'm thinking. I'm making some experiments
with http://getbarkeep.org, it's email based and has really a nice
review system, get a look at the video. Patchworks should offer
something similar.

> This would at least simplify the process of finding back in your
> e-mail client the relevant e-mail (which, to be honest, isn't that
> complicated: just copy/paste the Subject of the patch as given by
> patchwork into your e-mail client, and it'll return you just that one
> patch).
>
> Also, often people complaining about e-mail and wanting to use
> web-based stuff instead is because their e-mail client or e-mail setup
> in general sucks. Do you have a good and efficient e-mail client? If
> you don't, then the issue might be here.

Gmail is a good email client, no problems here. But if our mail
clients are easy to use, why there are patches as old as February
2014?

Sincerely, Angelo.

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



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] Worried about patches not being merged?

[Angelo Compagnucci]

Dear Thomas,

2015-03-19 10:34 GMT+01:00 Angelo Compagnucci <angelo.compagnucci@gmail.com>:
> Dear Thomas,
>
> 2015-03-19 10:16 GMT+01:00 Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>:
>> Angelo,
>>
>> (Please don't use top-posting, top-posting is bad.)
>
> Sorry for the top post, it was a mistake.
>
>> On Thu, 19 Mar 2015 09:35:31 +0100, Angelo Compagnucci wrote:
>>
>>> The first on is the impossibility to prioritize patches to be
>>> reviewed. Nobody really cares to go to months old threads only to find
>>> an important patch passed unobserved. We should have a way to tag that
>>> patch as high/low priority just at the time of arrival, so reviewers
>>> could choose in a pool of important patches. This way the project
>>> could add important features and bug fixes more easily.
>>> To me, it's not that important that my new shiny sysdig package will
>>> enter buildroot in a couple of major releases, it's more important to
>>> have the makedevs recursive option applied cause it's really a killer
>>> feature (this is only an example from my backlog).
>>
>> Indeed, patchwork could offer more features to "classify" patches.
>> There are some big series like the SELinux stuff or the per-package
>> staging directory that are really "advanced/in-progress" work that
>> isn't at the same level as many other patches in the list.
>>
>> Patchwork is an open-source project, the code base is pretty small and
>> easy, so feel free to contribute improvements!
>
> Why not, I will try to take a look, I'm really acquainted to web
> programming with various web frameworks.

Thinking about this, we could add more states, something like
"advanced/in-progress" for packages with a good looking review, or
"New Package" for packages classified as new packages, or "High
priority" for very important patches. No changes require here, only a
couple of new states to add to the database.


Sincerely, Angelo.

-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

Angelo,

On Thu, 19 Mar 2015 10:34:47 +0100, Angelo Compagnucci wrote:

> > Patchwork is an open-source project, the code base is pretty small and
> > easy, so feel free to contribute improvements!
> 
> Why not, I will try to take a look, I'm really acquainted to web
> programming with various web frameworks.

It's written in Django, and the code base is small as I said, so should
be easy to get involved. And the maintainer is also very nice, so
contributing shouldn't be a problem. patchwork's maintainer is even
using Buildroot himself, and he has contributed a number of patches, so
the project is definitely not unknown to him.

> > What you could do however, since patchwork has the complete e-mails, is
> > create a "Reply" button next to each patch in patchwork, that would
> > open up the patch and format a reply to it so that you can review the
> > patch.
> 
> Yes, this is exactly what I'm thinking. I'm making some experiments
> with http://getbarkeep.org, it's email based and has really a nice
> review system, get a look at the video. Patchworks should offer
> something similar.

I had a quick look at barkeep, but it seems that the workflow they have
is completely different than the one we want and use in the Buildroot
community. From
https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools,
it says:

  Barkeep was built at Ooyala, where we usually prefer a post-commit
  code review workflow for our products. This is where developers push
  to master as soon as their code is ready (i.e. looks nice, tests are
  written and pass) so other developers can begin integrating it. Code
  review happens when it's convenient for the team (within 1-2 days),
  and any comments are addressed in future commits.

This is definitely not the workflow we use today, and probably not the
one we would like to use.

> > Also, often people complaining about e-mail and wanting to use
> > web-based stuff instead is because their e-mail client or e-mail setup
> > in general sucks. Do you have a good and efficient e-mail client? If
> > you don't, then the issue might be here.
> 
> Gmail is a good email client, no problems here. But if our mail
> clients are easy to use, why there are patches as old as February
> 2014?

Because the problem is not tools, but time. We've got more and more
patches contributing, but not enough people helping with
reviewing/testing. So far, it's almost only Arnout, Yann, Peter, Baruch
and me doing regularly code reviews. Vicente is also helping by testing
patches. We need more people involved in the review process.

Also, on a number of pending patches, the reason they get stuck is
because they raise some questions/challenges that need to be discussed.
Something like just new package or a package bump that does not do
anything fancy is easy to review and merge. But something like the
per-package sysroot directory from Fabio, or some other big series,
require a lot more discussion / review because it's changing a lot of
things.

But indeed, having a way to categorize patches in patchwork would be
good. Maybe a simple tag system, so that we can associate random tags
to patches, and classify using that.

Best regards,

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

[Buildroot] Worried about patches not being merged?

[Angelo Compagnucci]

Dear Thomas,

2015-03-19 11:26 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Angelo,
>
> On Thu, 19 Mar 2015 10:34:47 +0100, Angelo Compagnucci wrote:
>
>> > Patchwork is an open-source project, the code base is pretty small and
>> > easy, so feel free to contribute improvements!
>>
>> Why not, I will try to take a look, I'm really acquainted to web
>> programming with various web frameworks.
>
> It's written in Django, and the code base is small as I said, so should
> be easy to get involved. And the maintainer is also very nice, so
> contributing shouldn't be a problem. patchwork's maintainer is even
> using Buildroot himself, and he has contributed a number of patches, so
> the project is definitely not unknown to him.

I'm already looking at the code!

>> > What you could do however, since patchwork has the complete e-mails, is
>> > create a "Reply" button next to each patch in patchwork, that would
>> > open up the patch and format a reply to it so that you can review the
>> > patch.
>>
>> Yes, this is exactly what I'm thinking. I'm making some experiments
>> with http://getbarkeep.org, it's email based and has really a nice
>> review system, get a look at the video. Patchworks should offer
>> something similar.
>
> I had a quick look at barkeep, but it seems that the workflow they have
> is completely different than the one we want and use in the Buildroot
> community. From
> https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools,
> it says:
>
>   Barkeep was built at Ooyala, where we usually prefer a post-commit
>   code review workflow for our products. This is where developers push
>   to master as soon as their code is ready (i.e. looks nice, tests are
>   written and pass) so other developers can begin integrating it. Code
>   review happens when it's convenient for the team (within 1-2 days),
>   and any comments are addressed in future commits.
>
> This is definitely not the workflow we use today, and probably not the
> one we would like to use.

Yes, it is out of the box. But changing that workwflow is really easy.
From my experiments, you can adapt it to buildroot workflow, in which
a patch can be applied only after a severe review.

>> > Also, often people complaining about e-mail and wanting to use
>> > web-based stuff instead is because their e-mail client or e-mail setup
>> > in general sucks. Do you have a good and efficient e-mail client? If
>> > you don't, then the issue might be here.
>>
>> Gmail is a good email client, no problems here. But if our mail
>> clients are easy to use, why there are patches as old as February
>> 2014?
>
> Because the problem is not tools, but time. We've got more and more
> patches contributing, but not enough people helping with
> reviewing/testing. So far, it's almost only Arnout, Yann, Peter, Baruch
> and me doing regularly code reviews. Vicente is also helping by testing
> patches. We need more people involved in the review process.

Yes, I know, and that's unfortunate. Btw I think this is a ckicken egg
problem, if user patches get reviewed after month, users lose interest
and then tend to contribute less.
I also have  a pile of patches that I rebase at each pull, but waiting
to send them case the backlog it's already full!

Count on me and please delegate to me patches you think I can help
review, I'm learning but I want to contribute more!

> Also, on a number of pending patches, the reason they get stuck is
> because they raise some questions/challenges that need to be discussed.
> Something like just new package or a package bump that does not do
> anything fancy is easy to review and merge. But something like the
> per-package sysroot directory from Fabio, or some other big series,
> require a lot more discussion / review because it's changing a lot of
> things.

Yes, can understand and I think the problem is not with this patches,
but the pile of new packages / medium level patches / newbie patches.

> But indeed, having a way to categorize patches in patchwork would be
> good. Maybe a simple tag system, so that we can associate random tags
> to patches, and classify using that.

I'll try to look into this!

Sincerely, Angelo.

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



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

Hello,

On Thu, 19 Mar 2015 11:45:02 +0100, Angelo Compagnucci wrote:

> > It's written in Django, and the code base is small as I said, so should
> > be easy to get involved. And the maintainer is also very nice, so
> > contributing shouldn't be a problem. patchwork's maintainer is even
> > using Buildroot himself, and he has contributed a number of patches, so
> > the project is definitely not unknown to him.
> 
> I'm already looking at the code!

Cool!

> > This is definitely not the workflow we use today, and probably not the
> > one we would like to use.
> 
> Yes, it is out of the box. But changing that workwflow is really easy.
> From my experiments, you can adapt it to buildroot workflow, in which
> a patch can be applied only after a severe review.

Ah, really? Could you describe a bit the workflow / how it would work ?

> Yes, I know, and that's unfortunate. Btw I think this is a ckicken egg
> problem, if user patches get reviewed after month, users lose interest
> and then tend to contribute less.

Yes, I fully agree on this. And that's why I spending *all* my
Buildroot time on reviewing/merging patches from others.

> Count on me and please delegate to me patches you think I can help
> review, I'm learning but I want to contribute more!

When, just pick whatever patches in the queue you believe you are
competent to review / test / ack.

> Yes, can understand and I think the problem is not with this patches,
> but the pile of new packages / medium level patches / newbie patches.

Well, is there really such a huge pile of new packages / medium level
patches / newbie patches ? We tend to apply them fairly quickly, in
general.

If there are so many "easy" patches, then please review / test / ack
them. Look at the A/R/T column at
http://patchwork.ozlabs.org/project/buildroot/list/. It indicates the
number of Acked-by, Reviewed-by and Tested-by tags. As you can see,
it's almost 0 0 0 for all patches. Which means nobody reviewed, tested
or acked the patches.

Also, if you think one patch is ready, has been given some
Acked/Reviewed/Tested tags and still doesn't get applied, please ping
me on IRC with a link to this patch.

Best regards,

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

[Buildroot] Worried about patches not being merged?

[Angelo Compagnucci]

Dear Thomas,

2015-03-19 12:09 GMT+01:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Thu, 19 Mar 2015 11:45:02 +0100, Angelo Compagnucci wrote:
>
>> > It's written in Django, and the code base is small as I said, so should
>> > be easy to get involved. And the maintainer is also very nice, so
>> > contributing shouldn't be a problem. patchwork's maintainer is even
>> > using Buildroot himself, and he has contributed a number of patches, so
>> > the project is definitely not unknown to him.
>>
>> I'm already looking at the code!
>
> Cool!

I have more or less done, I think in the WE I can push a patch to have
tags attached to patches.

>> > This is definitely not the workflow we use today, and probably not the
>> > one we would like to use.
>>
>> Yes, it is out of the box. But changing that workwflow is really easy.
>> From my experiments, you can adapt it to buildroot workflow, in which
>> a patch can be applied only after a severe review.
>
> Ah, really? Could you describe a bit the workflow / how it would work ?

I have to find more time to elaborate if that software could be bended
to buildroot needs. I have only a superficially view right now. I
promise to look better at it.

>> Yes, I know, and that's unfortunate. Btw I think this is a ckicken egg
>> problem, if user patches get reviewed after month, users lose interest
>> and then tend to contribute less.
>
> Yes, I fully agree on this. And that's why I spending *all* my
> Buildroot time on reviewing/merging patches from others.
>
>> Count on me and please delegate to me patches you think I can help
>> review, I'm learning but I want to contribute more!
>
> When, just pick whatever patches in the queue you believe you are
> competent to review / test / ack.
>
>> Yes, can understand and I think the problem is not with this patches,
>> but the pile of new packages / medium level patches / newbie patches.
>
> Well, is there really such a huge pile of new packages / medium level
> patches / newbie patches ? We tend to apply them fairly quickly, in
> general.

Yes, but I have the impression that patches tends to accumulate in a
stack fashion, so the patches served are the last arrived. If a patch
slips out of scope, it takes some time to get reviewed/committed. This
is wouldn't be a critic to your great work nor the work of the other
great reviewer/committers!

> If there are so many "easy" patches, then please review / test / ack
> them. Look at the A/R/T column at
> http://patchwork.ozlabs.org/project/buildroot/list/. It indicates the
> number of Acked-by, Reviewed-by and Tested-by tags. As you can see,
> it's almost 0 0 0 for all patches. Which means nobody reviewed, tested
> or acked the patches.
>
> Also, if you think one patch is ready, has been given some
> Acked/Reviewed/Tested tags and still doesn't get applied, please ping
> me on IRC with a link to this patch.


Thank you all for the great work!

Sincerely, Angelo.

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



-- 
Profile: http://it.linkedin.com/in/compagnucciangelo

[Buildroot] Worried about patches not being merged?

[Thomas Petazzoni]

Angelo,

On Thu, 19 Mar 2015 23:27:22 +0100, Angelo Compagnucci wrote:

> I have more or less done, I think in the WE I can push a patch to have
> tags attached to patches.

Awesome. Another thing that would be great in the long term is to make
the patchwork UI a bit reactive (Ajax stuff, etc.).

> > Ah, really? Could you describe a bit the workflow / how it would work ?
> 
> I have to find more time to elaborate if that software could be bended
> to buildroot needs. I have only a superficially view right now. I
> promise to look better at it.

Ok, thanks.

> > Well, is there really such a huge pile of new packages / medium level
> > patches / newbie patches ? We tend to apply them fairly quickly, in
> > general.
> 
> Yes, but I have the impression that patches tends to accumulate in a
> stack fashion, so the patches served are the last arrived. If a patch
> slips out of scope, it takes some time to get reviewed/committed. This
> is wouldn't be a critic to your great work nor the work of the other
> great reviewer/committers!

Yes, I agree this is what happens, but there is more or less a reason
for it. When a new patch arrives, if it's a fairly trivial package
bump, hash addition, or new package addition not raising any particular
question, then it's just good to apply it quickly so that it gets out
of the way.

Then, what happens is that what remains from this quick effort are the
more complicated patches, that tend to pile up.

Whenever I spend an evening applying patches, I generally try to work
in two passes: first a quick pass on all the trivial stuff of the day
(or past few days), and then a second pass during which I try to handle
a few older patches.

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