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
Attachment:
signature.asc
Description: PGP signature