[Sugar-devel] Fwd: Proposal on how to speed up patch reviews
anish at sugarlabs.org
Tue Mar 26 13:57:22 EDT 2013
I don't have a dog in the fight, but I can give my two cents
(disclaimer: I'm sorry if I misunderstood facts or misquoted people):
With dextrose, we had the same bottleneck problem, of patches getting
stuck in the review queue, then the commit queue. One associated
problem is that the longer a patch lingers on, the more it loses
contextual value and the harder it is to remember/understand for
everyone what the patch was for or what it did (even with good commit
messages). What would happen many times is that once the patch finally
reaches the maintainer, he has to make an effort to recall the
relevance of the patch and spend time in reviewing it again.
Gonzalo also raises pertinent points:
* We don't have enough reviewers
* We don't have enough maintainers
In dextrose, addressed this problem this way:
* There was one release manager
* There were multiple people with the access and the authority to commit patches
* There were dedicated testers
* There were foul-ups initially, but this increased the pace of
development by at least 2x.
What could this mean in context of sugar/mainline:
* Have one or two maintainers. Simon and Manuq are excellent. They are
responsible for setting roadmaps, deadlines, and making releases.
* Have multiple people with commit access authority. Daniel and
Gonzalo perhaps? I don't know who else.
* The criteria for committing could be as simple as:
** The patch has been reviewed by atleast one person from this group
** The patch has been *tested* by atleast one person from this group
Normally, one wouldn't recommend this as it increases the chance of
breakage, but I guess we're at the other end of the spectrum. If
development pace needs to be ramped up, I'd recommend the above.
On Tue, Mar 26, 2013 at 7:26 AM, Simon Schampijer <simon at schampijer.de> wrote:
> On 03/26/2013 12:21 PM, Manuel Quiñones wrote:
>> I would like to applaud the discussion.
>> Yes, I think we are blocking too much, in regards to stuff that is out
>> of bugfixing, and polishing the gtk3 port. This is indeed not good
>> for the community.
>> When I started in this project, my patches received reviews from many
>> people, not only maintainers. Many discussions went by. I don't see
>> that happening anymore. We also had periodic design meetings guiding
>> features. Discussing design after the development is made isn't good,
>> It would be great if someone can stand up and become a maintainer.
>> Maybe you, Daniel? You have demonstrated your skills with
>> sugar-build, and helping on the gtk3 port.
> A reviewer with the authority described in this discussion is probably a
> good first start. I think that is what Daniel would be able to help us with.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
Anish | anish at sugarlabs.org
More information about the Sugar-devel