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

Policy progress, was Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)

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 (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

- 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. ;-))


Reply to: