Hi,

in the light of the previous discussion I have a question to all voters.
Due to bug #1066377 more than 30 testing removal warnings hit my mailbox
today (I stopped counting after 30). While the Debian Med package
clustalo is the only package that's responsible for this due to its Build-Dependency from libargtable2-dev there is quite some dependency
tree inside Debian Med team also affecting packages relevant for
COVID-19 etc. This small lib is not a key package which is important
for all things I'm writing below. Its used as Build-Depends by 6 other packages.

Our always busy team member Étienne Mollier provided a patch 10 days ago (thanks again Étienne). The package had its last maintainer Upload

-- Shachar Shemesh <shachar@debian.org> Sat, 16 Jul 2016 20:45:15 +0300

(Shachar in CC) and a NMU

-- Holger Levsen <holger@debian.org> Fri, 01 Jan 2021 17:15:04 +0100

(reproducible build, no changes - in other words no problems since
2016). However, the BTS view of Sanchar might hinting for some
inactivity when looking at two RC bugs in other packages:

#965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm
#998987 [src:privbind] privbind: missing required debian/rules targets build-arch and/or build-indep

As I wrote to Marc here on this list also the explicit hint to Shachar:
Its not about blaming you - I just want to analyse the current situation
to act properly. Given that you had no capacity to respond to two bugs
that are RC since 2 years makes me wonder how long I need to wait for
your OK to a team upload I'm proposing below. I'm perfectly aware that
we as volunteers can't be blamed about those things. I simply want to
find new ways how to deal with those situations appropriately.

Am Thu, Apr 04, 2024 at 12:38:34PM +0200 schrieb Andreas Tille:

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

1. Fix vcs_url + vcs_browser (A.)

I moved the package to salsa[1] and added VCS fields

2. Fix some bug(s) (E.)

I applied the patch from Étienne.

3. Runs Janitor / routine-update which changes (C.)

I was running `routine-update -f`

4. Converts to dh (if not yet which I did not checked) (B.)

I removed debian/autoreconf.* files which were unneeded with latest dh
compat level (and routine-update is doing this).

5. Turn d/copyright into machine readable form (if not yet which
I did not checked) (C.)

Secure URI in copyright format

6. Finds a team where the package fits into moves the repository
to that team space and moves you to Uploaders (D.)

I simply sticked to debian/ since I have no idea what team might fit.

I forgot
7. Add autopkgtest

I admit I did not spent time into this.

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.

I guess this is fulfilled.

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.

Shachar is in CC of this mail.

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.

Sorry again for just picking this example which is attached to you
(Shachar). I neither wanted to blame Marc about anything in my previous
mail nor you in this mail.

Its simply the kind of thing that is creating a lot of stress in our
team. I could follow the normal NMU procedure but I do not consider
this a sustainable solution. It took me about 10-15 min in my lunch
break to bring the package into a shape, where other people are able to
commit in a convenient way (Salsa, latest packaging standards).

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?

I did not uploaded my work but I would like to know what action is
considered acceptable by the voters. I repeat that the package is no
key package for which I would not consider what I did above. Please
simply fill in the form:

[ ] Its not acceptable, don't do that
[ ] We should discuss this on debian-devel, possibly do some GR
before things like this are permitted
[ ] Wait one week before uploading
[ ] Wait one day before uploading
[ ] Just upload provided you care for any break your action might
have caused.
[ ] ???

What do you think?

Kind regards
Andreas.

[1] https://salsa.debian.org/debian/argtable2

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)