Hi all, Quoting Stuart Prescott (2014-04-20 16:58:21) > > As xnox says there is still some pending changes around the interpreter > > problem, as described here: > > https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges > > > > And that debate is part of the reason this stuff hasn't been > > considered 'finalised' and thus ready for policy. But I think the core > > stuff is now well-enough used that at the very least policy should not > > be inconsistent with it. > > pending changes, things still to be finalised, undocumented syntax changes > being pushed into jessie that broke wheezy→jessie upgrades (which had to be > fixed in both dh_python{2,3} and also required a stable update to apt > [1])... this worries me. It feels like it is being done backwards. > > This is the exact situation where I would like to see policy lead the way > and be part of the process to design and codify things *before* we start > implementing them on 21k packages. This is a general comment, not just about > multi-arch -- our policy editors have a huge amount of experience in > developing technical policies and documentation to go with them. Making use > of their expertise at the design stage would be much better for the project. > Currently, the project seems to tend towards policy documenting current > practice rather than policy leading us towards better (best!) practice; this > culture means that improving things can be very hard because you may have to > become policy non-compliant in order to develop the new "standard practice" > to then seek a change in policy. (And as observed recently, this also means > that when given a choice between A and B, we end up choosing A, B, C and Z > [2].)
One thing that makes me personally like to contribute to Debian in contrast to other distribution is how much importance is being put on the Debian policy and how well everything is documented in it. I was very alienated when I found that something as "important" (well at least from the point of view of stuff that I'm working on) as multiarch is not documented at policy at all but just in the Ubuntu wiki. Now together with wookey I have been pushing the build profile syntax extension [1] forward and while it is already integrated in a number of important tools (dpkg, apt, debhelper, lintian) it is also not yet in policy. The only available documentation sits at [1] and is not even finished yet because of a missing issue I raised at [2]. I would really *love* to have build profiles in policy but how to proceed without the spec even being finished yet? How to finish a spec? How to get input from enough relevant people and people who know what they are talking about? I should at least get approval of dpkg maintainers before I document a Build-Depends syntax extension, right? And if a decision is taken elsewhere, should dpkg maintainers who probably know best not have a veto? On top of that there is yet another thing (potentially another build-depends syntax extension, yes I know everybody must hate me now) that I want to discuss on dpkg-devel. And for that I want to take the way most accepted by the project. Should I first discuss it on debian-devel even though (as it happened with build profiles) dpkg maintainers will make the final call anyways? I wholeheartedly agree with Stuart's email. I would love to see policy lead the way. But as somebody who comes up with new things that might end up in policy: how to proceed? My current approach is to write countless mails to dpkg-devel and over time, an agreement is formed, things get implemented in dpkg and others follow because if dpkg does it, then it's probably nothing too wanky. But that's not the process I'd like to follow. How to turn it around? I also fear that turning the process around produces too much bureaucracy at the expense of finding a technically excellent solution decided by the people who have most experience? Is it not the way of Debian as a do-ocracy to first have the tool support decided by the people maintaining the tool and *then* the policy after stuff works? Maybe there is a middle ground? cheers, josch [1] https://wiki.debian.org/BuildProfileSpec [2] https://lists.debian.org/debian-dpkg/2014/02/msg00029.html [3] https://wiki.debian.org/HelmutGrohne/MultiarchSpecChanges [4] https://wiki.debian.org/Multiarch/InterpreterProposal -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140420175357.21059.78687@hoothoot