From: zimoun <zimon.toutoune@gmail.com>
To: "Katherine Cox-Buday" <cox.katherine.e@gmail.com>,
"Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Incentives for review
Date: Thu, 21 Oct 2021 23:22:35 +0200 [thread overview]
Message-ID: <86czny13ac.fsf@gmail.com> (raw)
In-Reply-To: <87cznyfmcb.fsf@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
next prev parent reply other threads:[~2021-10-21 21:57 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-15 18:54 Tricking peer review Ludovic Courtès
2021-10-15 22:03 ` Liliana Marie Prikler
2021-10-15 22:28 ` Ryan Prior
2021-10-15 22:45 ` Liliana Marie Prikler
2021-10-15 22:59 ` Ryan Prior
2021-10-18 7:40 ` Ludovic Courtès
2021-10-18 19:56 ` Ryan Prior
2021-10-19 8:39 ` zimoun
2021-10-20 23:03 ` Leo Famulari
2021-10-21 8:14 ` zimoun
2021-10-15 23:13 ` Thiago Jung Bauermann
2021-10-18 7:47 ` Ludovic Courtès
2021-10-18 7:34 ` Ludovic Courtès
2021-10-19 8:36 ` zimoun
2021-10-19 12:56 ` Ludovic Courtès
2021-10-19 14:22 ` zimoun
2021-10-19 15:41 ` Incentives for review Ludovic Courtès
2021-10-19 16:56 ` zimoun
2021-10-19 19:14 ` Ricardo Wurmus
2021-10-19 19:34 ` Christine Lemmer-Webber
2021-10-19 19:50 ` Joshua Branson
2021-10-21 20:03 ` Ludovic Courtès
2021-10-20 21:37 ` Thiago Jung Bauermann
2021-10-21 13:38 ` Artem Chernyak
2021-10-22 20:03 ` Thiago Jung Bauermann
2021-10-23 1:43 ` Kyle Meyer
2021-10-23 3:42 ` Thiago Jung Bauermann
2021-10-23 7:37 ` zimoun
2021-10-23 16:18 ` public-inbox/elfeed -> Maildir bridge (was: Incentives for review) Kyle Meyer
2021-10-24 12:18 ` Jonathan McHugh
2021-10-21 16:06 ` Incentives for review Ricardo Wurmus
2021-10-21 16:32 ` zimoun
2021-10-22 20:06 ` Thiago Jung Bauermann
2021-10-21 15:07 ` Katherine Cox-Buday
2021-10-21 16:10 ` Ricardo Wurmus
2021-10-21 17:52 ` Katherine Cox-Buday
2021-10-21 18:21 ` Arun Isaac
2021-10-21 19:58 ` Ludovic Courtès
2021-10-21 21:42 ` Ricardo Wurmus
2021-10-22 10:48 ` Arun Isaac
2021-10-22 11:21 ` zimoun
2021-10-23 6:09 ` Arun Isaac
2021-10-22 10:56 ` Jonathan McHugh
2021-10-22 7:40 ` zimoun
2021-10-22 11:09 ` Arun Isaac
2021-10-22 8:37 ` Jonathan McHugh
2021-10-22 9:15 ` zimoun
2021-10-22 10:40 ` Jonathan McHugh
2021-10-22 11:32 ` zimoun
2021-10-21 21:18 ` Jonathan McHugh
2021-10-22 10:44 ` Arun Isaac
2021-10-22 11:06 ` Jonathan McHugh
2021-10-21 21:22 ` zimoun [this message]
2021-10-28 14:57 ` Katherine Cox-Buday
2021-10-21 17:51 ` Vagrant Cascadian
2021-10-24 11:47 ` Efraim Flashner
2021-10-20 8:22 ` Tricking peer review Giovanni Biscuolo
2021-10-20 9:10 ` zimoun
2021-10-20 8:29 ` patches for new packages proper workflow (Re: Tricking peer review) Giovanni Biscuolo
2021-10-20 23:09 ` Tricking peer review Leo Famulari
2021-10-21 7:12 ` Ludovic Courtès
2021-10-25 13:09 ` Christine Lemmer-Webber
2021-10-28 8:38 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86czny13ac.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=cox.katherine.e@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).