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/msg00004.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 daemon right after package installation
> > (which we do, and Red Hat based distributions don't, causing irritations
> > by people accustomed to Red Hat working with Debian). You got a point
> > here.
>
> As I said I did not wanted to make a point about your maintainership.
But I did want to make a point about my maintainership. Your feedback is
appreciated, and you made me think about things.
> > Those bugs are either wontfix, or already fixed in git (not yet uploaded
> > because cosmetic), or neglected, right.
>
> I personally tend to upload when I've fixed some bug in Git (even when
> cosmetic) to remove noise from BTS.
That's a tradeoff that I usually adjust differently than you do, I
rather dont cause noise in the archive just to reduce BTS noise. But
that's a matter of style, either way is the right way to do ig.
> In the said cases it would
> specifically helpful to fix VCS information since it is very important
> information for other Debian contributors.
You have a point here.
> 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.
This is by the way one of the reasons why I usually ask contributors to
"my" packages to refrain from committing to master/main since an the old
fart I am, I quite often don't go the way everybody does. I'd like to be
able to say "no", if I am the one to be yelled at if something goes
wrong.
> > > What would you think if someone would push the following
> > > commits and uploads to unstable:
> > >
> > > 1. Fix vcs_url + vcs_browser (A.)
> > > 2. Fix some bug(s) (E.)
> > > 3. Runs Janitor / routine-update which changes (C.)
> > > 4. Converts to dh (if not yet which I did not checked) (B.)
> > > 5. Turn d/copyright into machine readable form (if not yet which
> > > I did not checked) (C.)
> > > 6. Finds a team where the package fits into moves the repository
> > > to that team space and moves you to Uploaders (D.)
>
> I forgot
> 7. Add autopkgtest
By all means go ahead with that, immediately ;-)
> > 1-5 are just fine. That's what git is for. Either fork the project,
> > commit changes, file an MR, or (dor a repository inside the Debian/
> > space), commit to a branch, file an MR.
>
> Thank you for your opinion. It is very valuable for me to learn what
> people consider acceptable. I assume you would consider 7. fine as
> well.
Yes, 7 is the same category.
> > Personally, I do prefer having the last word to say what gets into
> > the master/main branch and I'd like to at least be consulted before an
> > upload.
>
> If no team is specified this is definitely default behaviour.
In my packages, you can see who's "formally" on the team by looking at
the Uploaders field. I have elaborated about my use of the Maintainer
field already.
> > I might look like a rotten maintainer when you look at my oldest
> > packages,
>
> Absolutely not. When digging into the said resources I have seen way
> worse. I'm not here to blame anybody. I'm seeking for solutions.
I don't see blame by naming things like they are. No offense taken here.
> > 6 I would find too intrusive without talking to me first. It's a slap in
> > the face, I would probably drop the package as a kneejerk reaction.
>
> Talking to you is mandatory. I know you for a long time as helpful and
> responsive on mailing lists. But assume we are talking about someone
> who does not respond (for whatever reason). Could you imagine some
> scenario where 6. would be acceptable?
Of course there is a scenario, but we have the salvage process for that,
don't we? If the maintainer is MIA for years, I'd probably write a last
message, with a timeline of two to four weeks. If the package has been
unmaintained or NMU-maintained for years, another month doesn't hurt.
Also, the DELAYED queue is a great tool for that. Maybe we should have
DELAYED queues for 14, 28 or 90 days as well.
> > > Assume you will be asked about those changes but you have no time
> > > to answer (for whatever reason). What of those changes is OK for
> > > you and how long would you expect the potential contributor to your
> > > packages to wait until taking action?
> >
> > I think that strongly depends on the severity of the issue being worked
> > on. A security-related thing an appropriate waiting period is probably
> > "tonight", an RC bug a few days, and a cosmetic thing like a Homepage:
> > field probably never unless somebody is fixing something more important
> > anyway. And, otoh, it is clearly inappropriate to have a package
> > maintained via NMUs for a decade.
>
> I've seen packages with 10 year NMU history.
So did I, and that was the case I meant above. "A Decade" means ten
years in English, not ten days, right? I apologize for the confusion.
> > > > What is your position about technical leadership?
> > >
> > > IMHO we could gain/keep technical leadership if we would manage to apply
> > > our technical standards to all the things we consider important.
> >
> > Oh, I don't mean the technological lead as in "we're going ahead and the
> > rest follows", as it was around the Millennium (we have lost that
> > momentum with sarge or so).
> >
> > When I say "technical leadership" I mean things like "we're going
> > systemd", "usrmerge", "we want all initscripts to be gone by X",
>
> That's a tricky question but thanks for it.
Of course it is tricky ;-)
> I'm personally not sure
> whether it is of advantage for Debian to simply be the first
> implementing those changes. I think it is good that major distributions
> settle with the same techniques in the long run to avoid defraction of
> the Linux ecosystem in general. I do not consider it positive or
> negative to be the first implementing changes that are potentially
> breaking things at user side.
We have become the "follower" over the last 20 years, being late in
adopting changes after having a month-long public fight, press coverage,
and losing a measurable fraction of our personpower in the process.
I would love Debian to be seen again for its technological lead. It has
been proven over the last 20 years that the public thinks that we can't
get our release cadence right: First we released to slowly, and now that
have sorted out to release about every two years while still keeping our
"when it's ready" mantry, there are people who say we release too often,
which has prompted the LTS and ELTS projects (which is good), but has
also caused people breaking their systems by trying the unsupported way
of upgrading oldoldstable to stable without going through oldstable
first (a scenario which is reealistic in times of LTS and ELTS but we
neighter officially support nor test).
> We also need to keep in mind that we lost
> respected developers in connection with the systemd decision. Thus
> beeing conservative to some extend while not stopping progress on the
> other hand sounds like a strategy I would not question in principle.
> Debian is just huge. Changing a huge system by also keeping the lots of
> derivatives in mind takes time. This starts with finding some consensus
> between Debian developers that might take longer than in other
> distributions and is possibly the nature of Debian I do not intend to
> change.
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.
> > "we replace exim with postfix as the default MTA",
>
> Ahhhh, 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).
>
> > "we now use Wayland
> > instead of X11", "please don't create your system users with adduser and
> > more, use a declarative approach".
> >
> > At the moment, we simply dont take such decisions. I think that's a
> > problem.
>
> I think I get your point now. Thanks for these examples. You might
> have a point in these specific ones but I see Debian leading in other
> aspects.
>
> As far as I know other major distributions do not undertake the time_t
> 64bit transition (whether this marks leadership or not is questionable
> but it will make us the leading distribution on those architectures in
> future).
The time_t64 migration is indeed a topic where I see Debian - finally -
leading things again, making it easier because of our superior tooling,
and I am quite excited to see the thing progressing so smoothly.
Reproducible builds is another field where we're doing exceptionally
well, but both of those topics sadly are of lesser interest to the
decision makers in the organizations.
Otoh, we still have a horrible mess of init scripts and systemd units,
packages that offer both, with the init script in various stages of
bitrot.
> I'm not well informed about other distributions but seeked the internet
> and for instance found some article about reproducible builds from
> 2019[2] where Debian and ArchLinux are mentioned frequently but Fedora
> is not. I've picked that older article since taking the lead means who
> started that effort and I think we are in this game.
>
> Apropos ArchLinux: I would love if Debian would manage to craft such a
> great documentation in Wiki. That's not a "technological" lead but
> we've lost the lead in documentation by far which is in my perception a
> weaker point than the time we adopt one or the other technical change.
Indeed, ArchLinux is famous for its documentation, and I am actually
wondering how much personpower goes in to their wiki. They're so far
ahead of us in the documentation department that we're unlikely to catch
up soon regardless of how many talented technical writers we manage to
recruit.
> I think we are doing a good job regarding CI with adding autopkgtests
> (but we could do even better for sure). I'm not informed about the
> status of CI in other distributions and whether there exists something
> like Salsa CI. I'm positively convinced that Debian has reached a level
> of complexity which makes CI tests mandatory for every important package
> and I would love if we could do the lead here.
We don't have good enough documentation and - more important -
boilerplate code to copy from. I mean, adduser is easy to write tests
for, but already writing tests for sudo is way harder. I literally spent
days to figure out how to best fire up an appropriately initialized LDAP
server for testing of sudo-ldap.
If I could write a Wishlist, autopkgtest infrastructure would be high on
that list. For example, wouldnt it be nice if it was just a single line
in the autopkgtest definition to fire up an instance of $DATABASE with
given test contents, and also infrastructure to build that database
locally and to be easily able to freeze the contents in a state where
autopkgtest can start from?
And, I still don't have the slightest idea, for example, how to
autopkgtest an interactive application like aptitude, a GUI application
like knetworkmanager or a web app.
> I consider archive wide rebuilds as done by Lucas Nussbaum a great
> feature to ensure the quality of our distribution.
>
> To my (possibly wrong) perception Debian is pretty quick in adopting and
> supporting new architectures. This is also possible due to the cross
> building initiative some developers are very active in.
Still, not many embedded projects use Debian.
> I also want to mention UDD (you have seen that I'm a big fan ;-)) I'm
> not aware that this exists for other distributions and IMHO it has a
> great power for a lot of purposes (like tracker.d.o etc.)
>
> What I want to say is: If you look at the shiny marketing side it might
> be that we are slower adopting some technologies than others. But
> technology is not a one dimensional thing where you can pace a race in
> one direction. I think its spreading a multi-dimensional room which we
> are leading in some dimensions and move slower in other dimensions.
We need both. Including shiny marketing slides. I'm so tired to work in
places where RHEL is bought "because of the support", which is in turn
never invoked because they just say "your setup isn't supported, you're
on your own" and every day I find myself sighing about how easy $TASK
would be accomplished on Debian.
> > > > Are our technical
> > > > decision-making processes up to today's challenges?
> > >
> > > Would you mind clarifying this question? We have the CTTE as
> > > decision-making instance but I'm not sure whether you are refering to
> > > this.
> >
> > The CTTE is a tie-breaker which is only invoked to resolve a fight. And
> > if invoked, the decision takes months. In other sitations, we keep
> > fighting in the open, probably doing a GR, which makes the news even
> > before we have decided anything.
> >
> > That's the price we currently pay for being not a commercial entity,
>
> I fully subscribe to this statement.
>
> > so
> > that we don't have a project leader who has the power to say "we're
> > going to do X", like the board or the managing director of a commercial
> > company has.
>
> I consider the DPL as a "Leader with no power". Convincing a huge
> number of volunteers to pull a string into the same direction is a way
> harder job than telling employees of a company what to do next. I'm
> aware of this challenge.
We're getting to the core here.
Some part of me feels that we need a decision-making body taking those
decisions wihout going through weeks of GR discussion and voting, making
us end up with a compromise that nobody likes and makes ten more people
leave. Otoh, I am fully aware of the "you can't force a volunteer to do
things", knowing that I myself would be the first one to violently
oppose a decision that I don't like while - at the same time - being
mad at some core package maintainers who have forced the project to jump
through even more burning hoops to finally get the usrmerge migration
(which we didn't choose doing, but need to do because another of our
core upstreams wanted us to).
That's why I am just a technologist and not a politician.
> > Seriously, I don't how Fedora takes their technical
> > decision, but there has to be a reason why they're so far ahead of us
> > technologically.
>
> I need to admit that I (currently) don't know much about Fedora (but I
> hope I could fix this in the near future). At Chemnitzer Linuxtage I
> took the chance to talk to OpenSUSE and Nix about organisatorical
> solutions. There was no booth by Fedora I could show up.
I once more didn't make it to Chemnitz this year, despite having a
non-refundable train ticket and a booked hotel room.
> > > I hope this answer contained the amount of details you were expecting.
> >
> > It does, thank you. And sorry for the misunderstandings I might have
> > caused by my badly worded questions.
>
> No need to be sorry. I think the discussion is interesting anyway.
> Thanks a lot for beeing that verbose in your question.
I am finished with rambling for today. Thanks for your time.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Reply to: