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

Re: Call for Votes: General Resolution: Init system coupling



On 04/11/14 at 19:27 +0000, Neil McGovern wrote:
> On Tue, Nov 04, 2014 at 07:54:46PM +0100, Lucas Nussbaum wrote:
> > Hi Neil,
> > 
> > On 04/11/14 at 17:53 +0000, Neil McGovern wrote:
> > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> > > 57dd4d7c-3e92-428f-8ab7-10de5172589e
> > > [   ] Choice 1: Packages may not (in general) require a specific init system
> > > [   ] Choice 2: Support alternative init systems as much as possible
> > > [   ] Choice 3: Packages may require specific init systems if maintainers decide
> > > [   ] Choice 4: General Resolution is not required
> > > [   ] Choice 5: Further Discussion
> > > - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> > 
> > I must say that I am quite surprised by you choice of summary for Choice 2.
> > 
> > First, that's the only one not to include a verb. It could be understood
> > as "Packages *must* support alternative init systems as much as
> > possible", which is clearly misleading. Also "as much as possible" is
> > not part of the amendment.
> > 
> 
> Choice 2 seems to be about 4 things:
> * The default init system on all arches should be supported, 
> * maintainers should merge support for init systems, 
> * sysvinit support should be maintained for all packages which
> worked before and any the release team should accept changes during the
> freeze which preserve or enhance this support

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.

I am sorry you did not use the discussion period to clarify this, it
could have resulted in an improved proposal.

> This is obviously quite hard to put into one line.
> 
> > 
> > Second, after asking for an accurate summary, I replied in
> > <20141017202805.GA10561@xanadu.blop.info> (private mail to you+Ian, as
> > was your initial query) with: "support for alternative init systems is
> > desirable but not mandatory". If you disagreed with the suggestion, why
> > didn't you say so since Oct 17th?
> > 
> 
> Quite frankly, there's been one hell of a lot of mail during this
> process, which I've done my best to read and digest. The other option in
> that mail which you suggested was also quite contentious. I'd be happy
> with you sending the entire thread to the list if you and Ian agree.

Oh, I would be fine with that. But to summarize, I originally suggested
"make each package support all alternative init systems" for Ian's.
At the time, it was not clear to me that Ian meant "at least one
alternative" and not "all alternative". I wasn't the only one making
that mistake, and Ian later improved his proposal to clarify this. I also
apologized for this misunderstanding in <20141021125657.GA12019@xanadu.blop.info>.

> That entire thread seemed to then devolve with various accusations, and
> then you confusing my suggestions for Ian's text for your own.

That's not an accurate summary of the discussion. See
<20141020111714.GA18936@halon.org.uk>, <3165381.DVHk3vBgWs@gyllingar>,
<20141021083354.GK18936@halon.org.uk>,
<20141021125657.GA12019@xanadu.blop.info> (all on debian-vote@).
(anyway, I don't think it's important in that current discussion)

> > 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.GA13204@xanadu.blop.info>. This is not the core of the
proposal.

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

Lucas

Attachment: signature.asc
Description: Digital signature


Reply to: