Re: Questions about "Winding down my Debian involvement"
Hey Andreas
On 2019/03/21 09:38, Andreas Tille wrote:
>> 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.
<snip>
Yeah sorry, I got my mind wrapped up in that makefile and lost track of
the bigger picture, but your follow-ups brought me back on track...
>> 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. ;-)
:-)
>> 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:
Well, I really do like the idea of starting with some project-wide
consensus and putting it in policy first and implementing some release
goals, so with that in mind...
> 1) Who explicitly do not want any change.
I would start by asking them why they do not want this change, there may
be a legitimately good reason why they don't want to change. If it's
that modern package build systems don't cover their use case, I would go
with filing bugs against things like debhelper and cdbs.
If they're reasoning comes down to preference, I would remind them that
as a project we've agreed to move in a certain direction to make it
easier for everyone, and would ask them to reconsider.
If they're scared that something would break, I would listen to their
concerns, but also at the same time show them a working version. Also, I
would make the argument to them that the make files using the modern
build systems are a lot less error-prone since it contains a lot less
snow-flake code and is also less prone to human error and easier ot
maintain.
Failing all of that, if we have it as a release goal to use modernised
build systems across the project, than it doesn't seem inappropriate to
file an RC bug against their package.
> 2) Do not respond (but beeing not officially MIA)
If it has large-scale agreement and policy around it, I think it's
reasonable to file that RC bug and if they don't respond, do either an
NMU or package salvage, whichever is more appropriate.
Ultimately I think we want to be a project that's responsible for our
work and how we go about it, if a maintainer isn't interested in working
with the Debian project as a whole, even when it doesn't impose problems
on them, then that's a problem.
>> 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).
*nod*, it's kind of amazing how many packages aren't even in VCS right now.
-Jonathan
--
⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) <jcc>
⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage
⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org
⠈⠳⣄⠀⠀⠀⠀ Be Bold. Be brave. Debian has got your back.
Reply to: