Re: Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
Jonas Smedegaard writes: > Quoting Gard Spreemann (2022-08-26 08:49:21) >> On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" >> 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 signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
Quoting Gard Spreemann (2022-08-26 08:49:21) > On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" > 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. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Current NEW review process saps developer motivation [Was: Looking for new maintainer(s) for GStreamer packages]
On August 25, 2022 10:52:56 AM GMT+02:00, "Sebastian Dröge" 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Looking for new maintainer(s) for GStreamer packages
Hi! Currently I'm the only maintainer for the GStreamer packages, basically all on this list here: https://qa.debian.org/developer.php?login=gstreamer...@packages.debian.org I'm not planning to maintain them (or any of my other packages) further in the near future but will keep things running somehow for now because of the large number of reverse dependencies. The packages should continue to be team-maintained for the same reason. I can either add one or more people to the existing GStreamer team, or I'm also fine with it being moved to a separate team, e.g. the GNOME or multimedia teams. Thanks! 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 signature.asc Description: This is a digitally signed message part
