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 <jo...@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" > > <sl...@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
