Hi Marc,
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?
> If we do suck in some technical points, what are you planning to do to
> improve those things?
I would love to see that maintaining packages on Salsa becomes mandatory
and I wonder what might be the best way to approach this. We might
start with some GR about it. But perhaps it is better to start talking
to people. I use UDD as my reference and since I want to hear your
personal opinon I'm just querying for your packages. Its definitely not
about you personally - just a nice example.
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. 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. 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.)
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?
> 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.
> 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.
> 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.
I'd be really happy to start discussing things even here on vote and
I'll give some kind of summary on some more appropriate place later.
Kind regards
Andreas.
[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
--
https://fam-tille.de
