Re: Questions about "Winding down my Debian involvement"
On 15347 March 1977, Andreas Tille wrote:
Recently I've read the article "Winding down my Debian involvement" from
Michael Stapelberg[1]. I consider that article an interesting reading and
I would love to hear the opinion of the candidates about it.
I read it and it influenced parts of my platform.
1. I followed the hint to rsync checked out the source package have
read the 6k d/rules of it. In line with the request for modernisation
I wonder whether the candidates see any chance to convince
maintainers to stick to some standard like debhelper >= 9 as a
recommended build tool. (Rsync is just a random example - I have
seen several other packages that made my work as bug hunter harder
than necessary and I know efforts like cross building which would
profit heavily from some unification.)
While it seems nice that every maintainer can, more or less, do what
they want in their package, as long as the outcome fits the usual policy
stuff, I agree that we should get rid of parts of this. More unification
in central parts, with the biggest part being packaging, is better.
OTOH we need to stay open for enhancing things. So while I am a fan of
"dh for everyone, throw away all the hand crafted stuff", it should not
make it impossible to come up with new stuff in the future.
2. I consider packaging in Git on salsa.debian.org a big move
forward to some unified workflow for Debian packaging (thanks to
Salsa admins by the way). Do you see any chance to convince
maintainers to maintain their packages on salsa.d.o as a
recommended development platform.
I would actually like if we end up with a "git push turns into an
upload". Which would need some central $thing for it to make it so. Not
sure thats salsa. Or something seperately (but maybe together with it).
Aside that, yes, the more stuff is similar, the better and easier larger
changes can be done. Though salsa or not is a small point here. How many
different ways of maintaining a package in git do we have by now?
Driving something here to end up with one, now that would be good. Also,
something that shouldnt be the DPLs job - but the DPL may need to help
out with communications, delegations, support (say, meetings and cost
for them).
--
bye, Joerg
Reply to: