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.
