I'm writing here in a purely secretarial capacity.
Russ Allbery writes ("Bug#727708: init system coupling etc."):
> Colin Watson <cjwat...@debian.org> writes:
> > I agree. Russ, how about this amendment?
Is that a formal proposal ?
> > diff --git a/727708_initsystem/coupling-russ.txt
> > b/727708_initsystem/coupling-russ.txt
> > index 242505a..dfc1ded 100644
[etc]
>
> This seems fine.
And is this an acceptance ?
As a matter of process, it would be very wise for everyone to at least
make all statements approving changes to these kind of resolutions as
formal proposals. That way you don't risk not having time to
explicitly accept the formal amendment before the CFV.
Likewise if a TC member thinks a change is important enough that they
want to press for it, it would be better to propose it as a formal
amendment. It can always be withdrawn or accepted later. A TC member
would be well-advised to make such a formal proposal iff they want
something like their suggestion to be on the ballot.
I think in the absence of clarity, when preparing the CFV, I should
probably proceed on the following basis:
- Statements from TC members suggesting changes but not explicitly
stating that they are formal proposals, are not formal proposals.
Rationale: This avoids the ballot being clogged up with a
profusion of suggested edits which the suggester probably didn't
want to put onto the ballot if not accepted.
- Statements from TC members expressing unqualified approval of
suggested edits to their own texts are to be treated as formal
acceptance of amendments (including formal proposal of the
amendment if necessary). Even if the TC member's message does
not contain an explicit "I hereby ..." statement.
Rationale: This avoids the ballot containing older versions of a
text in a situation where a TC member didn't get around to
whatever tidying up or redrafting they felt they were waiting for.
If anyone disagrees with this, please say.
So accordingly, I intend to treat Russ's "this seems fine" as an
acceptance of Colin's suggestion.
> > - For the jessie release, all packages that currently support being run
> > + For the jessie release, all software that currently supports being run
> > under sysvinit should continue to support sysvinit unless there is no
> > technically feasible way to do so. Reasonable changes to preserve or
> > improve sysvinit support should be accepted through the jessie
> > release. There may be some loss of functionality under sysvinit if
>
> This looks good.
And this.
But not the other suggestions in Colin's mail, which Russ either
didn't quote or disagreed with.
But for now I'm not going to make these changes in git. Instead I'm
going to drop the message-id of Russ's message into the git repo as a
note that it contains accepted amendments which need integrating.
That will save effort if Russ decides to rewrite or re-edit the file
himself.
I trust this meets with everyone's approval. Sorry to be so
long-winded and pernickety about process, but I don't want to make
sure that we all agree on the process and the proprieties and I don't
want anyone to be taken by surprise.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
