Hi Marc,
Post by Andreas TilleI 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
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.
...
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.
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.
I simply wanted to discuss existing examples instead of statistics.
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. In the said cases it would
specifically helpful to fix VCS information since it is very important
information for other Debian contributors. 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.
Post by Andreas TilleWhat would you think if someone would push the following
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
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.
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.
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.
but I am usually responsive when I get poked.
I'm perfectly sure about this.
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?
Post by Andreas TilleAssume 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
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.
Post by Andreas TilleWhat 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. 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 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.
"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.
"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).
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.
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.
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.
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.
Post by Andreas TilleAre 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.
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.
Post by Andreas TilleI 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.
Kind regards
Andreas.
[1] https://trends.debian.net/packages-with-smells-sorted-by-maintainer.txt
[2] https://news.ycombinator.com/item?id=19311345
--
https://fam-tille.de
