Re: Request for assistance maintaining LibreWolf

[Ian Eure <ian@retrospec.tv>]

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

> [[PGP Signed Part:Undecided]]
> Sergio Pastor Pérez <sergio.pastorperez@outlook.es> writes:
>
>> I cannot help you since I don't have commit access. But I want 
>> to thank
>> you for your hard work, I'm currently using your package.
>>
>> I can only echo your frustration since I also have some patches 
>> ready to
>> be merged that seem to be forgotten. As it has been discussed 
>> in the
>> past, Guix is growing, but there are not enough hands to merge 
>> all the
>> contributions that come through.
>>
>> We should try to come up with a solution that alleviates the 
>> burden on
>> the maintainers. Given how often this issue arises, what if we 
>> try, as
>> a collective, to suggest new mechanisms that would improve the
>> situation?
>>
>> If I recall correctly, someone suggested having a development 
>> branch in
>> which, once the QA passes, the patches get automatically 
>> merged. I know
>> some people rose concerns about the slowness of the QA system 
>> for this
>> to be an effective solution, and there is also the issue 
>> ordering the
>> patch application.
>>
>> If the previous solution is ruled out, I would like to know the 
>> opinion
>> of the Guix community on a voting system. I'm imagining a 
>> system where
>> we reuse the mailing infrastructure we have, where each 
>> accepted mail in
>> the guix devel mailing list has 1 vote for a given patch, that 
>> way we
>> avoid multiple votes from the same entity and would allow 
>> people without
>> commit access, but active on the Guix development, to 
>> participate. So,
>> we could set up a threshold where if a patch gets 10 votes from
>> non-committers the merge would be done; preferably automated, 
>> but if it's
>> not possible, committers would know what is ready to be merged 
>> without
>> effort and what the community wants.
>
> We've had for many months a feature in QA [1] where people can 
> mark
> patches as being reviewed and looking like they're ready to be 
> merged,
> which is personally what I hope will mitigate this feeling of "I 
> cannot
> help you since I don't have commit access", because you can 
> help, you
> can review the patches and if you think they're ready to merge, 
> you can
> record that, and this does help highlight patches that are ready 
> to
> merge.
>

Yes, I’ve used it before.  Unfortunately, it doesn’t appear to be 
making a material difference, as the size of the backlog continues 
to grow[1].  Progress on this problem would result in the backlog 
decreasing.  It doesn’t matter how many reviewers say it looks 
good -- a committer is required to actually push the changes.

The macro problem of the review process being broken has existed 
for years and there doesn’t seem to be concensus on the cause, 
much less a solution.  Waiting for that fix is unreasonable, but 
if a committer was willing to collaborate with me, the worst 
effects could be mitigated.  This is similar to how the Linux 
kernel works -- the "trusted deputy" approach.  It’d also provide 
a path for contributers to grow into committers.  Guix seems 
committed to using an email-based workflow, so I think it makes a 
lot of sense to look at how Linux does it.  It’s the most 
successful project in the world to use email-based development.

Thanks,

  — Ian

[1]: https://debbugs.gnu.org/rrd/guix-patches.html