Re: Working on debian developer's reference and "best packaging practices"
On Mon, May 06, 2002 at 06:11:46PM +0100, Julian Gilbey wrote:
> On Fri, May 03, 2002 at 08:02:50PM +1000, Anthony Towns wrote:
> > I'm concerned about this because when I tried passing over
> > "release-critical policy issues" to the policy group, it didn't work. [..]
> Strawman (to quote lots of others). As a concept, it's very good, but
> as we discovered, the implementation was poor.
As a concept it sucked, we just didn't realise it at the time. -policy
isn't competent at judging which issues should be release critical. We
didn't realise this before we tried, no we have tried and it's blatanly
I'd suspect the reason it doesn't work is because there's no downside
for -policy to making a rule a release-critical issue, compared to not
doing it. You guys don't have to try to coerce people into fixing their
RC bugs in a timely manner, nor throw out packages that don't have their
RC bugs fixed, nor deal with the people who absolutely need the package.
The only downside has been that if you try adding a release critical
requirement, I'll jump down your throats. And that doesn't have any wins
over me just deciding which issues are RC and which aren't.
> My suggestion for a
> policy rewrite it to move to the standard RFC uses of MUST and SHOULD,
> and indication RC-ness in an orthogonal way.
In short, this isn't going to happen. There'll be a separate document,
maintained by the release manager. It may or may not be included in
debian-policy.deb. I'm inclined to think it'd be better if it were in
that package, but we'll see.
> > Further, considering that everyone seems to think that the -policy
> > group have done pretty poorly at their actual job -- maintaining
> > the policy document so that it's readable, consistent and useful --
> > it doesn't seem like a good idea to broaden its scope. Rewriting it
> > into something comprehensible, making the already approved of changes,
> > and merging all the subpolicies (at least debconf, perl, and python)
> > is likely to be more than enough work for the forseeable future.
> Thanks. Appreciated. We need to rewrite policy, and have known this
> for absolutely ages, but when it absorbed the old packaging manual, it
> introduced the contradictions (oops). I vaguely recall that at that
> time, a freeze was effectively placed on substantially rewriting
> policy because of the upcoming freeze of woody.
This was about six months ago, and you and Manoj were too busy to do
anything at all about it (and there aren't any other active policy
editors to do it). The packaging manual was included about four months
earlier than that. It doesn't really matter. Doing a good rewrite of
what's currently in there, incorporating all the separate mini-policies
that're about, and adding all the new policies that need to be added
will be a lot of work, even without trying to make a "dpkg standard".
> We are still in this
> freeze period, and both Manoj and I are itching to rewrite the current
> spaghetti which is called policy.
So start. Rewriting means no changes to the substance anyway (or so I'd
assume), which means there aren't any problems at all with it as far as
I'm concerned (with my release manager hat on).
Anthony Towns <firstname.lastname@example.org> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org