Re: Incentives for review

[zimoun <zimon.toutoune@gmail.com>]

Hi,

I mainly agree with the words of the message I am replying and my
intent is to provide numbers about what we are speaking.

>> It’s not about urgency but rather about not contributing to the growth
>> of our patch backlog, which is a real problem.

While I disagree for submitting new package – I do not understand why or
how it is a problem to submit to guix-patches, wait 15 days, and then
push – I would like to put numbers about this backlog…

> I have often seen folks on various projects worried about the size of
> various backlogs: bugs, issues, etc. I think it is human to want to
> try and contain something that appears to be growing, unbounded. 

…about patches only.  Bug is another story. :-)


Patch 49993 is from Aug. 2021.  Between this patch and now (patch
51319), there are 164 patches still open.  Other said, 164 still open
submission for 2 months – I have not counted how many closed.

Patch 48999 is from Jun 2021.  Because the Debbugs numbering is shared
by many GNU projects, it is hard to know how many patches over this
thousand are Guix only.  However, today still 83 patches open on this
thousand range (49093–49993) for ~2months. And on this 83 still open
submission, there are 17 submissions that have not received any reply.
And I bet they will not receive one and they are falling in the cracks.

Patch 47997 is from Apr 2021. Still 75 patch opens on this thousand
range (48006–48999) for ~2months.

Therefore, from Apr 2021 to now (~6months), it is ~320 patches still
open.  From Dec. 1rst 2020 (patch 45000) to the bottom Mar 2017 (patch
25849), it is 282 still open patches.  And I do not count how many
without any reply.

Just pick a random patch, say 47932 proposing the addition of package
’xqilla’.  First, there is no reply, And second, the patch does not
apply, thus it requires manual work.

Ok, so many are “just” triage.  For instance, last year over one month,
we did a bug squashing [1,2].  And I closed one per day over the month;
something like between 5min per report to half hour.  Bug was easier
than patch.  Considering that many of these 282 still open submissions
require: look if it is compliant, apply (manual work), build, etc. say
half hour on average, it means 141 hours which is basically a full month
full time for one person – and not a funny work – only for triaging old
submissions.

Here I speak about 282 old submissions (before Dec 2020) and for recent
ones (after Jan 2021), it is 438 still open submissions.  Other said, it
is ~720 submissions to deal with.  Considering 50 active people, it
means deal with 14 submissions per person, assuming half hour per
submission, it means a full day working only on that per person.

On the top of that, there are bugs, systems and new features. :-)

Do not take me wrong, it is great to have these numbers!  It means Guix
is used and people contribute.  So no complaint! :-)

Just number to fix the idea about large backlog.


1: <https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00001.html>
2: <https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00257.html>


> I think the thing that bothers us is a sense that the backlog is
> becoming unmanageable, or too large to triage. I submit that this is
> actually a tooling and organizational issue, and not an intrinsic
> issue to be solved. Bugs may still be valid; patches may still have
> valuable bones to modify.

This is the point.  What do you do?  What could we improve about tooling
and organisation to better scale and deal with this “becoming
unmanageable backlog”?

From my point of view, it is good to have this issue.  It means that
Guix is becoming more popular.  And we – regular user, contributor,
committer – have to adapt to this increasing workload, IMHO.

The question is how.  And how to invite people to complete review. :-)


> I think the real issue is that as a backlog grows, the tools we're
> used to using cannot answer the questions we want to ask: what is most
> relevant to me or the project right now?

If it is relevant to the project then it is also relevant to me as an
user.  And vice-versa. ;-)

When something relevant to me is not making progress, it often means
people are busy elsewhere, so I try to comment (review?) about patches
or bugs.  It is a Sisyphean task because the workload never
decreases. :-)  Or maybe structured procrastination. ;-)


Cheers,
simon