On Tue, 26 Aug 2003 18:54:31 +1000, Anthony Towns <aj@azure.humbug.org.au>
said:
> On Tue, Aug 26, 2003 at 12:50:53AM -0500, Manoj Srivastava wrote:
>> In my view, policy is supposed to represent the minimum set of
>> rules that packages follow to allow the parts to dovetail together.
> I don't think that makes sense -- getting packages to dovetail
> together isn't something that can be achieved once and forever more;
> once we've got libraries and file hierarchies making sense and
> fitting together, we're not going to stop, we're going to start
> working on getting documentation put together in more consistent
> fashions, or stop Gnome from spewing assertions to xterms, or any
> number of other things.
Where are you getting the impression that there is a time
limit to changes done in policy? I hope that it is not from something
I wrote (and I went back and looked at what I wrote, and I don't see
where I gave that impression), since it is not true.
Protocols change. Applications evolve. New classes of
applications come into being -- so no, I don't think the work on the
ruleset required for integrating the software out there into a
coherent whole is ever done. Case in point: nearly a decade ago, me
and my colleagues at UMASS were crafting the information policy for
the department, and just when we had finished detailing ftp and
gopher hierarchies, required messages for gopher directories, backup
routines, access controls, there came along this new fangled thing
called Mosaic and threw it all into a hoop. I am sure the situation
has not improved -- we had not considered laptops in every dorm, or
the effect of the likes of Kaaza.
Anyway, this was a nice strawman, but it did not address
anything I wrote.
> But doing any of that requires a document that's willing to cover
> all the things we're trying to achieve. Having many documents
> doesn't work, because packagers coming to Debian need to be able to
> find *everything* that affects them; having stuff undocumented
> doesn't work because otherwise not only won't new people know it,
> but those of us who decided what we'd do are liable to forget.
If people can't go to one document for things that are
required for having a package work with others in Debian, and another
for best practices and tips of the day, we certainly have a problem,
-- though not just the one you think, but a far worse one, since that
implies a degradation of the quality and motivation of the general
developer.
>> The developers reference is the best repository of "best practices"
>> -- common techniques that over time have been discovered to be
>> desirable to adopt.
> No, it's not. The developer's reference is about procedures; debian
> policy is about packaging. And this is utterly appropriate; working
> out what to do (packaging policy), and how to do (uploading policy)
> are fundamentally different things. Procedures, like when to upload
> NMUs or the use of DELAYED queues, change by dictate and mood;
> technical policy whether you consider that "best practices" change
> only when new problems are noticed, or when new procedures become
> possible.
> Moving these things into other documents is a *mistake* -- it was a
> mistake when we did it to the packaging manual, one which continues
> to make policy confusing and difficult to follow, and it's a mistake
> to extend chapter six of the developers reference.
>> [...] but by and large, the goal is to pare it down to a ruleset
>> _required_ for packages to interact and integrate tightly together.
> What, exactly, do you think this means?
This means that if there is only one right way to do
something, policy should not be declared. Policy only should lay down
rules and guidelines if there are multiple, equally viable ways of
doing things, and packages need to choose one in order to cooperate
(case in point: location of a web servers root of the document tree).
> It's not required in the sense that the package won't be allowed in
> Debian, or in a Debian stable release; that's
> http://people.debian.org/~ajt/sarge_rc_policy.txt.
Ah. I can understand that your view is coloured by the release
process. But there are higher requirements than that: the social
contract says that we are trying to produce the _best_ OS there is,
and the requirements of integration, one that allows packages to have
synergy, and to produce something of far more utility than individual
packages supersede everything. In other words, some rules allow
packages to better cooperate, and without those rules, or being able
to depend on the invariants implied by those rules, degrades the
quality of the distribution.
> It's not required in the sense that the packages won't work at all,
> or even that it won't work for the majority of people; that would be
> even shorter than the sarge_rc_policy.
But we are not here joining common cause to produce a hodge
podge of software randomly gathered over the network: we are
producing the _best_ OS ever. I hope we have not lost sight of that
prime cause in the heat of releases and RC bugs.
That is what I mean by rules "_required_ for packages to
interact and integrate tightly together" .
>> I, however, agree that policy is not a stick to beat developers on
>> the head with, which is another way of stating what you said.
> "The Axiom of Choice is obviously true; the Well Ordering Principle
> is obviously false; and who can tell about Zorn's Lemma?"
> (You did just disagree with me, then restate my comment and agree
> with it, right?)
I agreed with one underlying principle, which you stated in the
beginning, and disagreed with your expansion of that, and the
rationale you gave. Your viewpoint, in my humble opinion, is tainted
by viewing everything through the prism of release management (and
that is perfectly understandable). But release management, important
though it is, is not the sole viewpoint about policy.
> If you're not going to beat people on the head with policy, the only
> merit it has *at all* is as a compendium of well thought out advice
> to package maintainers about how to do their work. That is the
> *precise* definition of "best practices" documents.
I beg to differ. The reason you can't beat people on the head
with _anything_ is that they are volunteering their time; not because
there are not rules that _have_ to be followed; because such rules do
exist. There are also rules which, if people fail to follow them,
would result in a degradation of the quality of implementation of the
OS that we produce. Policies role lies in being the repository of
such rules.
> By contrast, sarge_rc_policy is a list of requirements, and is
> something to beat people over the head with.
No. At best, you can excludse these packages from the
release. Violating rules in policy can, at best, cause bugs to be
reported against your package. In neither case can we bring more
pressure to bear on volunteers than that, really. While the
mechanisms are different both in scope, they have a certain
underlying similarity.
manoj
--
If I could read your mind, love, What a tale your thoughts could tell,
Just like a paperback novel, The kind the drugstore sells, When you
reach the part where the heartaches come, The hero would be me, Heroes
often fail, You won't read that book again, because the ending is just
too hard to take. I walk away, like a movie star, Who gets burned in
a three way script, Enter number two, A movie queen to play the scene
Of bringing all the good things out in me, But for now, love, let's be
real I never thought I could act this way, And I've got to say that I
just don't get it, I don't know where we went wrong but the feeling is
gone And I just can't get it back... Gordon Lightfoot, "If You Could
Read My Mind"
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
