Manoj Srivastava wrote:
So from now on, we'll only change Policy after all packages comply
with the proposed changes?
Yes. This is how policy has always worked; too.
Maybe in most cases, but I think not in all cases. Counter examples are
the move from FSSTND to FHS in Policy 3.0.0 (June 1999) and the secure
creation of temporary files (tempfile or mktemp suggested) in Policy
2.4.0.0 (January 1998). A lot of packages were not Policy-compliant when
these changes were accepted.
Yes, these examples are long in the past, but I also think that the FHS
transition over 4 years ago has been the last major Policy change that
affected more than just a few packages.
But we have managed to do so in the past, by providing a
Well, about 4 years ago when the last major Policy change happened there
have been around 400 Debian developers and 2500 packages. Making major
changes was a lot easier then although the /usr/share/doc transition
required over 1 year of discussion and a decission by the CTTE. Such a
Policy change is IMHO impossible nowadays with over 1000 developers and
10000 packages. Remember, the first word of the first answer to Martin's
proposal was "objection". :-(
transition plan. First, you recommend the change, and work on getting
packages changed over. Then you make the new way the default, but not
a must condition, deprecating the old one. And finally, you can
mandate the new way.
I think that if I file wishlist bugs againt some packages that provide
init script I'll get "change Policy first" as an answer. Shouldn't the
Policy also give the direction where packages should be heading instead
of just documenting common grounds?
So, the way to go would be:
- make a Policy proposal which says that init script "may" provide a
status option (and hope to not again get an objection as the first
answer...)
- file wishlist bugs after the proposal was accepted
- wait a very long time (at least one release?)
- make a 2nd proposal to change "may" to "should" (or even "must")
- file bugs after the 2nd proposal was accepted
- make a 3rd proposal that services "should" not be started in the
postinst during upgrades if they have not been running before
(suggesting to use the new status option and not stopping the service
in the prerm if it's an upgrade - this would also minimize the
downtime of a service during upgrades if it was previosuly running.)
- file wishlist bugs after the 3rd proposal was accepted
- wait again a very long time (at least another release?)
This means that we'll have the desired feature in 4 or 5 years. And
that's just a minor enhancement, how long would it take to get stack
protection (at least for suid programms and daemons) or package signatures?
You can not use policy changes to beat people on the head with.
I think we should get away from the idea that bugs are something like an
offense to the maintainer. IMHO they are more like feedback and
suggestions, the base for progress.
To summarize: Do we really want the Policy process to work this way?
With the growing number of developers and packages this will IMHO lead
to just more stagnation since nobody wants to spend so much time to get
a relatively small (but IMHO very useful) enhancemant.
Wrong. There is only one policy, the current one.
Then it is a bug to upload a package which does not conform to the
latest Policy version with it's control file stating a former
Standards-Version:? (No, I don't intend to mass-file bug reports. ;-))
Stefan
