Thanks for this interesting discussion. I think it's an important one to have, too. Generally speaking, Debian needs a way to promote best practices, because there *are* practices that are better than others and uniforming on them is a way to both improve the quality of our maintenance work and reduce barriers to contributions (because learning one practice you can then contribute to many packages, as opposed to having to learn many different practices to contribute to different packages). The underlying question here is *where* Debian should do that. For one thing, according to the customs of the Policy editors, the Policy is not such a place. Policy rules on something when it's already the de facto standard in the archive, to have a process that makes what is not following it already converge to it (Russ will surely correct me on this point if I'm wrong). The Developer's Reference is possibly a good place, and has been used in the past to promote best practices: the example of DEP-1 and NMU rules comes to mind. The problem with devref is that it's not directly actionable: we can edit the devref and amend it, but noone will notice until much later. Also, using only the devref is very far from hacker's practices. What we do want to be notified of best practices, is a sort of "test suite" that yells when we are not following them, as in test harness situations. I.e.: something very similar to lintian :-) On Fri, Mar 29, 2013 at 01:28:29AM +0100, Niels Thykier wrote: > I am not sure we can in general promote the use of 3.0 (quilt) over 1.0 > via Lintian at the moment[1]. […] > [1] Basically it is the same reasons as mentioned in #702671. If I'm not mistaken, that reason is the following, right? ------------------------------------------------------------------------ Russ Allbery wrote: > I agree, but that's not really the point -- the point, rather, was > that several long-time DDs responded to the suggestion that it become > mandatory with quite a bit of outrage in debian-devel, and several > people said that they absolutely refused to add it. ------------------------------------------------------------------------ That kind of argument is very well-known, but I do question its validity. For one thing, IIRC the discussion Russ was referring to, it happened a long time ago, it might be time to reassess it. Second, the part "long-time DDs" is questionable, as their opinion is not necessarily more valuable than those of others. It *could* very much be, due to experience and capacities, but old-timers tend also to be much more inclined to stay put with old practices, which are not necessarily the best ones. Finally, there is the usual counter-argument that those vocals on lists are not necessarily representative of a majority of a population: they might be a strict, but very vocal, minority. Personally, I'd love if the lintian maintainers could assume their responsibility as promoting the adoption of best-practices. After all, it is you people who are the first steward of package quality, thanks to lintian. As a developer I'd have no problem whatsoever in trusting your judgement about that. And if I will ever find myself in disagreement I can either stop using lintian (with all the associated negative quality consequences), add an override documenting my disagreement, or try to convince you that you're wrong discussing in a bug report as we do for every other package. Failing that, we might consider delegating the responsibility of promoting best practices to the devref editors, and have lintian implement what is written in there. But that is a much more heavyweight process in terms of community costs and is more far away from hacker standard practices. As such, it has much less possibilities of having an impact onto best practices adoption in the archive. Hope this helps, Cheers. -- Stefano Zacchiroli . . . . . . . zack@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
Attachment:
signature.asc
Description: Digital signature