Re: Question to all candidates: What are your technical goals
[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 |
>| http://git.debian.org/?p=collab-maint/apg.git;a=summary
> console-log | Marc Haber |
>| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
> dnstop | Marc Haber |
>| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
> policyrcd-script-zg2 | Marc Haber |
>| 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 packa
Re: Question to all candidates: Bits from the DPL?
> "Andreas" == Andreas Tille writes: Andreas> I was told in private that a daily log in Git might be a bit tough but Andreas> I hope to manage. I consider it a good preparation for the monthly Bits. I think I recall inheriting some infrastructure from Chris for maintaining some DPL news that was accessible to DDs or to future DPLs or something, but not in git and not public. Ah, yeah, master.debian.org:/srv/leader/news I used it sometimes, but definitely not daily. I think Chris used it more effectively. I don't remember how I tracked what to cover in my bits emails. I think I did look at the news files, and I also just had a few issues I knew I was going to cover. I also looked back at lea...@debian.org mail to see if there were things happening that I should boost. --Sam signature.asc Description: PGP signature
Re: Question to all candidates: What are your technical goals
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 |
| http://git.debian.org/?p=collab-maint/apg.git;a=summary
console-log | Marc Haber |
| http://git.debian.org/?p=collab-maint/console-log.git;a=summary
dnstop | Marc Haber |
| http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
policyrcd-script-zg2 | Marc Haber |
| 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 w
Re: Question to all candidates: Bits from the DPL?
Hi Lous-Philippe, Am Tue, Apr 02, 2024 at 04:05:21PM -0400 schrieb Louis-Philippe Véronneau: > Jonathan's latest "Bits from the DPL" entry reminded me of how much I like > those :) > > What are your thoughts on the format? > > If you are elected, do you plan to publish regular "Bits"? If not, how do > you plan to communicate with the rest of the project with regards to the > work you are doing? Quoting my platform: I intend to maintain a daily log in a public Git repository, provided the information can be shared with a public audience. Additionally, I will send a monthly summary to debian-devel-announce to keep you informed about my activities and progress. I was told in private that a daily log in Git might be a bit tough but I hope to manage. I consider it a good preparation for the monthly Bits. Kind regards Andreas. -- https://fam-tille.de
