On Mon, 10 Jul 2006, Sven Mueller wrote: > I think we need something like a "policy to be", i.e. some document > which shows which changes _should_ go into the policy document as soon > as packages are fixed accordingly. Something that results in an
We can have a "ongoing tasks" page in the wiki, and document where that page is properly (i.e. at least an email to d-d-a). That said, you are encouraged to propose a policy change that uses "may", with a footnote that specifies that it will become a should and must when the goals of "x% of packages" have been met (I suggest 80% and 98% for the should and must thresholds). This has been done before, and it works. > and still not in policy. The reason is simple: Many maintainers don't > care to implement upcoming policy changes until they really are in policy. True, and AFAIK the usual way to fix this is do a patch run, followed by a not-so-friendly prodding for the patch acceptance, and then a NMU to delayed run. It takes a few months for non-invasive changes, but it is not too painful. You end up with enough packages fixed to bump policy to a should without much resistence, and after a few months, another patch run which can be a lot more forceful will allow it to be brought to a must. > 1) Implement "force-reload" as a "restart" alias if "reload" is not > available and violate LSB (which, according to the RMs means an RC > bug). Did you specifically ask the RM if this *particular* violation of the LSB is RC? If you didn't, please clarify it with them. > 2) Implement "force-reload" as a conditional "restart" alias only > executed when the service is already running. This violates current > policy wording and is therefor also an RC bug. It is also non-trivial to implement. "already running" is not always easy to detect, and most initscripts are really just crap and don't even do the start-stop-daemon dance properly. Usually, if you are going to implement any such thing, it would be good to implement "status" while at it. One of the reasons I would get behind a massive workforce to switch to runit (provided we *still* keep init.d scripts -- they will often be little more than generic calls into runit helpers and a base initscript shell library anyway) is that we'd fix all initscripts and maintainers would not have an excuse to write bad ones anymore because it would be simpler to just do it right (and runit makes it MUCH easier to track "running state" properly). > At the very least, I would suggest the following wording of the > "force-reload" description: > > ******************************************************************** > <tag><tt>force-reload</tt></tag> > <item>cause the configuration to be reloaded if the service supports > this. If it doesn't support reloading, restart the service. Note that > the service should not get started if it wasn't already running.</item> > ******************************************************************** I can second such a change. > After all, even if policy can't _mandate_ (must, required) the wanted > behaviour, it should not encourage behaviour that is supposed to get RC > buggy at some point in time. That I agree with completely. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
