You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Hans Bergsten <ha...@gefionsoftware.com> on 2001/01/24 22:11:09 UTC
[VOTE] Release Plan approval clarifications
I announced Monday that I would put a number of decision guideline
clarifications related to the approval of a Release Plan up to a vote
by PMC members today, so here we go. I have adjusted the original proposal
slightly based on feedback on this list and comments made on the Tomcat
Developers list.
Note! According to our existing guidelines, changes to the guidelines are voted
on by PMC members only! It has been suggested that approval requires a
"super-majority vote", i.e. a +1 from 3/4 of the PMC members. Since I have
not seen any objections to this suggestion, I assume that all PMC members agree
and that this vote is decided by "super-majority vote".
All PMC members are required to vote or abstain within 24-hours.
Clarification of voting flavors
-------------------------------
I suggest we change the voting flavor description like this (based
on the parts of Ted's proposal that seem to have consensus at this
time, the PMC meeting minutes, and feedback on this list):
+1 "The action should be performed, and I will help."
+0 "Abstain. I support the action but I can't help."
-0 "Abstain. I don't support the action but I can't help with an
alternative."
-1 "The action should not be performed and I am offering an explanation
or alternative."
On issues where "lazy approval" or consensus is required, a "-1" vote
counts as a veto. All vetos must contain an explanation of why the veto is
appropriate. Vetos with no explanation are void. A veto can be challenged.
It then requires another person with voting rights to state that the
explanation is valid (not necessarily that they agree, but merely that the
explanation is valid) for the veto to be valid.
An action item needs one of three types of approval:
Lazy approval
An action requiring Lazy Consensus or Lazy Majority approval do not
require any +1 votes, but must not receive a binding veto. If it gets a
binding veto, the veto must be addressed (by changing the proposal, by
lobbying the person who cast the veto, etc.) and the vetoed item must be
put up for an Active Consensus or Majority approval vote.
Active Consensus approval
An action requiring Active Consensus approval must receive at least 3
binding +1 votes and no binding vetos. The vote message must include a time
limit for voting.
Active Majority approval
An action requiring Active Majority approval must receive at least 3
binding +1 votes and more +1 votes than -1 votes. The vote message must
include a time limit for voting.
For an Active Majority or Active Consensus approval, the mail announcing the
vote must also include information about when the voting ends. The time limit
must not be less than 24 hours and not more than 120 hours.
Change "lazy majority" to "majority approval"
---------------------------------------------
Since the approval of a Release Plan is a decision that defines what items
Committers will work on, I feel that it's important to see real support for
the plan. I therefore suggest that we change "lazy majority" to "Active Majority
Approval" in the following paragraph in our existing decision guidelines:
Release Plan
A release plan is used to keep all Developers aware of when a release
is desired, who will be the release manager, when the repository will
be frozen to create a release, and other assorted information to keep
Developers from tripping over each other. <strike>Lazy majority</strike>
<insert>Active Majority Approval</insert> decides each issue in a release
plan.
Clarification of Release Plan votes vs. Release votes
-----------------------------------------------------
A +1 vote on a Release Plan means the Committer agrees to help with the
implementation of the plan only. A +1 vote on the Release means the
Committer agrees to help with the support (bug fixes, answering user
questions, etc.) of the released product.
I believe that with these clarifications and amendments, we will be able
to handle a vote for a Release Plan without controversy. If you feel something
is still missing, please let us know so we can address this ASAP.
My vote is, of course, +1 on all of this and if it passes I will update the
guideline documents.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [VOTE] Release Plan approval clarifications
Posted by Louis Tribble <lo...@metamata.com>.
Ted Husted wrote:
> >Okay, I agree. How about this:
> > Lazy means the action item has immediate tactic approval, and it is
I've been seeing "tactic approval" for a while now. I can't figure
out what it means: I'm guessing "tacit approval" is meant?
Louis
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
On 1/25/2001 at 3:16 PM Anil Vijendran wrote:
>What would be the course of action if someone +1s an action but
doesn't help?
I think that may be why we go three-deep on Committers;-) Each person
must be willing to be responsible for the codebase, "jointly and
severally". Effectively, you "co-signing" the code (at least to the
extent of your ability).
Of course in the case of the plan, if not enough people help, there
would probably never be a final release candidate to act upon.
At one point, I had suggested in the omnibus proposal, under
Roles/Committer
"Committers who approve a public release are expected to prioritize
their contributions so that Bug Reports regarding that release are
quickly resolved, as the individual Committer's skill set permits. A
Committer who approves (votes +1) on a public release, but then fails
to support that release to the best of their ability, may lose his or
her status as a Committer. (In other words, do not develop and
contribute new code while current, released code you approved is
broken.). Committers who fail and refuse to follow Project guidelines
may have their status and privileges revoked by a 3/4 vote of the PMC."
but later removed it. It seemed a little harsh for an organization with
the mission to create software in an "open and cooperative fashion".
Though, it does close the loop.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: [VOTE] Release Plan approval clarifications
Posted by Anil Vijendran <An...@eng.sun.com>.
Ted Husted wrote:
> Clarification of voting flavors
> -------------------------------
>
> +1 ="The action should be performed, and I will help."
> +0 = "Abstain. I support the action but I can't help."
> -0 = "Abstain. I don't support the action but I can't help with an
> alternative."
> -1 = "The action should not be performed and I am offering an
> explanation or alternative."
After reading Henri's comment, I have to go back on what I said about
voting flavours. This is indeed a bit complicated and sounds binding for
whoever does it. Obviously we can't enforce any such binding but it is
bound to create a bit of uneasiness as you have seen. What would be the
course of action if someone +1s an action but doesn't help?
Maybe, we should just stick to +1, 0 and -1. In addition to this numerical
vote maybe we should add the following to the various flavors:
* +1 = "The action should be performed."
o "I will help with the XXX module or subsystem"
* 0 = "Abstain."
* -1 = as above
Basically what I'm saying is that: "It is strongly suggested that a +1 be
augmented with the exact nature of the contribution."
> Clarification of Release Plan votes vs. Release votes
> -----------------------------------------------------
>
> A +1 vote on a Release Plan means the Committer agrees to help with the
> implementation of the plan only. A +1 vote on the Release means the
> Committer agrees to help with the support (bug fixes, answering user
> questions, etc.) of the released product.
I'm fine with the meaning of +1 on a Release Plan. However, for a Release,
I'm inclined to say that a +1 should mean that the committer is convinced
that the release plan was adequately followed and the goals were met and
s/he feels comfortable with actually cutting the release.
> Clarification of Lazy vs. Active voting
> -----------------------------------------------------
>
> Lazy means the action item has immediate tacit approval, and it is not
> necessary to tally the vote until a -1 vote is posted. The terms Lazy
> Consensus and Lazy Majority refer to the type of approval needed in
> case of a -1 vote. If an action item subject to lazy approval of one
> of these types gets a -1 vote, the approval type for the item turns
> into an Active Consensus or Majority approval vote, respectively.
>
> [- I would add to that last bit:
>
> "A -1 vote on an action requiring a majority decision, including a
> Release Plan and the Release, is * not * a veto." -]
>
I agree that -1 on a release should not be a veto. Also, what constitutes a
majority? For a Release Plan and a Release, what sort of voting are we
using -- Active Consensus or Majority? It is important to say what events
require consensus and which ones require majority.
> Change to add time limit to active voting
> ---------------------------------------------
> An action item needs one of three types of approval:
>
> Active Consensus approval
> An action requiring Active Consensus approval must receive at least 3
> binding +1 votes and no binding vetos. The vote message must include a
> time limit for voting.
>
> Active Majority approval
> An action requiring Active Majority approval must receive at least 3
> binding +1 votes and more +1 votes than -1 votes. The vote message must
> include a time limit for voting.
>
> For an Active Majority or Active Consensus approval, the mail
> announcing the vote must also include information about when the voting
> ends. The time limit must not be less than 24 hours and not more than
> 120 hours.
Re: time limits, this is good.
> Change "lazy majority" to "majority approval"
> ---------------------------------------------
> Release Plan
>
> A release plan is used to keep all Developers aware of when a release
> is desired, who will be the release manager, when the repository will
> be frozen to create a release, and other assorted information to keep
> Developers from tripping over each other. <strike>Lazy
> majority</strike> <insert>Active Majority Approval</insert> decides
> each issue in a release plan.
Answers one of my questions...
--
Peace, Anil +<:-)
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
Sorry, I screwed this up.
My recap left out Lazy Approval from the three types of voting, and the
Change to add challenges to vetos.
I'll just stay out of this now.
-Ted.
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
On 1/25/2001 at 1:00 PM Jon Stevens wrote:
> Ok, I just got an email from Hans reminding me to vote for this.
However, I see that there has been a lot of discussion regarding his
clarifications.
Mostly just me, I'm afraid. I apologize for being such a pest. But, in
the spirit of cooperation, from the exchange, I would make the status
to be:
Clarification of voting flavors
-------------------------------
+1 ="The action should be performed, and I will help."
+0 = "Abstain. I support the action but I can't help."
-0 = "Abstain. I don't support the action but I can't help with an
alternative."
-1 = "The action should not be performed and I am offering an
explanation or alternative."
Clarification of Release Plan votes vs. Release votes
-----------------------------------------------------
A +1 vote on a Release Plan means the Committer agrees to help with the
implementation of the plan only. A +1 vote on the Release means the
Committer agrees to help with the support (bug fixes, answering user
questions, etc.) of the released product.
Clarification of Lazy vs. Active voting
-----------------------------------------------------
Lazy means the action item has immediate tacit approval, and it is not
necessary to tally the vote until a -1 vote is posted. The terms Lazy
Consensus and Lazy Majority refer to the type of approval needed in
case of a -1 vote. If an action item subject to lazy approval of one
of these types gets a -1 vote, the approval type for the item turns
into an Active Consensus or Majority approval vote, respectively.
[- I would add to that last bit:
"A -1 vote on an action requiring a majority decision, including a
Release Plan and the Release, is * not * a veto." -]
Change to add time limit to active voting
---------------------------------------------
An action item needs one of three types of approval:
Active Consensus approval
An action requiring Active Consensus approval must receive at least 3
binding +1 votes and no binding vetos. The vote message must include a
time limit for voting.
Active Majority approval
An action requiring Active Majority approval must receive at least 3
binding +1 votes and more +1 votes than -1 votes. The vote message must
include a time limit for voting.
For an Active Majority or Active Consensus approval, the mail
announcing the vote must also include information about when the voting
ends. The time limit must not be less than 24 hours and not more than
120 hours.
Change "lazy majority" to "majority approval"
---------------------------------------------
Release Plan
A release plan is used to keep all Developers aware of when a release
is desired, who will be the release manager, when the repository will
be frozen to create a release, and other assorted information to keep
Developers from tripping over each other. <strike>Lazy
majority</strike> <insert>Active Majority Approval</insert> decides
each issue in a release plan.
HTH.
Re: [VOTE] Release Plan approval clarifications
Posted by Jon Stevens <jo...@latchkey.com>.
Ok, I just got an email from Hans reminding me to vote for this. However, I
see that there has been a lot of discussion regarding his clarifications.
Therefore, I would like to see another vote established that clarifies the
latest status of what I'm voting on as at this point, as I am confused. :-)
I would also like to ask for an extension on the deadline (24 hrs) as I am
way over worked right now.
-jon
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
On 1/25/2001 at 11:52 AM Hans Bergsten wrote:
> If a plan gets passed by lazy approval (e.g. no votes at all),
significant work can be done in the HEAD even though only the person
that submitted the plan is really committed to the changes. This can
cause confusion, as is evident with the recent TC 3.3 discussions.
Changing lazy approval to active approval makes sure there are at least
three Committers that believe in the plan and are committed to
implement it.
Anyone who that would confuse should simply vote -1, and convert it to
an active majority vote. This just happened when Tomcat 4.0 plan first
went. But Craig made his case, and the CVS changes were eventually
approved.
If there are not three Committers to do the work, it would be unlikely
that the other work would be accomplished before the product was
obsolete, and the release candidate would never be approved. If one
person can do the work, and the release candidate is approved (by
active majority vote, as usual), then great, we have a new Release
Build to ship!
> "Public Release
How is that different than what I have in the proposal:
Clarification of Release Plan votes vs. Release votes
-----------------------------------------------------
A +1 vote on a Release Plan means the Committer agrees to help with
the
implementation of the plan only. A +1 vote on the Release means the
Committer agrees to help with the support (bug fixes, answering user
questions, etc.) of the released product.
I believe that an oversight in the current guidelines is the Public
Release step, which deserves clarification. If it had been there to
begin with, we might not be having this conversation now.
I do agree that this paragraph would be a good thing to append to the
voting section in the guidelines at any time, along with a reminder
that a -1 on a majority vote is not a veto. It could also just be
circulated by Sam in the form of an email until the rest of the
guidelines are updated.
>Okay, I agree. How about this:
> Lazy means the action item has immediate tactic approval, and it is
not necessary to tally the vote until a -1 vote is posted. The terms
Lazy Consensus and Lazy Majority refer to the type of approval needed
in case of a -1 vote. If an action item subject to lazy approval of
one of these types gets a -1 vote, the approval type for the item
turns
into an Active Consensus or Majority approval vote, respectively.
That * is * much better, but I still don't see that this is as urgent
as the other clarification.
> I don't agree. Since the plan requires majority approval, it can
still
pass as long as there are more +1 votes than -1 votes. If there are
more -1 votes than +1 votes, something is wrong and it needs to be
dealt
with. Besides, you'd have to deal with this even if we would stick to
lazy majority for the plan.
We'll have to agree to disagree then. I don't believe we should be able
to vote down a "plan" as a whole, only the individual issues that make
up the plan. This seems contrary to everything else that is written in
the guidelines. I believe that the system as it is written now makes
perfect sense. But the PMC members voting on this have been using the
system longer than I have, and should do what they think is best for
the Project, and all of its subprojects.
-Ted.
Re: [VOTE] Release Plan approval clarifications
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Ted Husted wrote:
>
> >One of the major concerns at the PMC meeting last week was that a
> >proposed release to an existing code base, such as TC 3.x, must come
> >with some kind of guarantee that there are enough Committers interested
> >in the proposed release to ensure that the result will be supported.
>
> I would submit that this is an issue for the product release vote,
> which is already by active majority. A +1 on the plan would not commit
> someone to support. It's easy to envision that someone might want to
> help prepare the release, but then work on another codebase afterward.
I agree that a +1 on the plan doesn't commit anyone to support the
released product, only to help with the implementation with the plan.
That's why I added that specific clarification as well. But even the
plan itself is important enough to warrant an active vote. If a plan
gets passed by lazy approval (e.g. no votes at all), significant work
can be done in the HEAD even though only the person that submitted the
plan is really committed to the changes. This can cause confusion, as
is evident with the recent TC 3.3 discussions. Changing lazy approval
to active approval makes sure there are at least three Committers that
believe in the plan and are committed to implement it.
> I believe the best way to address support issues is to clarify what
> voting +1 on a product release means. It's possible that Committers
> have been voting +1 on actions when they really meant +0.
Yes, and that's what one of the clarifications in this proposal deals
with.
> If support is the issue, it should be addressed head-on, perhaps by
> inserting between "Release Plan" and "Showstoppers":
>
> "Public Release
>
> "Once the Release Manager determines that testing is complete, and all
> showstoppers for the release have been resolved, the Release Manager
> will call for a vote on the public release. The Committers who approve
> a public release (vote +1) are expected to provide ongoing support for
> that release while it is current. The Release Manager must summarize
> the outcome of the vote before the public release becomes final."
How is that different than what I have in the proposal:
Clarification of Release Plan votes vs. Release votes
-----------------------------------------------------
A +1 vote on a Release Plan means the Committer agrees to help with the
implementation of the plan only. A +1 vote on the Release means the
Committer agrees to help with the support (bug fixes, answering user
questions, etc.) of the released product.
> >If an action item subject to lazy approval of one of these types gets
> >a valid veto
>
> I believe the point that needs the most clarification is that "you
> can't veto a release - that's a majority decision" (Roy Fielding). Veto
> and -1 are not synomous terms.
Okay, I agree. How about this:
Lazy means the action item has immediate tactic approval, and it is
not necessary to tally the vote until a -1 vote is posted. The terms
Lazy Consensus and Lazy Majority refer to the type of approval needed
in case of a -1 vote. If an action item subject to lazy approval of
one of these types gets a -1 vote, the approval type for the item turns
into an Active Consensus or Majority approval vote, respectively.
If this is clear and I don't see any objections form PMC members,
I can use this text instead.
> > A -1 on an individual item is a -1 on the complete plan.
>
> I don't mean to sound inflammatory, but this ~could~ be seen as
> mechanism designed to generate -1s. I would think that the guidelines
> for a meritocracy would encourage Committers to "show us the code". The
> time to thumbs up-or-down the complete package (and sign-up for product
> support) is when the final release candidate is locked and loaded.
I don't agree. Since the plan requires majority approval, it can still
pass as long as there are more +1 votes than -1 votes. If there are
more -1 votes than +1 votes, something is wrong and it needs to be dealt
with. Besides, you'd have to deal with this even if we would stick to
lazy majority for the plan.
> >This use of the GENERAL list has been announced to the Tomcat
> >Developers list in at least the following mails:
>
> These changes would affect all of the Jakarta projects, not just
> Tomcat.
Anyone else have concerns about this? I tried to look at the archives
for the other subproject Developers lists, but my ISP's DNS server is
not healthy today so I can't get to them. I would imagine, however, that
the word has spread to all subprojects by now. The decision to use the
GENERAL list was also documented in the PMC meeting minutes.
> >But I feel that it's urgent to get a decision on the things directly
> >related to the Release Proposal approval now, since we will be faced
> >with such a proposal soon. In fact, we're holding up the TC 3.3
> >proposal until we have made these clarifications.
>
> I would submit that these are not clarifications, but significant
> *changes*. (Which is beginning to sound like another recent discussion
> ;-).
There's one change: lazy to active majority for a Release Plan. The
rest are clarifications, IMHO.
> >That's why I put just selected items up for a vote now, because I
> >believe it will take quite a bit of time to reach consensus on the
> >complete package that you're putting together.
>
> If everyone else believes that what we are doing here has been properly
> announced, then why not put the full proposal up for a vote and see? As
> far as I'm concerned, it's locked and loaded. The CVS copy at
> docs/proposal.html is up to date, and there is another reference copy
> at < http://husted.com/about/jakarta/ >. If we had 5 PMC votes today,
> it could be on the Web site tomorrow.
Maybe, but I still believe it's better to focus on the most urgent
parts first.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
On 1/25/2001 at 8:46 AM cmanolache@yahoo.com wrote:
>I other words - my proposal is:
- to vote "Plans" on simple majority.
- a +1 on a plan to mean "this is a good plan, I'm interested in it
and I'll help" ( and "help" doesn't means 8 h/day work, in all areas ).
- a +0 on a plan to mean "this is a good plan, I don't have any
resource to help make it happen - but I would be glad to see _you_
doing
it"
I would suggest that the PMC members consider passing the part of the
proposal which says
"Clarification of Release Plan votes vs. Release votes
-----------------------------------------------------
A +1 vote on a Release Plan means the Committer agrees to help with the
implementation of the plan only. A +1 vote on the Release means the
Committer agrees to help with the support (bug fixes, answering user
questions, etc.) of the released product."
Along with a follow up to Roy Fielding's comment from the minutes:
"A -1 vote on an action requiring a majority decision, including a
Release Plan and the Release, is * not * a veto."
This language could just be appended to the Voting section, as a simple
amendment.
The PMC could then reserve judgment on the other parts of the proposal,
which seem to be changes rather than clarifications.
I don't believe that making the plan an "active" rather than "lazy"
majority at this time is a difference that makes a difference. Anyone
with strong feelings about the pending plans can cast a -1 and convert
it to an "active" vote. If no one is willing to vote -1, then making it
an active vote won't make a difference. The idea of support makes no
practical difference until we get to a Release, which is already an
actve majority vote. Making this change at this time seems like a
lose:lose proposition to me.
-Ted.
Re: [VOTE] Release Plan approval clarifications
Posted by cm...@yahoo.com.
> I don't mean to sound inflammatory, but this ~could~ be seen as
> mechanism designed to generate -1s. I would think that the guidelines
> for a meritocracy would encourage Committers to "show us the code". The
> time to thumbs up-or-down the complete package (and sign-up for product
> support) is when the final release candidate is locked and loaded.
+1 on this.
I don't think it's reasonable to make a decision based on "plans" to do
something. We are asking people to commit themself for an undetermined
time for undetermined obligations ( what does "support" means in this
context ? ) and all that without having the final product.
( sort of a "go/no go" on a release with 3 months before the release
date).
We can make many plans, but we can't know a priori what will be the
result. I know that I want the plan to succeed, and that I'll commit
all my available resources to it - but I still can't predict the result,
it depends on many other people.
I other words - my proposal is:
- to vote "Plans" on simple majority.
- a +1 on a plan to mean "this is a good plan, I'm interested in it
and I'll help" ( and "help" doesn't means 8 h/day work, in all areas ).
- a +0 on a plan to mean "this is a good plan, I don't have any
resource to help make it happen - but I would be glad to see _you_ doing
it"
I would also ask to establish the voting rules for the release and
post-release support _after_ it's properly defined what it means.
We have a good example - Apache's httpd - and I propose to use the same
definition ( or give good arguments for requiring more/less than httpd
people do ).
Those rules will affect many projects, don't make them using tc3.3
as an example. There are plenty of commiters on 3.3, some using it in
products or production sites - the "commit to support" can hardly be done
by a volunteer working in his free time ( and without control over
the ammount of time) . While we are lucky to have people with jobs
involving tomcat who can vote this release, maybe other projects
don't.
I would rather like rules where people volunteering to help specific parts
of the product ( "I can't support all tomcat, but I'll help with mod_jk")
are taken into account - the current rules just discard them. I personally
prefer to know that all areas of a product are covered by the most
knowlegeable people ( even if they can't commit for "full support of the
product" ).
In particular, this is how tc3.x was developed - most developers earned
their "commiter" status by developing a specific chunk of tomcat. Only few
people were involved in all areas.
I don't want to start a new dispute, and I'll support whatever rules you
decide on - but I feel many people willing to do small contributions are
better than few people doing everything ( even for the support issues ).
Costin
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
>One of the major concerns at the PMC meeting last week was that a
proposed release to an existing code base, such as TC 3.x, must come
with some kind of guarantee that there are enough Committers interested
in the proposed release to ensure that the result will be supported.
I would submit that this is an issue for the product release vote,
which is already by active majority. A +1 on the plan would not commit
someone to support. It's easy to envision that someone might want to
help prepare the release, but then work on another codebase afterward.
I believe the best way to address support issues is to clarify what
voting +1 on a product release means. It's possible that Committers
have been voting +1 on actions when they really meant +0.
If support is the issue, it should be addressed head-on, perhaps by
inserting between "Release Plan" and "Showstoppers":
"Public Release
"Once the Release Manager determines that testing is complete, and all
showstoppers for the release have been resolved, �the Release Manager
will call for a vote on the public release. The Committers who approve
a public release (vote +1) are expected to provide ongoing support for
that release while it is current. The Release Manager must summarize
the outcome of the vote before the public release becomes final."
>If an action item subject to lazy approval of one of these types gets
a valid veto
I believe the point that needs the most clarification is that "you
can't veto a release - that's a majority decision" (Roy Fielding). Veto
and -1 are not synomous terms.
> A -1 on an individual item is a -1 on the complete plan.
I don't mean to sound inflammatory, but this ~could~ be seen as
mechanism designed to generate -1s. I would think that the guidelines
for a meritocracy would encourage Committers to "show us the code". The
time to thumbs up-or-down the complete package (and sign-up for product
support) is when the final release candidate is locked and loaded.
>This use of the GENERAL list has been announced to the Tomcat
Developers list in at least the following mails:
These changes would affect all of the Jakarta projects, not just
Tomcat.
>But I feel that it's urgent to get a decision on the things directly
related to the Release Proposal approval now, since we will be faced
with such a proposal soon. In fact, we're holding up the TC 3.3
proposal until we have made these clarifications.
I would submit that these are not clarifications, but significant
*changes*. (Which is beginning to sound like another recent discussion
;-).
>That's why I put just selected items up for a vote now, because I
believe it will take quite a bit of time to reach consensus on the
complete package that you're putting together.
If everyone else believes that what we are doing here has been properly
announced, then why not put the full proposal up for a vote and see? As
far as I'm concerned, it's locked and loaded. The CVS copy at
docs/proposal.html is up to date, and there is another reference copy
at < http://husted.com/about/jakarta/ >. If we had 5 PMC votes today,
it could be on the Web site tomorrow.
-Ted.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: [VOTE] Release Plan approval clarifications
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Ted Husted wrote:
>
> Simply as an observer, and newbie Committer, I would ask
>
> + Why are we changing the method of making a release plan vote?
>
> What's broken? Are we fiddling with the time-tested Apache conventions
> here, or were our rules different to begin with?
One of the major concerns at the PMC meeting last week was that a
proposed release to an existing code base, such as TC 3.x, must
come with some kind of guarantee that there are enough Committers
interested in the proposed release to ensure that the result will
be supported. The same concerns have also been discussed on this list
after the meeting, e.g. within the "Formalize a QA Member role"
thread.
To me, the best way to ensure this is to require an active vote for
the Release Plan. With the existing rules, a Release Plan can pass
without any support from the Committers, as long as no one posts a
veto. That's not good enough IMHO, which is why I put this change
up for a vote.
> + Is making the release plan vote "active" a useful approach?
>
> The plans I've seen so far are a collection of issues. Many of these
> are pro-forma, and others are debated. Would we need to vote up or down
> on the release plan as a whole, or each issue? What if the release plan
> issue involved a product change, would that still be elevated to a
> consensus vote?
A -1 on an individual item is a -1 on the complete plan.
According to the existing guidelines, a Product Change is documented
in the status file, subject to lazy consensus. Based on precedence
from previous Release Plans, selected items from the status file are
included in the Release Plan. So, a Product Change will show up as
an item in the Release Plan, and can get a -1 vote just as any other
item.
> + Should we clairify the voting rules without clarifying what people
> are voting on?
>
> The recent PMC minutes clearly states that the criteria for a release
> plan will be clarified, and published to the Tomcat list. Shouldn't
> that happen first?
IMHO, this is part of that clarification: clarify the criteria for
approval of the Release Plan. James got this action item in the meeting,
but since he is traveling, I started the discussion here to help out.
I also announced that I had started this discussion here on the PMC
list, and no one objected (see the "Release voting rules" thread).
I agree that we may also want to clarify exactly what a Release Plan
must contain, the Release Manager role, etc. but for now I feel that
the precedence set by previous Release Plans and the description in
the existing guidelines are sufficient.
> + Is it wise to make this change so quickly?
>
> This affects that way each subproject makes its decisions, and should
> involve all the Committers. The General list has been used this way for
> less than a week, and I am still unsure of whether it's new use has
> been properly announced. I don't believe the PMC should abdicate it's
> authority to make changes, but I do believe a proposal should be
> offered to the Committers for feedback first.
This use of the GENERAL list has been announced to the Tomcat Developers
list in at least the following mails:
* 1/18, Clarification of decision rules [Was: Re: Forming an opinion]
* 1/18, A Note On The PMC Meeting Outcomes
It's also been stated in a number of replies to other threads, and
it's stated on the Mailing List page on the web site:
"This is the project general mailing list. This is where ideas,
suggestions, and comments are exchanged that deal with the
overall Jakarta project. Matters that affect the project as a
whole are decided here."
The clarifications I put up for a vote have been discussed on this
list during the last week or so, and I also announced my intention
to put them up for a vote today in the "Things we need to clarify with
regards to Release Plans" mail on this list on 1/22.
> + Is the definition of Lazy approval accurate? It seems to imply that a
> majority vote is subject to a veto, and then contradicts that later. I
> believe a cleaner approach might be to define the adjective lazy as it
> applies to voting. For example:
>
> "Lazy means the action item has immediate tactic approval, and it is
> not necessary to tally the vote until a -1 reply is posted."
Okay, I agree that it may still not be as clear as it should. How about
this:
Lazy means the action item has immediate tactic approval, and it is
not necessary to tally the vote until a valid veto is posted. The terms
Lazy Consensus and Lazy Majority refer to the type of approval needed
in case of a valid veto. If an action item subject to lazy approval of
one of these types gets a valid veto, the veto must be addressed (by
changing the proposal, by lobbying the person who cast the veto, etc.)
and the vetoed item must be put up for an Active Consensus or Majority
approval vote.
If no one objects, I can use this text when I update the guidelines
(assuming the vote passes).
> + The idea that someone can essentially ask that a veto be "seconded"
> is an interesting idea, but I don't think its been publically discussed
> before.
>
> I'm not disagreeing, but it seems like another big change to make in a
> hurry. Even with this provisiion, two people could still deadlock a
> product release. I personally believe that the PMC should be able to
> overrule a veto with a super-majority vote.
It was discussed in the PMC meeting, see the minutes for Topic 4:
"Vetos with reasons can be challenged, and it requires another person
with voting rights to state that the reason was valid (not necessarily
that they agree, but merely that the reason was valid)."
I also mentioned this in the "Release voting rules" thread.
> + Do we want to start making patchwork changes?
>
> I believe that there are several other clarifications that have been
> discussed here, and we might want to draft a new version of the
> guidelines that people can review in context.
I appreciate all the work you have done, compiling all the discussions
here into a draft version, and I agree that we need to address other
parts of the guidelines as well.
But I feel that it's urgent to get a decision on the things directly
related to the Release Proposal approval now, since we will be faced
with such a proposal soon. In fact, we're holding up the TC 3.3
proposal until we have made these clarifications.
That's why I put just selected items up for a vote now, because I
believe it will take quite a bit of time to reach consensus on the
complete package that you're putting together.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [VOTE] Release Plan approval clarifications
Posted by Ted Husted <ne...@husted.com>.
Simply as an observer, and newbie Committer, I would ask
+ Why are we changing the method of making a release plan vote?
What's broken? Are we fiddling with the time-tested Apache conventions
here, or were our rules different to begin with?
+ Is making the release plan vote "active" a useful approach?
The plans I've seen so far are a collection of issues. Many of these
are pro-forma, and others are debated. Would we need to vote up or down
on the release plan as a whole, or each issue? What if the release plan
issue involved a product change, would that still be elevated to a
consensus vote?
+ Should we clairify the voting rules without clarifying what people
are voting on?
The recent PMC minutes clearly states that the criteria for a release
plan will be clarified, and published to the Tomcat list. Shouldn't
that happen first?
+ Is it wise to make this change so quickly?
This affects that way each subproject makes its decisions, and should
involve all the Committers. The General list has been used this way for
less than a week, and I am still unsure of whether it's new use has
been properly announced. I don't believe the PMC should abdicate it's
authority to make changes, but I do believe a proposal should be
offered to the Committers for feedback first.
+ Is the definition of Lazy approval accurate? It seems to imply that a
majority vote is subject to a veto, and then contradicts that later. I
believe a cleaner approach might be to define the adjective lazy as it
applies to voting. For example:
"Lazy means the action item has immediate tactic approval, and it is
not necessary to tally the vote until a -1 reply is posted."
+ The idea that someone can essentially ask that a veto be "seconded"
is an interesting idea, but I don't think its been publically discussed
before.
I'm not disagreeing, but it seems like another big change to make in a
hurry. Even with this provisiion, two people could still deadlock a
product release. I personally believe that the PMC should be able to
overrule a veto with a super-majority vote.
+ Do we want to start making patchwork changes?
I believe that there are several other clarifications that have been
discussed here, and we might want to draft a new version of the
guidelines that people can review in context.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/about/struts/
Re: [VOTE] Release Plan approval clarifications
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Craig R. McClanahan" wrote:
>
> I'm +1 on the proposed changes, but would add a couple of comments on selected
> paragraphs below. In addition, I share the concerns that Sam raised, especially
> about 24 hour time limit. "Three business days", or something like that, might be a
> better general policy -- and it will also encourage us all to plan ahead a little
> better if we want something done :-).
>
> Craig
>
> Hans Bergsten wrote:
>
> > [snip]
> >
> > On issues where "lazy approval" or consensus is required, a "-1" vote
> > counts as a veto. All vetos must contain an explanation of why the veto is
> > appropriate. Vetos with no explanation are void. A veto can be challenged.
> > It then requires another person with voting rights to state that the
> > explanation is valid (not necessarily that they agree, but merely that the
> > explanation is valid) for the veto to be valid.
> >
> > An action item needs one of three types of approval:
> >
> > Lazy approval
> > An action requiring Lazy Consensus or Lazy Majority approval do not
> > require any +1 votes, but must not receive a binding veto. If it gets a
> > binding veto, the veto must be addressed (by changing the proposal, by
> > lobbying the person who cast the veto, etc.) and the vetoed item must be
> > put up for an Active Consensus or Majority approval vote.
> >
>
> I suggest the term "binding veto" be changed to "valid veto", to be consistent with
> the terminology in the previous paragraph.
Okay. I'll make that change when I update the guidelines (assuming this vote
passes).
> >
> > Active Consensus approval
> > An action requiring Active Consensus approval must receive at least 3
> > binding +1 votes and no binding vetos. The vote message must include a time
> > limit for voting.
> >
>
> s/binding vetos/valid vetos/ as above.
As above.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: [VOTE] Release Plan approval clarifications
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
I'm +1 on the proposed changes, but would add a couple of comments on selected
paragraphs below. In addition, I share the concerns that Sam raised, especially
about 24 hour time limit. "Three business days", or something like that, might be a
better general policy -- and it will also encourage us all to plan ahead a little
better if we want something done :-).
Craig
Hans Bergsten wrote:
> [snip]
>
> On issues where "lazy approval" or consensus is required, a "-1" vote
> counts as a veto. All vetos must contain an explanation of why the veto is
> appropriate. Vetos with no explanation are void. A veto can be challenged.
> It then requires another person with voting rights to state that the
> explanation is valid (not necessarily that they agree, but merely that the
> explanation is valid) for the veto to be valid.
>
> An action item needs one of three types of approval:
>
> Lazy approval
> An action requiring Lazy Consensus or Lazy Majority approval do not
> require any +1 votes, but must not receive a binding veto. If it gets a
> binding veto, the veto must be addressed (by changing the proposal, by
> lobbying the person who cast the veto, etc.) and the vetoed item must be
> put up for an Active Consensus or Majority approval vote.
>
I suggest the term "binding veto" be changed to "valid veto", to be consistent with
the terminology in the previous paragraph.
>
> Active Consensus approval
> An action requiring Active Consensus approval must receive at least 3
> binding +1 votes and no binding vetos. The vote message must include a time
> limit for voting.
>
s/binding vetos/valid vetos/ as above.
Craig