[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Working on debian developer's reference and "best packaging practices"



On Mon, May 06, 2002 at 06:19:54PM +0100, Julian Gilbey wrote:
> > > Then each section could either have the structure:
> > >   Policy dictate s
> > >   Discussion, useful information, guidelines, examples
> > > or we could merge them, and have policy dictates all in the form MUST,
> > > SHOULD, MAY, MUST NOT, etc., as in the RFCs. 
> > I'm quite confident that trying to differentiate between requirements
> > and guidelines like this will turn out to be completely unhelpful and
> > a large waste of time, personally.
> Don't RFCs do this frequently?  And I've never heard people making
> such a complaint about them.

RFCs have a different goal to -policy. RFCs specify things that get
implemented by different groups and have to be interoperable. -policy
doesn't.

There is only one "dpkg", there is only one "apt", there is only one
"Debian", and the point of -policy is to make all of these more effective,
not to help random people with nothing better to do implement clones.

If we were doing the latter (and you and Manoj seem to want to wrt "dpkg"
for no reason I can fathom), then must/should would be useful. But
we're not. If people want to clone dpkg (or finish of libapt-inst so
it can actually install packages; or implement Herring (if anyone even
*remembers* it...)) then more power to them. If someone does do this,
then it might turn out that there are some incompatibilities that need to
be handled specially by packages, and we'll probably add these to policy
when we find them.

Maybe, some day, there'll be a handful of competing "dpkg"s and we will
need a standards document to say what constitutes a valid "dpkg", but
that ain't today. So why waste time on it?

> > > (As far as RC issues
> > > goes, this could be marked by (RC) after the MUST/SHOULD/whatever,
> > > with a catchall at the start of policy that the final decision on what
> > > is RC rests with the release manager.)
> > As far as RC issues go, they'll be specified in an entirely separate
> > document, not maintained by the policy group.
> Do you really expect bug submitters to consult yet another document,
> or is it just so that you can point people to it and say "See, this is
> not considered an RC bug!"?  

Bug submitters already look at "another document". That document will
merely change from being the entirety of policy, to something a fair
bit shorter and a fair bit more on-point.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

     ``BAM! Science triumphs again!'' 
                    -- http://www.angryflower.com/vegeta.gif

Attachment: pgp2T3AMv8_zN.pgp
Description: PGP signature


Reply to: