Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
To be honest, in terms of volunteered reviewing work, waiting
for several months is not something new. In academia, it may
take several months to years to get a journal paper response.
I've ever tried to think of possible ways to improve the process, but
several observations eventually changed my mind, and I'm willing
to accept the status quo.
* there is a trade-off between rigorousness and efficiency.
Any change in the process may induce disadvantages, where
the most difficult thing is to reach an agreement.
* we will add more work for ftp team if we get them involved in the
discussion of possible (but unsure) ways to improve NEW.
My ultimate opinion on NEW processing is neutral, and my only
hope for ftp team is to increase the pace of hiring new members.
To be concrete, it is much harder to write a concrete proposal
to debian-vote@l.d.o than discussing possibilities.
I understand we may have the enthusiasm to sprint on something.
However, in terms of the long-term endeavor on Debian development,
the negligible popcon number won't be less disappointing than
a long-term wait to clear the NEW queue.
If one's enthusiasm on working on some package is eventually
worn out after a break, then try to think of the following question:
Is it really necessary to introduce XXX to Debian?
Must I do this to have fun?
Strong motivations such as "I use this package, seriously" are not
likely to wear out very easily through time. Packages maintained
with a strong motivation are better cared among all packages in our
archive.
Why not calm down, and try to do something else as interesting
as Debian development when waiting for the NEW queue?
Or simply think of NEW queue as a Debian holiday application.
I just realized these over the years, and these are only my personal
opinion.
On Fri, 2022-08-26 at 09:18 +0200, Gard Spreemann wrote:
Jonas Smedegaard <jonas@jones.dk> writes:
> Quoting Gard Spreemann (2022-08-26 08:49:21)
> > On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge"
> > <slomo@debian.org> wrote:
> > > PS: To preempt any questions as for why, the background for my
> > > decision
> > > to stop maintaining any packages is this thread, but it's really
> > > just
> > > the straw that broke the camel's back
> > > https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html
> > >
> >
> > A bit off-topic, but I think we really ought to discuss (address?)
> > this elephant in the room once more. I don't have the answers, but
> > Sebastian's email yet again clearly illustrates how the status quo
> > is hurting the project. This clear example comes in addition to
> > worries raised before about what the status quo does to recruitment
> > of new developers.
> >
> > PS: I do not imply that the elephant in the room is the
> > ftpmasters. I'm thinking of the *process*. The people involved put
> > in admirable work in carrying out said process.
>
> The way I see it, the process is clear: provide *source* to build
> from.
>
> If there is "source" built from another source, then that other
> source
> is the true source.
>
> If ftpmasters sometimes approve intermediary works as source, then
> that
> is not a reason to complain that they are inconsistent - it is a
> reason
> to acknowledge that ftpmasters try their best just as the rest of us,
> and that the true source is the true source regardless of misssing it
> sometimes.
>
> Yes, this is painful. Yes, upstreams sometimes consider us stupid to
> care about this. Nothing new there, and not a reason to stop do it.
>
> If you disagree, then please *elaborate* on what you find sensible -
> don't assume we all agree and you can only state that the process is
> an
> elephant.
Apologies, I should have been a lot clearer. I did not mean the exact
issue of what is the "true source" of something in a package. Rather, I
was referring to the process itself (looking in particular to the last
three paragraphs and the PS in Sebastian's linked email [1]). Whatever
the correct answer to what a "true source" is, in the current process,
a
developer has to make an attempt at doing the right thing, and then
wait
*weeks or possibly months* to know for sure whether it was OK. And if
it's deemed not OK, the reasoning may be entirely specific to the exact
package and situation at hand, and therefore extremely hard to
generalize and to learn from. (Do not construe the above as "ftpmasters
should work faster and give more lengthy reasoning!" – adding *more*
work to the process would make things even worse in my opinion.)
Although I maintain a very small number of packages, and ones that also
very rarely have to re-clear NEW, even I feel sapped of motivation from
the process. And I read Sebastian's email partly as an expression of
the
same thing (apologies if I misconstrue your views, Sebastian). I do
believe similar points of view have been aired on the list before by
others too.
As to your last point, elaborating on what I find sensible: I sadly
don't have a good suggestion. I do believe it is possible to point out
that the status quo is harmful without knowing how to sensibly fix it,
though. That's what discussions are for :-)
I am presently unable to find the message I'm thinking of, but I seem
to
recall one proposal being raised in the past: trust that a developer
has
done everything right, and introduce a class of bugs that can cause
complete removal from the archive instead. Afterall, we do assume that
the developer does the technical things correctly, until such a time as
a bug is filed. Could we not also make the same assumptions for Policy
and Social Contract things?
[1]
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2022-August/022938.html
Best,
Gard
Reply to: