Re: Questions about "Winding down my Debian involvement"
On Wed, Mar 20, 2019 at 11:13:58PM +0200, Jonathan Carter wrote:
> I'm sorry if that's not the answer you were looking for, but that's how
> I generally feel about it.
I wasn't looking for specific answers. I was just interested in your
opinion. ;-)
There are different kind of texts in this direction. I simply think
this was one that is worth discussing (in contrast to others).
> > Besides your general opinion I'm interested in your opinion about some
> > questions that immediately popped up when reading the article.
> >
> > 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.)
>
> Just checked out that file, and at 98 lines, it's really not that bad
> for a really old pre-debhelper-7 style makefile:
>
> """
> Language Files Code Comment Comment % Blank
> ---------------- ----- --------- --------- --------- ---------
> make 1 98 18 15.5% 15
> ---------------- ----- --------- --------- --------- ---------
> Total 1 98 18 15.5% 15
> 131
> """
>
> I've recently adopted packages with worse make files than that and
> successfully converting them wasn't too hard.
I think the point of the writer which is perfectly in line with mine is
not whether the file itself is good or bad. The point was that the
maintainer actively refused modernisation due to personal taste. If we
think about Debian as a team of 1000+/-x people some specific personal
taste can block a lot of good movements. I'm speaking explicitly about
my experiences in a way smaller team where several modernisations were
initialised by new members and I as the longest standing member of the
team adopted modern things.
> So, to answer your question, I do think having a wide discussion and
> then some final decision for it scheduled would be useful. I wouldn't
> want to force dh9+ per sé (people still use CDBS and are apparently
> happy with it), but I do agree those old style makefiles are holding us
> back.
I do not want to turn this into a cdbs to dh flamewar. Before dh 7
Debian Med policy mentioned cdbs explicitly. We moved away to dh now.
I'm pretty sure the rsync maintainer would have refused a patch to
convert to cdbs as well. Several teams inside Debian have agreed to
team policies recommending modern tools to simplify the life of all team
members. I'd love to see something like this for the Debian Developer
team as a whole.
> I think a good way to go about it would be to propose that we have a
> recommended (not necessarilly required) set of supported build systems,
> and make it a release goal that we update all those really long make
> files to anything more modern, supported and easy to work with (well,
> basically debhelper :) ).
If there would have been any answer I was looking for than it was this
one. ;-)
> There's an idea I've been playing with in my head for the last few days,
> I call it "Fixer teams". These are teams of people that exist for a
> small amount of time to achieve a goal and then they disband.
>
> For example, we'd establish a fixer team that can help people who want
> to convert their old-style make files all the way to a modern debhelper,
> we do a call for volunteers for that team, and then announce it
> somewhere like d-d-a. The fixers can either check irc/mail for people
> who request this help, or they could check a bug list and recommend a MR
> on GitLab. Whether I'm DPL or not (or a fixer or not), I'm happy to help
> anyone who would like to update their package in the meantime.
Sounds like an interesting idea. You are talking about the people who
*want to convert*. Can you please be more explicit what to do in cases
where people:
1) Who explicitly do not want any change.
2) Do not respond (but beeing not officially MIA)
(I'm explicitly not "looking for a certain answer I want to hear" - I'm
just seeking for good ideas.)
> > 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.
>
> Yes! I do think GitLab/Salsa is one of the best things to have happened
> to Debian in recent history. I posted a blog post that touches on some
> salsa topics earlier tonight:
>
> https://jonathancarter.org/2019/03/20/gitlab-and-debian/
>
> I think "unified workflow" has good merits but putting it like that
> sounds scary and I can see how there will be some push back. I agree
> that it is a problem that there are nearly as many packaging workflows
> as there are teams, and that at least getting them all documented
> somewhere where they can be compared will make it easier to merge down
> all the similarities between them, and perhaps highlight the differences
> so that it's easier to eliminate some unneeded parts. After that you
> could perhaps end up with a common workflow and the teams that need
> exceptions can just add it to that workflow as addendums. With a process
> like that where it happens in quick-succession baby steps it may be
> easier getting large-scale buy-in / consensus for every step.
I personally see advantages even in a "unified workflow" but for the
moment the short term goal should be to have at least every package
there (and having all Vcs fields expressing this correctly).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: