Re: Vote change...

[Roy Fielding <fi...@beach.w3.org>]

>> Yes, that's much better.  However, I would prefer
>> 
>>        0_8_11_01_a_ScriptAliasKaboom.patch
>
>I think you might like the revised syntax which I guess you've
>yet to read.

I saw it, but I would prefer a syntax that remained sorted when
plopped into a single directory with all the other patches
(something I'd like to have if we create patch db Mark III).
The reason for incrementing "a" for alternate patches instead
of incrementing the "01" part is so that patches intended to
solve the same problem are put next to each other.

No big deal, though.

>> with each patch change for the same problem incrementing the "a".
>> I believe in reserving .extensions to file typing.
>
>Everything in the patch dir will be a patch, no ?

As far as I know  -- I'm just anal about some things.

>> What mechanism do we provide for those unable to work on hyperreal?
>
>Everyone can upload to hyperreal as anonymous. They should nag^H^H^Hask
>someone to move things from incoming if they don't have an account.

Hmmm, I'm surprised the asswipe pirates haven't exploited it yet
(we had to close off all the incoming directories at UCI).

>> Also, 'diff -c file.c.orig file.c' reminds people not to reverse it.
>
>We'd settled in the past on -C3 for good reason, or is your point
>here the   ".orig" extension ? if yes, it's worth suggesting that syntax.

Well, both actually.  -C3 is identical to -c on all systems I know of,
since 3 is the default.

>> >  6) the vote deadline can be voted on too.
>> 
>> No.  That allows the entire voting process to be delayed indefinitely
>> by a single veto.  
>
>Mmm, I was thinking more along the lines of having the first deadline
>stay as the default and having other deadlines (extended presumably)
>put forward... these can be blasted away with a single veto, but if enough
>people want an extension, there'll be a procedure to handle it and we
>won't have to flame each other over timing.

Okay.

>> The vote deadline should be two days after the
>> vote is called.  
>
>do we need to restric the votes to the end of the process ? if we
>allow votes (and the comments that go with them) to flow over the
>whole announce->build period, then more issues can be raised before
>the last minute rush.

Uh, yeah, how about just "the initial vote deadline must not be less
than 2 days after the vote deadline is proposed, so that everyone is
given a fair chance at voting."

>> >  7) the release is assumed to be public unless vetoed.
>> 
>> Our public is our test base.  I'd say that the release is assumed to
>> be a beta unless the vote itself is on changing an existing beta to
>> the official release (in which case patches are not allowed).
>
>Are you saying that all versions should be released to the public
>and just named accordingly. When we get to feature patches, it might
>be useful to save up a series of features. Having the version number
>increment on a weekly basis might put a strain on webmasters who get
>pestered by users to upgrade in order to use the latest bells and whistles. 

We don't have to announce every release -- just stick it in the dist
directory with a big beta warning.  We can then just announce the "good" ones.

>> >  8) no veto can be overruled, they can only be withdrawn.
>> 
>> That will guarantee deadlock if someone vetoes one patch which is
>> a prerequisite for others (it has happened in the past).  Given that
>> we are now a large group, I'd recommend that we come up with a better
>> means of resolving vetoes, or at least strict guidelines on justification.
>
>that's something I meant to add earlier. A veto without a defendable
>reason should be void.
>
>So if I veto something and fail to offer a defence (should someone argue)
>then that veto can be declared void. You can veto again later, but be
>prepared to be flamed alive if you're just being stuborn.

Okay, I think that's reasonable.

>12) makes it explicit that the builder doesn't have to ask permission
>or call for votes if (s)he accidentally screwed up.
>
>> > 14) if a new patch causes any problems a quick vote (*) should be taken on
>> >      whether to remove, replace or leave the patch as it stands. A majority
>> >      decission decides this vote.
>> >      (*) quick = about a day... enough time for everyone to read mail and
>> >      respond.
>> 
>> I'll veto this last one -- no re-votes unless the new version does
>> not work the same as requested by patch vote.
>
>I didn't follow that. Having reread 14), it should perhaps be reworded..
>
>if after a build, one of the patches is found to cause a problem a majority
>quick vote shall determine whether the patch is left/replaced/removed
>
>does that help ?
>
>>  A single veto (limited
>> to these exact conditions) should stop a public release until the
>> build error is fixed and re-checked.
>
>maybe we're talking about different things, I'm thinking of a case,
>e.g. that old pain in the ass unmunge_name problem, where a problem
>is discovered after a build. In this case the patch had to be removed
>'cos it caused more problems that it tried to fix. If we had to try
>to "fix" the problem, we might have been there for weeks.

I'd say that is the same as vetoing the patch after the build but
before the release (if it is after the release, then the only choice
is to make a new quickie-release with one fix).  Shall we have a
quick-fix release vote as well?

Looks rational.  I think most of the problems will go away if we
just have a clear process for voting and replacing patches,
such that replaced patches always need their own votes.

.....Roy