Re: what is policy about?
On Thu, 28 Aug 2003 14:25:11 +1000, Anthony Towns <aj@azure.humbug.org.au> said:
> You do remember that we tried getting RC policy to be controlled by
> -policy, and it didn't work, right?
No, I don't, for that would be an interesting revision of
history, and not an accurate representation of actual events. I do
not ever remember the policy group bering in charge of a list of bugs
that were release critical, or passing judgement on which bugs were
grave, or critical, or which packages were otherwise too buggy to
release.
> Too many things that shouldn't be RC getting made RC, too many
> things getting made RC by accident or default, too much effort
> required to convince people that their pet fancy shouldn't be RC,
> and the RC policy not being up to date enough when it counts, and
> all.
And this is your best effort at being constructive?
All you are saying is that the release managers views differed
from the people who populate the policy mailing list, and very
possibly the goals of the policy team are different from the release
managers.
I do not find this surprising, since the the broad goals may
well be in agreement, but the details may be different.
All the policy group does it to determine what details of
packaging are important for systems integration; and there are three
varying levels of how important we think conformance to these rules
are. Lacking a firm determination in the release process in the
past, the most serious of these violations were regarded as being
important enough to cause an examination of the issue before the
package was released (in other words, release critical). Yes, when
examining specific cases, the general rule can, and does, turn out to
have exceptions. Having a general rule was not an excuse to stop any
critical thought process during the release process.
There is no particular reason to connect violation of policy
rules to release management (well, other than trying to get a handle
on the quality of the distribution, or to beat people on the head
with).
Hammering integration related rules (which is what policy is)
to be only restricted to those rules that impact release management
is likely to be as bad of integration quality as trying to substitute
integration rule violations for a coherent release management
protocol.
manoj
--
Don't indulge in careless behaviour. Don't be the friend of sensual
pleasures. He who meditates attentively attains abundant joy. 27
Manoj Srivastava <srivasta@debian.org> <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
Reply to: