On Tue, Nov 04, 2014 at 09:17:51PM +0100, Lucas Nussbaum wrote:
> I cannot parse the last bullet point, sorry ("and any the release
> team"?). Also, the proposal does not mention the release team.
> "Reasonable changes to preserve or improve sysvinit support should be
> accepted through the jessie release." is not meant as an override of the
> release team: the maintainer should accept such changes, not necessarily
> the release team (normal rules for the freeze should apply).
> If I intended to override the release team here, I would obviously have
> made it explicit.
>Well, any enhancement for sysvinit support would certainly be against the freeze policy. However, as these are decisions which in theory the release team has not yet made (it's done on a case by case basis) then there's no decision to override yet, hence the 1:1 requirement. Additionally, after the Jessie release date, if a bug comes in that improves support for the stable version of a package, what is the maintainer supposed to do? > I am sorry you did not use the discussion period to clarify this, it > could have resulted in an improved proposal. > I'm not sure it's really my position to try and amend your text in this case, I've not been asked to do so. It is, however, regrettable that I haven't had time to continue to discuss the summary lines. Would you be happy with me simply cancelling the entire vote to allow that discussion to take place? I'm not keen to adjust the ballot before midnight, I'd rather send out a new CfV if that's the case. > > > If my suggestion is too long, you could have used any of the following, > > > which are all shorter or the same size as the summary for Choice 3: > > > - Support for alternative init systems is desirable, not mandatory > > > - Maintainers are encouraged to support alternative init systems > > > > That doesn't appear to capture the paragraph starting "For the Jessie > > release..." accurately. > > That paragraph could be summarized as "support wheezy->jessie upgrades > nicely", as was detailed in e.g. > <20141021131459.ga13...@xanadu.blop.info>. This is not the core of the > proposal. > However, it's in the text. If you didn't want it to be part of the proposal, it should have not been there, or been as a summary outside of the resolution to be passed. The fact remains that it's in there, whether your intention or not. > > I discussed the final summaries with Kurt before the CfV, and we think > > that this is about as accurate as we could do given the very short > > amount of space available. This is also the reason I added a separate > > paragraph encouraging people to go and read the full proposals. > > [...] > > > Given the above, I don't believe that this would help the process. I > > feel that the summaries are as accurate as they can be at this time. > > I strongly disagree, and urge you to reconsider. > > However, if you decide not to change the summary for this proposal to > something that I would consider an accurate summary of it, I > ask you to include a title at the start of my proposal (under "Choice > 2:", but before "Debian has decided [...]"), that should read: > > | Support for alternative init systems is desirable, not mandatory > | ================================================================ > > That's only a compromise solution, and clearly not one I'm satisfied > with -- I still think that this should be used as the summary. I think that the web pages and the ballot not matching would be the worst of all worlds to be honest. Unless I'm mis-understanding? Neil
signature.asc
Description: Digital signature
