Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Am Tue, Apr 09, 2024 at 01:03:10PM + schrieb Stefano Rivera: > > I have also noticed that the young people we manage to recruit are > > usually not interested too much in the boring gruntwork of maintaining > > important core packages (like adduser and sudo) but instead want to do > > "new" things. But, otoh, what would Debian be without sudo? Somebody > > needs to do that work as well. > > To some degree, this is self-fulfilling. Most core packages have a > maintainer. Drive-by contributions in a bug or MR are likely to go > ignored for years. Newbies aren't going to get pulled into these > packages, easily. > > Where core packages are up for adoption, they're probably pretty complex > and maybe not the best candidate for a new contributor. The best stuff > has probably already been adopted. > > All of this leads to the position we are in, where new contributors best > road into the project is into teams. And the best way to get some > experience is packaging something new in a team. > > I see one of the goals of promoting team maintenance as increasing the > pipeline of new contributors into the maintenance of core > infrastructure. Rather than having to wait for the current maintainers > to slowly fade away and salvage the result after years of problems. Very well said. Congratulations for remotely reading my mind and turn it into those clear words. Kind regards Andreas. -- https://fam-tille.de
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
Hi Marc (2024.04.08_16:48:13_+) > I have also noticed that the young people we manage to recruit are > usually not interested too much in the boring gruntwork of maintaining > important core packages (like adduser and sudo) but instead want to do > "new" things. But, otoh, what would Debian be without sudo? Somebody > needs to do that work as well. To some degree, this is self-fulfilling. Most core packages have a maintainer. Drive-by contributions in a bug or MR are likely to go ignored for years. Newbies aren't going to get pulled into these packages, easily. Where core packages are up for adoption, they're probably pretty complex and maybe not the best candidate for a new contributor. The best stuff has probably already been adopted. All of this leads to the position we are in, where new contributors best road into the project is into teams. And the best way to get some experience is packaging something new in a team. I see one of the goals of promoting team maintenance as increasing the pipeline of new contributors into the maintenance of core infrastructure. Rather than having to wait for the current maintainers to slowly fade away and salvage the result after years of problems. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
[I'm skipping most of this email because I haven't generally been keeping up with the thread, but thought it might be worth pointing out one thing.] On Mon, Apr 08, 2024 at 06:48:13PM +0200, Marc Haber wrote: > On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote: > > Before uploading I usually > > run `routine-update -f` which is just upgrading to latest standards by > > calling Janitor tools and does some other changes to keep up with latest > > packaging standards semi-automatically. > > I wasn't aware of that tool. We need to publish more about such things. > > I am not particularly fond of Janitor's suggestions though. For my > taste, it removes support for older versions of Debian too quickly, and > I have frequently chosen to not accept janitor MRs because this would > affect ability and ease to backport to oldstable or even to > oldoldstable. But that also is a matter of style. I'm not sure how widely known it is, but the Janitor does have a mechanism for overriding the versions of Debian it retains compatibility with based on various considerations, and I've found it useful to land changes there in the past so that its other facilities can still be useful without getting in my way. Search for "compat_release" in https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: About Package Maintenance (was: Question to all candidates: What are your technical goals)
On Monday, April 8, 2024 12:48:13 PM EDT Marc Haber wrote: > > > "we replace exim with postfix as the default MTA", > > > > A, this question always makes me wonder: If our default MTA is exim > > why do I have such a hard time to find documents about exim in wiki.d.o > > while there is always a postfix solution. I personally usually go with > > the default and thus using exim. But well, if it comes to tricky > > details I always need to fall back to the longish exim docs while the > > short solution is available for postfix in wiki.d.o. > > That's the next chapter in the great MTA war which has been won by > postfix. As somebody who has been working on Exim in the 2000 years (I > am still on the team but haven't done anything useful to the package > for 15 years), I of course must say that Exim is the better MTA; but it > is way harder to use. > > I tend to use the metaphor that Postfix is the menu of a nice restaurant > run by professionals, offering much that you might want to eat, while > Exim is the fully equipped kitchen with a storage full of the best > ingredients, but you need to cook yourself. Summarized, if you find > something on the restaurant's menu that feels your need, order that > dish from the Postfix menu, and if not, go to the kitchen and cook your > own Exim menu. > > And of cours, Postfix's architecture is more modern while Exim still is > a monolithic, suid root blob, and Postfix also is more suitable for > sending out bulk mail since it is way better parallelized tham Exim is > (exim's disadvantage in this regard doesn't show as blatantly on a very > busy system with a full queue). For the record (as the only active maintainer of postfix), I am super happy that postfix is NOT the default MTA. There are enough bug reports as it is. One additional point that I have not seen mentioned is the cognitive load associated with team maintenance. Almost all the packages are team maintained and that's great for things where we have general consensus on how to go about things (like Python packages, where most of my work is), but having multiple maintainers also then requires coordination and resolution of disagreements. For postfix, I prefer that I don't really have to deal with that. If something's broken (in a violates policy, breaks things for the user kind of way), I don't mind NMUs if I'm not paying attention (that does happen sometimes), but the original maintainer of postfix (lamont) made some opinionated choices about the package that I think it's not practical to undo now and I am glad I don't have to argue with people about that (much). Scott K signature.asc Description: This is a digitally signed message part.
About Package Maintenance (was: Question to all candidates: What are your technical goals)
This is the continuation of a thread from debian-vote, that originated
from a question about technical goals to the DPL candidates
(https://lists.debian.org/debian-vote/2024/04/msg4.html).
I will try to quote generously to deliver context.
On Thu, Apr 04, 2024 at 12:38:34PM +0200, Andreas Tille wrote:
> Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
> > On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> > > I see a big problem that we do not follow common standards. While we
> > > have some teams with strict policies setting those standards internally
> > > to a different level of strictness there is no Debian wide consensus
> > > about things like
> > >
> > > A. Packages should be maintained on Salsa
> > > B. Lets use dh (if possible - I was told there are exceptions)
> > > C. Commit to latest packaging standards
> > > D. Make more than one person responsible for a package
> > > E. General QA work of contributors not mentioned as Maintainer /
> > > Uploader
> > >
> > > [I will reference these items below by their letters]
> > >
> > > I'm addressing this in the paragraph "Packaging standards" of my
> > > platform. I'm also very concerned about packages who don't get
> > > any attention any more ("smelly packages") which has two major
> > > reasons:
> > >
> > > 1. We do not have contributors with free capacity to care for
> > > problems in other peoples packages
> > > 2. Even if we had those the strict ownership of packages pevents
> > > that new contributors can step in. When reading the paragraph
> > > about NMUs in developers reference[1] this is probably
> > > sensible for actively maintained packages - but what about
> > > those packages which do not show any activity for years?
> >
> > I think this can't just be seen by looking at the statistiks. Many small
> > packages do their job and don't need constant attention as long as they
> > still build and work.
>
> I agree that pure statistics is not telling the whole story. However,
> those statistics give some feeling about the issue which for sure needs
> to be verified on case-by-case basis. I can assure you that I usually
> inspect the list of smelly packages[1] whether there are hits for my
> name (currently one false positive and one package where I'm forced to
> use cdbs) but also look for packages I might be able to salvage from
> there. I've found some impressive hits for this purpose in the past
> that are supporting my point besides stupid statistics.
I agree with your reasoning here, and I don't see an attack against my
packaging practise here. It is important feedback to me that will help
me to adjust my view on my duties as package maintainer.
[apg, console-log, dnstop]
> > Those three packages I decided not to put work into until there is a
> > technical reason for doing so. I do have all three on the radar and they
> > will properly move to salsa and be modernized once there will be a
> > change to the code or an RC bug regarding packaging. Until then, I have
> > more important things to do.
>
> Thanks for going into detail about these which I neither wanted nor
> expected in this granularity. I had no doubt that there are more
> important things for you. I honestly tried to investigate by using
> these examples is the following: In case there might be people out
> there who have time and energy to fix this kind of things, how can we
> enable them to take this work from your shoulders to enable you
> concentrating on more important stuff.
I'm always open to patches, MRs or more involvement of more people. I
doubt that thos three packages are going to get any in the future, and I
surely hope that any external help that I might get from others will be
regarding more important packages that I maintain like sudo or adduser.
I would like to elaborate a bit about adduser, where team collaboration
has worked like a charm.
I seldomly set myself in the Maintainer field any more, even if I am the
only person who has worked on the package in years. Having a
packages.debian.org mailing list in the Maintainer field enables random
people to subscribe to the full stream of package-related e-mails, which
allows interested parties to just peek in and see what's going on, and
also allows inofficial team building. For my most important packages, I
write about my plans to package@p.d.o and am soliciting for comments,
and I still do this while I know that I am mostly talking to myself.
In adduser, this has enabled two people to informally joint the team and
directly contribute. Sadly, both persons are gone again, but they have
left impressive amounts of code and a test suite which now enables me to
make changes to adduser without being afraid of breaking things badly.
> > policyrcd-script-zg2 I should modernize and upload. A few people seem to
> > actually use this, and it helps getting rid of the discussions whether a
> > distributio should start a
