You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Erik de Bruin <er...@ixsoftware.nl> on 2014/12/01 11:07:29 UTC
The 'less-RC' process explained
Hi,
I've put an initial draft for an explanation of the 'less-RC' process
into the Wiki:
https://cwiki.apache.org/confluence/x/2oH0Ag
Please take a look and see if that properly summarizes the previous
discussions we've had.
Thanks,
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I considered that as well, but this project decided to follow this
workflow [1]. That article suggests that bug fixes are made on the
release branch and then (immediately) merged back into develop.
That also makes sense, as the release branch will be as stable as
possible, while develop may or may not be, depending on what is
committed. I don't want to impose any restrictions on the develop
branch, as the 'less-RC' may take considerable time.
Reading the 'stabilizing' article right now, interesting stuff.
EdB
1: http://nvie.com/posts/a-successful-git-branching-model/
On Tue, Dec 2, 2014 at 2:27 PM, Frédéric THOMAS <we...@hotmail.com> wrote:
> Hi Erick,
> Nice introduction, I just wanted to ask, it is written "Any issues found should be fixed - preferably by the reporter - and committed to the 'release' branch", why not fix on the dev branch and cherry picked onto the release one avoiding a merge back to the dev branch ?
> A nice article too [1] btw !
>
> Frédéric THOMAS
> [1] http://producingoss.com/fr/stabilizing-a-release.html
>
>> From: erik@ixsoftware.nl
>> Date: Tue, 2 Dec 2014 09:19:34 +0100
>> Subject: Re: The 'less-RC' process explained
>> To: dev@flex.apache.org
>>
>> Excellent idea. I've added it to the Wiki text.
>>
>> EdB
>>
>>
>>
>> On Mon, Dec 1, 2014 at 9:04 PM, Alex Harui <ah...@adobe.com> wrote:
>> > I’m ok with it too. I would like to see a specific subject tag for the
>> > way the RM "makes his intention” known. How about [LAST CALL]? That
>> > would make it stand out from the usual email traffic.
>> >
>> > -Alex
>> >
>> >
>> > On 12/1/14, 10:26 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
>> > wrote:
>> >
>> >>+1
>> >>
>> >>Looks like it's doable and shows similarities to other development
>> >>projects I have seen. But with a lot less steps.
>> >>
>> >>-Mark
>> >>
>> >>
>> >>-----Original Message-----
>> >>From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>> >>Sent: Monday, December 01, 2014 5:07 AM
>> >>To: dev@flex.apache.org
>> >>Subject: The 'less-RC' process explained
>> >>
>> >>Hi,
>> >>
>> >>I've put an initial draft for an explanation of the 'less-RC' process
>> >>into the Wiki:
>> >>
>> >>https://cwiki.apache.org/confluence/x/2oH0Ag
>> >>
>> >>Please take a look and see if that properly summarizes the previous
>> >>discussions we've had.
>> >>
>> >>Thanks,
>> >>
>> >>EdB
>> >>
>> >>
>> >>
>> >>--
>> >>Ix Multimedia Software
>> >>
>> >>Jan Luykenstraat 27
>> >>3521 VB Utrecht
>> >>
>> >>T. 06-51952295
>> >>I. www.ixsoftware.nl
>> >
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
RE: The 'less-RC' process explained
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi Erick,
Nice introduction, I just wanted to ask, it is written "Any issues found should be fixed - preferably by the reporter - and committed to the 'release' branch", why not fix on the dev branch and cherry picked onto the release one avoiding a merge back to the dev branch ?
A nice article too [1] btw !
Frédéric THOMAS
[1] http://producingoss.com/fr/stabilizing-a-release.html
> From: erik@ixsoftware.nl
> Date: Tue, 2 Dec 2014 09:19:34 +0100
> Subject: Re: The 'less-RC' process explained
> To: dev@flex.apache.org
>
> Excellent idea. I've added it to the Wiki text.
>
> EdB
>
>
>
> On Mon, Dec 1, 2014 at 9:04 PM, Alex Harui <ah...@adobe.com> wrote:
> > I’m ok with it too. I would like to see a specific subject tag for the
> > way the RM "makes his intention” known. How about [LAST CALL]? That
> > would make it stand out from the usual email traffic.
> >
> > -Alex
> >
> >
> > On 12/1/14, 10:26 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
> > wrote:
> >
> >>+1
> >>
> >>Looks like it's doable and shows similarities to other development
> >>projects I have seen. But with a lot less steps.
> >>
> >>-Mark
> >>
> >>
> >>-----Original Message-----
> >>From: Erik de Bruin [mailto:erik@ixsoftware.nl]
> >>Sent: Monday, December 01, 2014 5:07 AM
> >>To: dev@flex.apache.org
> >>Subject: The 'less-RC' process explained
> >>
> >>Hi,
> >>
> >>I've put an initial draft for an explanation of the 'less-RC' process
> >>into the Wiki:
> >>
> >>https://cwiki.apache.org/confluence/x/2oH0Ag
> >>
> >>Please take a look and see if that properly summarizes the previous
> >>discussions we've had.
> >>
> >>Thanks,
> >>
> >>EdB
> >>
> >>
> >>
> >>--
> >>Ix Multimedia Software
> >>
> >>Jan Luykenstraat 27
> >>3521 VB Utrecht
> >>
> >>T. 06-51952295
> >>I. www.ixsoftware.nl
> >
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Excellent idea. I've added it to the Wiki text.
EdB
On Mon, Dec 1, 2014 at 9:04 PM, Alex Harui <ah...@adobe.com> wrote:
> I’m ok with it too. I would like to see a specific subject tag for the
> way the RM "makes his intention” known. How about [LAST CALL]? That
> would make it stand out from the usual email traffic.
>
> -Alex
>
>
> On 12/1/14, 10:26 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
> wrote:
>
>>+1
>>
>>Looks like it's doable and shows similarities to other development
>>projects I have seen. But with a lot less steps.
>>
>>-Mark
>>
>>
>>-----Original Message-----
>>From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>>Sent: Monday, December 01, 2014 5:07 AM
>>To: dev@flex.apache.org
>>Subject: The 'less-RC' process explained
>>
>>Hi,
>>
>>I've put an initial draft for an explanation of the 'less-RC' process
>>into the Wiki:
>>
>>https://cwiki.apache.org/confluence/x/2oH0Ag
>>
>>Please take a look and see if that properly summarizes the previous
>>discussions we've had.
>>
>>Thanks,
>>
>>EdB
>>
>>
>>
>>--
>>Ix Multimedia Software
>>
>>Jan Luykenstraat 27
>>3521 VB Utrecht
>>
>>T. 06-51952295
>>I. www.ixsoftware.nl
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Alex Harui <ah...@adobe.com>.
I’m ok with it too. I would like to see a specific subject tag for the
way the RM "makes his intention” known. How about [LAST CALL]? That
would make it stand out from the usual email traffic.
-Alex
On 12/1/14, 10:26 AM, "Kessler CTR Mark J" <ma...@usmc.mil>
wrote:
>+1
>
>Looks like it's doable and shows similarities to other development
>projects I have seen. But with a lot less steps.
>
>-Mark
>
>
>-----Original Message-----
>From: Erik de Bruin [mailto:erik@ixsoftware.nl]
>Sent: Monday, December 01, 2014 5:07 AM
>To: dev@flex.apache.org
>Subject: The 'less-RC' process explained
>
>Hi,
>
>I've put an initial draft for an explanation of the 'less-RC' process
>into the Wiki:
>
>https://cwiki.apache.org/confluence/x/2oH0Ag
>
>Please take a look and see if that properly summarizes the previous
>discussions we've had.
>
>Thanks,
>
>EdB
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl
RE: The 'less-RC' process explained
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
+1
Looks like it's doable and shows similarities to other development projects I have seen. But with a lot less steps.
-Mark
-----Original Message-----
From: Erik de Bruin [mailto:erik@ixsoftware.nl]
Sent: Monday, December 01, 2014 5:07 AM
To: dev@flex.apache.org
Subject: The 'less-RC' process explained
Hi,
I've put an initial draft for an explanation of the 'less-RC' process
into the Wiki:
https://cwiki.apache.org/confluence/x/2oH0Ag
Please take a look and see if that properly summarizes the previous
discussions we've had.
Thanks,
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Chris Martin <wi...@gmail.com>.
Sounds like we've got a plan. Lets take this baby for another test spin
and see how she handles ;)
On Mon, Dec 1, 2014 at 3:16 AM, Harbs <ha...@gmail.com> wrote:
> Nice, clear concise, explanation.
>
> On Dec 1, 2014, at 12:07 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
>
> > Hi,
> >
> > I've put an initial draft for an explanation of the 'less-RC' process
> > into the Wiki:
> >
> > https://cwiki.apache.org/confluence/x/2oH0Ag
> >
> > Please take a look and see if that properly summarizes the previous
> > discussions we've had.
> >
> > Thanks,
> >
> > EdB
> >
> >
> >
> > --
> > Ix Multimedia Software
> >
> > Jan Luykenstraat 27
> > 3521 VB Utrecht
> >
> > T. 06-51952295
> > I. www.ixsoftware.nl
>
>
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
Nice, clear concise, explanation.
On Dec 1, 2014, at 12:07 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Hi,
>
> I've put an initial draft for an explanation of the 'less-RC' process
> into the Wiki:
>
> https://cwiki.apache.org/confluence/x/2oH0Ag
>
> Please take a look and see if that properly summarizes the previous
> discussions we've had.
>
> Thanks,
>
> EdB
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
Understood.
Go tweak the wording on the wiki until you’re happy that it reads correctly. I don’t think anyone would have issues with that.
If anyone wants to then tweak it further, great. That’s what wikis are for! ;-)
On Dec 3, 2014, at 12:04 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> I don’t think Erik was trying to be so precise with his wording.
>
> I just want to make sure we're not trying to introduce consensus for releases via this new process. It really needs to be made clear that releases are by majority approval only (ie 3+1 more +1s than -1s) not consensus (3 +1s and a -1 is a veto). The wording as it is currently reads to me that a "blocker" is basically a veto and thus you need consensus before making a release candidate, that's against Apache policy and we can't have a release process that does that.
>
> Thanks,
> Justin
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I don’t think Erik was trying to be so precise with his wording.
I just want to make sure we're not trying to introduce consensus for releases via this new process. It really needs to be made clear that releases are by majority approval only (ie 3+1 more +1s than -1s) not consensus (3 +1s and a -1 is a veto). The wording as it is currently reads to me that a "blocker" is basically a veto and thus you need consensus before making a release candidate, that's against Apache policy and we can't have a release process that does that.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
Justin,
I don’t think Erik was trying to be so precise with his wording. I think we’re all aware of policy already.
Why don’t you fix any wording you feel is inaccurate? If anyone has issues with your corrections, the wording can be reverted and/or discussed.
Thanks,
Harbs
On Dec 2, 2014, at 10:41 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I'd like to see a few corrections/changes to this process as described.
>
> Re "packaged and signed by a representative of the organization and voted to be valid by the contributors of the project." - as per Apache policy anyone can make a release (but it would be hard if you were not a committer) but only PMC votes are binding on releases, committers or other contributors can vote but their votes are not binding.
>
> RE "the voting process is repeated until no new blocking issues are found in the artifacts." it actually repeated until there 3+1 votes and more +1s than -1s. A release may include something that someone considers a blocker, if it gets enough +!s.
>
> RE "As soon as someone finds a blocking issue, the entire process stops." This is not normally the case, and in fact has been the cause of excessive RC in the past, you would want to PMC to continue to check the release for other issues even f there is a blocker, and again one persons "blocker" (ie spelling issues) may not be anothers, consensus (while nice to have) is not required for releases. We have had a couple of releases that passed with -1s.
>
> RE "The issue if fixed or the issue is discussed until consensus is reached." this is against Apache release policy. Consensus is not required for releases.
>
> RE "Any issues found should be fixed - preferably by the reporter " it not always going to be possible that the person who reports the issue can fix it.
>
> I'd also note that this was basically the process we took for TourDeFlex but it resulted in having 3 release candidates.
>
> Thanks,
> Justin
>
>
Re: The 'less-RC' process explained
Posted by Erik de Bruin <er...@ixsoftware.nl>.
As a PMC I'm very much aware of the Apache voting rules, as a project
we have codified them in our guidelines. I very much resent the
implication from Justin that I am not familiar with them :-(
On the article: Justin has really taken this whole discussion way out
of context, as the paragraph he keeps going on about is actually an
informal summary of the current way we do releases (codified elsewhere
on the Wiki), NOT a guide for the proposed 'less-RC' process.
Feel free to do to the article what you want, it's a Wiki after all,
but realize that this whole discussion is based on an incorrect
reading of the original text. To me, changing it into something that
it was never intended to be - an official guideline for 'less-RC' - is
a total waste of our time.
One I will gladly try to ignore from here on out.
EdB
On Wed, Dec 3, 2014 at 7:58 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean <ju...@classsoftware.com> wrote:
>> ...I'll look at the changes and make some more edits later today if I some time....
>
> Cool - so it looks like there's no need to discuss this further, until
> Justin makes those edits and reports here that he's happy with the
> result.
>
> Justin, I'm happy to review that document as well once you're at that
> point, from my point of view of making things as simple as possible
> and sticking to the Apache-wide definitions of voting options listed
> at http://www.apache.org/foundation/voting.html
>
> -Bertrand
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by OmPrakash Muppirala <bi...@gmail.com>.
Justin, it is not clear whose email you are responding to. Can you please
clarify?
Thanks,
Om
On Thu, Dec 4, 2014 at 1:12 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > You are actively discouraging non-PMC members to participate in the
> > release process by repeatedly explaining how their votes are worth
> > nothing.
>
> Really? I had added "although others are also encouraged to vote." and
> only PMC votes are binding on releases, we shouldn't state otherwise.
>
> > You have edited the paragraph that talks about the 'old' release
> > process to read as if it were part of the new proposal.
>
> I corrected it where I thought it was needed.
>
> > Re: 1. A possible blocker is discussed, and if there is no majority
> > opinion apparent, a vote is called
>
> The was no mention of a vote in fact voting is actively discouraged until
> the last RC. This happened with the last TourDeFlex release and it was left
> in limbo for a while because of this. Now however you saying you can vote
> along the way, so how exactly is this different to the current release
> process how? In that we we get a blocker it's discussed and a new RC
> created and voted on.
>
> > Re: 2. Are you suggesting we don't allow work on 'develop' during a
> release?
>
> No.
>
> > Re: 3. The language implies that, not? "should" does not equal "have
> > to" or "need".
>
> I think "should" is a little too strong here.
>
> > Re: 4: The start of that sentence holds the information you are looking
> for...
>
> So voting is the answer? Again why not stick to the currently process
> which handles that quite well?
>
> > Re: 5: As stated only one paragraph earlier, if a discussion gets to
> > lengthy it gets it's own thread.
>
> Seams reasonable.
>
> > Re: 6: How can that possibly be against Apache policy.
>
> It's the PMC who decides by voting that a release should be made not the
> RM.
>
> Thanks,
> Justin
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> You are actively discouraging non-PMC members to participate in the
> release process by repeatedly explaining how their votes are worth
> nothing.
Really? I had added "although others are also encouraged to vote." and only PMC votes are binding on releases, we shouldn't state otherwise.
> You have edited the paragraph that talks about the 'old' release
> process to read as if it were part of the new proposal.
I corrected it where I thought it was needed.
> Re: 1. A possible blocker is discussed, and if there is no majority
> opinion apparent, a vote is called
The was no mention of a vote in fact voting is actively discouraged until the last RC. This happened with the last TourDeFlex release and it was left in limbo for a while because of this. Now however you saying you can vote along the way, so how exactly is this different to the current release process how? In that we we get a blocker it's discussed and a new RC created and voted on.
> Re: 2. Are you suggesting we don't allow work on 'develop' during a release?
No.
> Re: 3. The language implies that, not? "should" does not equal "have
> to" or "need".
I think "should" is a little too strong here.
> Re: 4: The start of that sentence holds the information you are looking for...
So voting is the answer? Again why not stick to the currently process which handles that quite well?
> Re: 5: As stated only one paragraph earlier, if a discussion gets to
> lengthy it gets it's own thread.
Seams reasonable.
> Re: 6: How can that possibly be against Apache policy.
It's the PMC who decides by voting that a release should be made not the RM.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by Alex Harui <ah...@adobe.com>.
The wiki page had become annotated with issue discussions. I just rewrote
the entire document, trying to make it shorter, removing history and
rationale and just describing the steps, but addressing/clarifing issues
raised. I left the original document below so you can compare and make
sure your important points are still included.
Hopefully this will help, but maybe it won’t. I’m off to bed, and will
check feedback in the morning.
-Alex
On 12/4/14, 5:01 PM, "OmPrakash Muppirala" <bi...@gmail.com> wrote:
>On Thu, Dec 4, 2014 at 4:52 PM, Justin Mclean <ju...@me.com> wrote:
>
>> Hi,
>>
>> > You interpreted it wrong. That voter thought non-binding meant a -1
>> vote.
>> > Please read that email carefully.
>>
>> I don't think so, but either way, it shows the need for clarity around
>> who's votes are binding. I notice the link was edited in the Wiki to
>> include all the content and not just link to "Majority Approval" I guess
>> that sorts the issue, but does water down the original intention of the
>> link.
>>
>
>Thanks for coming to a compromise. Let's move on, please.
>
>Regards,
>Om
Re: The 'less-RC' process explained
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Dec 4, 2014 at 4:52 PM, Justin Mclean <ju...@me.com> wrote:
> Hi,
>
> > You interpreted it wrong. That voter thought non-binding meant a -1
> vote.
> > Please read that email carefully.
>
> I don't think so, but either way, it shows the need for clarity around
> who's votes are binding. I notice the link was edited in the Wiki to
> include all the content and not just link to "Majority Approval" I guess
> that sorts the issue, but does water down the original intention of the
> link.
>
Thanks for coming to a compromise. Let's move on, please.
Regards,
Om
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@me.com>.
Hi,
> You interpreted it wrong. That voter thought non-binding meant a -1 vote.
> Please read that email carefully.
I don't think so, but either way, it shows the need for clarity around who's votes are binding. I notice the link was edited in the Wiki to include all the content and not just link to "Majority Approval" I guess that sorts the issue, but does water down the original intention of the link.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Dec 4, 2014 at 4:19 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > Are you referring to this post? [1]
>
> Yes.
>
> > The poster just thought that non-binding meant he voted against the
> > release, not whether his vote counted or not.
>
> My reading of that post was that he assumed his +1 counted and was
> surprised when it didn't and was saying "but I voted for it why doesn't my
> vote count". It was sorted quickly but still something to consider.
>
You interpreted it wrong. That voter thought non-binding meant a -1 vote.
Please read that email carefully.
Thanks,
Om
>
> Thanks,
> Justin
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Are you referring to this post? [1]
Yes.
> The poster just thought that non-binding meant he voted against the
> release, not whether his vote counted or not.
My reading of that post was that he assumed his +1 counted and was surprised when it didn't and was saying "but I voted for it why doesn't my vote count". It was sorted quickly but still something to consider.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by Chris Martin <wi...@gmail.com>.
> I made a minor edit to the small print to include a note that PMC votes
are counted as binding. Hopefully
> that completes the definition of "Majority Approval" for our group.
Well that was fast. Hehe, so I thought the "here" link was pointing to the
definition of "Majority Approval", not the voting page. So my edit doesn't
make sense in that context. I've removed it :)
Chris
On Thu, Dec 4, 2014 at 4:08 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 12/4/14, 2:43 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> >Hi,
> >
> >> No need for a solution since there is no problem. What exactly is the
> >> issue you are trying to solve? Who do you think needs this
> >>clarification?
> >
> >Currently as it reads is that votes on release are "Majority Approval",
> >that's correct/good but not the whole picture. If a committer or user
> >votes on a release they may be this disappointed to find out later that
> >their vote didn't count.
>
> Are you referring to this post? [1]
>
> The poster just thought that non-binding meant he voted against the
> release, not whether his vote counted or not.
>
> -Alex
>
> [1] http://s.apache.org/EVI
>
>
Re: The 'less-RC' process explained
Posted by Chris Martin <wi...@gmail.com>.
Hey everyone,
I made a minor edit to the small print to include a note that PMC votes are
counted as binding. Hopefully that completes the definition of "Majority
Approval" for our group.
I welcome any edits to the above, as I'm still the new guy here ;)
Also made my replies to the numbered issues if I felt my thoughts would add
to or improve upon the existing answers. If I didn't answer, it means I
was in agreement with the response and didn't feel the need to add more.
I like it gentlemen. I feel we are making progress.
Chris
On Thu, Dec 4, 2014 at 3:48 PM, Harbs <ha...@gmail.com> wrote:
> On Dec 5, 2014, at 12:43 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
>
> > IMO would be a good idea to make it clear.
>
>
> What’s not clear about the following?
>
> The Small Print
> All votes mentioned on this page are as defined on the official voting
> page here[1].
>
> [1]http://www.apache.org/foundation/voting.html
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
On Dec 5, 2014, at 12:43 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> IMO would be a good idea to make it clear.
What’s not clear about the following?
The Small Print
All votes mentioned on this page are as defined on the official voting page here[1].
[1]http://www.apache.org/foundation/voting.html
Re: The 'less-RC' process explained
Posted by Alex Harui <ah...@adobe.com>.
On 12/4/14, 2:43 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>Hi,
>
>> No need for a solution since there is no problem. What exactly is the
>> issue you are trying to solve? Who do you think needs this
>>clarification?
>
>Currently as it reads is that votes on release are "Majority Approval",
>that's correct/good but not the whole picture. If a committer or user
>votes on a release they may be this disappointed to find out later that
>their vote didn't count.
Are you referring to this post? [1]
The poster just thought that non-binding meant he voted against the
release, not whether his vote counted or not.
-Alex
[1] http://s.apache.org/EVI
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> No need for a solution since there is no problem. What exactly is the
> issue you are trying to solve? Who do you think needs this clarification?
Currently as it reads is that votes on release are "Majority Approval", that's correct/good but not the whole picture. If a committer or user votes on a release they may be this disappointed to find out later that their vote didn't count. This happened recently so IMO would be a good idea to make it clear.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Dec 4, 2014 at 1:14 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > There is a link to
> > http://www.apache.org/foundation/glossary.html#MajorityApproval which
> has
> > the correct definitions.
>
> It exmplain what "Majority Approval" is but not that only PMC vote are
> binding. Perhaps a solution is to add a link to our own guidelines with a
> link to voting on releases.
No need for a solution since there is no problem. What exactly is the
issue you are trying to solve? Who do you think needs this clarification?
Thanks,
Om
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> There is a link to
> http://www.apache.org/foundation/glossary.html#MajorityApproval which has
> the correct definitions.
It exmplain what "Majority Approval" is but not that only PMC vote are binding. Perhaps a solution is to add a link to our own guidelines with a link to voting on releases.
Justin
Re: The 'less-RC' process explained
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Thu, Dec 4, 2014 at 1:00 PM, Justin Mclean <ju...@classsoftware.com>
wrote:
> Hi,
>
> > I think I’ve edited the page to take care of Justin’s concerns without
> it being too “in your face”…
>
> I'm not sure of removal of any reference to the PMC is correct, only PMC
> members votes are binding on releases.
>
>
There is a link to
http://www.apache.org/foundation/glossary.html#MajorityApproval which has
the correct definitions. There is no need to make this wiki page any more
verbose than it is needed.
Thanks,
Om
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
That’s the “small print” on the bottom. If someone does not know what a vote is, they can read the link. It’s all explained in detail.
On Dec 4, 2014, at 11:00 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> I think I’ve edited the page to take care of Justin’s concerns without it being too “in your face”…
>
> I'm not sure of removal of any reference to the PMC is correct, only PMC members votes are binding on releases.
>
> Thanks,
> Justin
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I think I’ve edited the page to take care of Justin’s concerns without it being too “in your face”…
I'm not sure of removal of any reference to the PMC is correct, only PMC members votes are binding on releases.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
I think I’ve edited the page to take care of Justin’s concerns without it being too “in your face”…
On Dec 4, 2014, at 3:47 PM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> You are actively discouraging non-PMC members to participate in the
> release process by repeatedly explaining how their votes are worth
> nothing.
Re: The 'less-RC' process explained
Posted by Erik de Bruin <er...@ixsoftware.nl>.
You are actively discouraging non-PMC members to participate in the
release process by repeatedly explaining how their votes are worth
nothing.
You have edited the paragraph that talks about the 'old' release
process to read as if it were part of the new proposal. It is not. The
text you have edited described the de facto practise of releases being
blocked as long as there was a discussion going on.
Re: 1. A possible blocker is discussed, and if there is no majority
opinion apparent, a vote is called (as with all discussions under the
new regime). This means that if only one PMC thinks something is a
blocker, it will save time for that person to just give up and save
the others the trouble and time a vote takes.
Re: 2. Are you suggesting we don't allow work on 'develop' during a release?
Re: 3. The language implies that, not? "should" does not equal "have
to" or "need".
Re: 4: The start of that sentence holds the information you are looking for...
Re: 5: As stated only one paragraph earlier, if a discussion gets to
lengthy it gets it's own thread.
Re: 6: You're again reading and quoting out of context. The text
describes only the final stages of the release, when (as it states
just after your comment) everything but issues related to the creation
of the release artefacts will have been long ironed out. It is
intended to clarify that at that point any issues raised that are not
blocking that actual release process (like missing/wrong signatures)
will have to be deferred to the next release. How can that possibly be
against Apache policy. The mere suggestion that is might be sounds
like FUD to me :-(
This was my last contribution to this discussion, and I don't want to
get into an edit war on the Wiki, so I'll leave it up to the other
contributors to sort this out.
EdB
On Wed, Dec 3, 2014 at 10:17 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
>> Cool - so it looks like there's no need to discuss this further, until
>> Justin makes those edits and reports here that he's happy with the
>> result.
>
> Done. I've also marked up what I think the issues are with this approach.
>
> If we are going to introduce a new release procedure, we need to make sure it documented and clearly understood. It would be better to discuss and sort out these issues up front rather than when we start using it. We also have to very carefully check that it is in line with Apache release policies, I'm still not convinced that this is the case with this new process.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
> Done. I've also marked up what I think the issues are with this approach.
I’ve responded to all the issues with my point of view.
Thanks,
Harbs
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Cool - so it looks like there's no need to discuss this further, until
> Justin makes those edits and reports here that he's happy with the
> result.
Done. I've also marked up what I think the issues are with this approach.
If we are going to introduce a new release procedure, we need to make sure it documented and clearly understood. It would be better to discuss and sort out these issues up front rather than when we start using it. We also have to very carefully check that it is in line with Apache release policies, I'm still not convinced that this is the case with this new process.
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...I'll look at the changes and make some more edits later today if I some time....
Cool - so it looks like there's no need to discuss this further, until
Justin makes those edits and reports here that he's happy with the
result.
Justin, I'm happy to review that document as well once you're at that
point, from my point of view of making things as simple as possible
and sticking to the Apache-wide definitions of voting options listed
at http://www.apache.org/foundation/voting.html
-Bertrand
Re: The 'less-RC' process explained
Posted by Harbs <ha...@gmail.com>.
Hi Justin,
Please don’t read too much into things. We all agree that a vote is 3 +1 votes. “Agreement” does not mean anything more than that.
Of course if it’s reasonable to address issues even beyond the “binding” votes, I’d assume that a reasonable effort would be done to do that.
Like I said before, if you are concerned about the wording, the simplest way to resolve that is to just edit the wiki…
Thanks,
Harbs
Re: The 'less-RC' process explained
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> ...Perhaps "some agreement" or "general agreement" is a better term? You may consider
> that an unnecessary distinction but I really think that the PMC as a whole misses this
> rather important point about releases....
I was going to comment on that - sticking to the ASF-wide voting
"modes" of http://www.apache.org/foundation/voting.html would IMO help
make sure everybody's on the same page.
That provides the following 3 options:
"majority approval" which is defined at
http://www.apache.org/foundation/glossary.html#MajorityApproval
"veto", defined at http://www.apache.org/foundation/glossary.html#Veto
which only applies to commits
"lazy consensus" as per
http://www.apache.org/foundation/glossary.html#LazyConsensus
I suppose Flex can live with these options, you could then just use
these terms and refer to the above pages which are standard Apache
definitions, to spare yourself the burden of defining your own
variants.
-Bertrand
Re: The 'less-RC' process explained
Posted by Chris Martin <wi...@gmail.com>.
Hey everyone,
Thanks Bertrand for the info. At some point I think we should change the
wording to be more of what we intend. Mainly
because Bertrand makes a good point by pointing out a "burden of defining
your own variants" is being made. I actually registered to change agreement
to "majority approval" as that is what we are looking for, but I don't see
an "edit" option after I've created my account. It's probably in a special
state because it was just created.
I like the idea of working out the process definition a little to make it
more official. I feel if we firm up the definition and continue to firm it
up as we go along, this process stands a better chance of being successful.
Chris
On Wed, Dec 3, 2014 at 6:08 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Justin,
>
> I couldn't have twisted what I actually wrote any further out of
> context than you did, even if I tried really hard.
>
> I refuse to be drawn into a 'blow-by-blow' rebuttal of your
> misunderstandings. I urge you to spend the time you intend to spend
> talking yet another well-intentioned effort to death on fixing bugs
> and adding features instead.
>
> Is the article perfect? No. Does it need to be? Certainly not,
> according to every PMC member and contributor that read it - all but
> you, predictably, unfortunately and sadly :-(
>
> EdB
>
>
>
> On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean <ju...@classsoftware.com>
> wrote:
> > Hi,
> >
> > I'll look at the changes and make some more edits later today if I some
> time.
> >
> >> I've changed 'consensus' to 'agreement'
> >
> > While consensus has a well defined meaning under Apache (especially in
> voting), basically agreement means the same thing here. There is no
> requirement for agreement for publishing a release. (again all it requires
> is a majority vote of 3 +1 and more +1s than -1s). Perhaps "some agreement"
> or "general agreement" is a better term? You may consider that an
> unnecessary distinction but I really think that the PMC as a whole misses
> this rather important point about releases.
> >
> > I have concerns about a release process that seems on face value to be a
> single vote only after consensus / agreement is reached and that treats any
> "blockers" along the way as vetoes. It comes from good intentions (trying
> to reducing the workload on the PMC) but may not be in alignment with
> Apache release policy.
> >
> > Perhaps Bertrand or Rich would care to comment on this?
> >
> > Thanks,
> > Justin
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
Re: The 'less-RC' process explained
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Justin,
I couldn't have twisted what I actually wrote any further out of
context than you did, even if I tried really hard.
I refuse to be drawn into a 'blow-by-blow' rebuttal of your
misunderstandings. I urge you to spend the time you intend to spend
talking yet another well-intentioned effort to death on fixing bugs
and adding features instead.
Is the article perfect? No. Does it need to be? Certainly not,
according to every PMC member and contributor that read it - all but
you, predictably, unfortunately and sadly :-(
EdB
On Wed, Dec 3, 2014 at 8:40 AM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I'll look at the changes and make some more edits later today if I some time.
>
>> I've changed 'consensus' to 'agreement'
>
> While consensus has a well defined meaning under Apache (especially in voting), basically agreement means the same thing here. There is no requirement for agreement for publishing a release. (again all it requires is a majority vote of 3 +1 and more +1s than -1s). Perhaps "some agreement" or "general agreement" is a better term? You may consider that an unnecessary distinction but I really think that the PMC as a whole misses this rather important point about releases.
>
> I have concerns about a release process that seems on face value to be a single vote only after consensus / agreement is reached and that treats any "blockers" along the way as vetoes. It comes from good intentions (trying to reducing the workload on the PMC) but may not be in alignment with Apache release policy.
>
> Perhaps Bertrand or Rich would care to comment on this?
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I'll look at the changes and make some more edits later today if I some time.
> I've changed 'consensus' to 'agreement'
While consensus has a well defined meaning under Apache (especially in voting), basically agreement means the same thing here. There is no requirement for agreement for publishing a release. (again all it requires is a majority vote of 3 +1 and more +1s than -1s). Perhaps "some agreement" or "general agreement" is a better term? You may consider that an unnecessary distinction but I really think that the PMC as a whole misses this rather important point about releases.
I have concerns about a release process that seems on face value to be a single vote only after consensus / agreement is reached and that treats any "blockers" along the way as vetoes. It comes from good intentions (trying to reducing the workload on the PMC) but may not be in alignment with Apache release policy.
Perhaps Bertrand or Rich would care to comment on this?
Thanks,
Justin
Re: The 'less-RC' process explained
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I've changed 'consensus' to 'agreement' and removed the bit about the
reporter doing the fix.
Justin, thank you for your contribution. Please keep in mind this is
not a legal document, only a rough outline of a process.
Now let's move on, I'm sure everyone will agree more than enough time
has been spent on this topic.
Thanks all, now let's fix some bugs and see if 'less-RC' will lead to
a 'more-SMOOTH' release ;-)
EdB
On Tue, Dec 2, 2014 at 9:41 PM, Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> I'd like to see a few corrections/changes to this process as described.
>
> Re "packaged and signed by a representative of the organization and voted to be valid by the contributors of the project." - as per Apache policy anyone can make a release (but it would be hard if you were not a committer) but only PMC votes are binding on releases, committers or other contributors can vote but their votes are not binding.
>
> RE "the voting process is repeated until no new blocking issues are found in the artifacts." it actually repeated until there 3+1 votes and more +1s than -1s. A release may include something that someone considers a blocker, if it gets enough +!s.
>
> RE "As soon as someone finds a blocking issue, the entire process stops." This is not normally the case, and in fact has been the cause of excessive RC in the past, you would want to PMC to continue to check the release for other issues even f there is a blocker, and again one persons "blocker" (ie spelling issues) may not be anothers, consensus (while nice to have) is not required for releases. We have had a couple of releases that passed with -1s.
>
> RE "The issue if fixed or the issue is discussed until consensus is reached." this is against Apache release policy. Consensus is not required for releases.
>
> RE "Any issues found should be fixed - preferably by the reporter " it not always going to be possible that the person who reports the issue can fix it.
>
> I'd also note that this was basically the process we took for TourDeFlex but it resulted in having 3 release candidates.
>
> Thanks,
> Justin
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: The 'less-RC' process explained
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
I'd like to see a few corrections/changes to this process as described.
Re "packaged and signed by a representative of the organization and voted to be valid by the contributors of the project." - as per Apache policy anyone can make a release (but it would be hard if you were not a committer) but only PMC votes are binding on releases, committers or other contributors can vote but their votes are not binding.
RE "the voting process is repeated until no new blocking issues are found in the artifacts." it actually repeated until there 3+1 votes and more +1s than -1s. A release may include something that someone considers a blocker, if it gets enough +!s.
RE "As soon as someone finds a blocking issue, the entire process stops." This is not normally the case, and in fact has been the cause of excessive RC in the past, you would want to PMC to continue to check the release for other issues even f there is a blocker, and again one persons "blocker" (ie spelling issues) may not be anothers, consensus (while nice to have) is not required for releases. We have had a couple of releases that passed with -1s.
RE "The issue if fixed or the issue is discussed until consensus is reached." this is against Apache release policy. Consensus is not required for releases.
RE "Any issues found should be fixed - preferably by the reporter " it not always going to be possible that the person who reports the issue can fix it.
I'd also note that this was basically the process we took for TourDeFlex but it resulted in having 3 release candidates.
Thanks,
Justin