[snipped everything that I don't have an answer for. Neither removal nor
quoting is endorsement or reject of what Andreas said.]
On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
> Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
> > There are many people who see Debian as a technology project, with the
> > technical goal of producing The Universal Operating System.
> >
> > What are you planning to do to Debian from a technical and technological
> > point of view? What do we well, where do we suck on the technical site?
>
> 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 notived you are maintaining
>
> select count(*) from (SELECT DISTINCT source, maintainer, uploaders,
> vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike
> '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like
> '%salsa%') tmp;
> 20
>
> packages on Salsa in various teams. Great! You also have
>
> udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources
> WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike
> '%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
> source | maintainer |
> uploaders | vcs_browser
>
> ----------------------+----------------------------------------------+-----------+--------------------------------------------------------------------------
> apg | Marc Haber <mh+debian-packa...@zugschlus.de> |
> | http://git.debian.org/?p=collab-maint/apg.git;a=summary
> console-log | Marc Haber <mh+debian-packa...@zugschlus.de> |
> | http://git.debian.org/?p=collab-maint/console-log.git;a=summary
> dnstop | Marc Haber <mh+debian-packa...@zugschlus.de> |
> | http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
> policyrcd-script-zg2 | Marc Haber <mh+debian-packa...@zugschlus.de> |
> | http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
> (4 rows)
>
> I verified on Salsa that all those are imported to debian/ name space on
> Salsa (which is also great - I have seen lots of other packages who are
> not imported to Salsa). It would help if you could sooner or later
> consider uploading those packages.
apg has a dead upstream and will probably have to go. Two years ago, I
decided to move the package to salsa to have it available for reference.
In parallel, I queried the maintainer of the least dead github fork
whether they are planning to take care of the upstream, received no
answer. The only commits that are not in the package are of cosmetic
value and I do not much believe in doing an upload (wasting buildd
resources, mirror bandwidth etc) just for the sake of those cosmetics.
console-log is little more than an init script that needs serious
rewriting to be usable on a systemd system. Probably also a candidate
for removal. I was not aware that Jelmer put the sources on salsa, I
appreciate their efforts.
dnstop I should probably either put up for adoption or have removed as
well. It hasn't seen a release in a decade, the last commit upstream was
two years ago, and I am not running DNS server at scale any more. Also,
I was not aware that the repository was put on salsa by Jelmer, probably
we shold have a mechanism to keep the maintainer of the Debian package
posted when something like that happens.
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.
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.
> When seeking for other reasons I've
> found 11 bugs via
>
> udd=> SELECT id, package, source, arrival, severity, title FROM bugs WHERE
> source IN (SELECT DISTINCT source FROM sources WHERE release = 'sid' and
> (maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND
> vcs_url not like '%salsa%');
>
> which I will not list here to not lengthen this mail. My guess is you
> are aware of this but have reasons / time constraints to not act for the
> moment.
Those bugs are either wontfix, or already fixed in git (not yet uploaded
because cosmetic), or neglected, right.
> 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.)
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.
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. I might look like a rotten maintainer when you look at my oldest
packages, but I am usually responsive when I get poked.
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.
> 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.
> > 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", "we
replace exim with postfix as the default MTA", "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.
> > 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, 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. 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.
> > Thanks for your consideration to answer these questions despite
> > platforms containing language about this topic.
>
> 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.
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
