Advice for how to make new things policy (was: ':any' syntax in package names in jessie/sid Packages)
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
Reply to: