One of the reasons Justin may think we have trouble getting enough votes
is because of another interesting dynamic in Flex. When someone votes -1
on an RC because they found what they think is an important bug, folks
tend to stop testing and voting. I’ve actually tried not voting -1 and
simply as
That's true for me. If it's got enough votes to pass, by people I trust,
and I'm really busy, then I wont test it myself, or it I do it wont be
formally enough to be worth a +1
Tom
On 05/12/14 12:14, Erik de Bruin wrote:
I think what we've seen is that all VOTEs get just enough votes to
pass
You can remove yourself from the list:
Subscribe: dev-subscr...@flex.apache.org
Post (after subscription): dev@flex.apache.org
Unsubscribe: dev-unsubscr...@flex.apache.org
Subscribe to digest: dev-digest-subscr...@flex.apache.org
Unsubscribe to digest: dev-digest-unsubscr...@flex.apache.org
On De
I think what we've seen is that all VOTEs get just enough votes to
pass because once enough passing votes are in, people choose to spend
the little time they have available for the projects on something
else.
3 votes are enough for a release, and I don't think we have to be
afraid of not reaching
Please remove me from this list.
2014-12-05 12:00 GMT+00:00 Bertrand Delacretaz :
> On Friday, December 5, 2014, Jeffry Houser wrote:
>
> > ...Could part of the problem we have too many projects under the Apache
> Flex banner?
> > Do other Apache projects have 9+ completely separated, but relate
On Friday, December 5, 2014, Jeffry Houser wrote:
> ...Could part of the problem we have too many projects under the Apache
Flex banner?
> Do other Apache projects have 9+ completely separated, but related,
projects?...
The key is not how many modules you are managing but whether those belong
to
On 12/5/2014 4:18 AM, Justin Mclean wrote:
most of the recent (last 6 months) Squiggly, Tour De Flex, FlexJS, Falcon
releases have only have 3 or 4 votes each. (If you need links just ask).
Could part of the problem we have too many projects under the Apache
Flex banner?
Do other Apache pro
-Original Message-
From: Valdemar Lopes [mailto:valdemarlo...@gmail.com]
Sent: Friday, December 05, 2014 5:43 AM
To: dev@flex.apache.org
Subject: Re: [TTH] vetoes get in the way
Please remove me from this list.
2014-12-05 10:39 GMT+00:00 Harbs :
> On Dec 5, 2014, at 11:18 AM, Justin Mclean
>
Agreed.
I think this discussion has gone on long enough. Time to stop trying
to convince each other, as that obviously is not going to happen.
Is there something here that can be resolved by a vote? If so, please
start a VOTE thread.
Otherwise let's end this discussion and move on.
Thanks,
EdB
On Fr
Again, you seem to have a different definition of “should”[1]. Nowhere does it
state that if you do not mention it when you start the thread, the votes can
not carry over.
Of course it’s the RM’s choice. No one has stated that Om’s vote was valid if
you refused to carry it over. You said you CO
Please remove me from this list.
2014-12-05 10:39 GMT+00:00 Harbs :
> On Dec 5, 2014, at 11:18 AM, Justin Mclean
> wrote:
>
> > Being the release manager many time I can say that getting 3 or 4 vote
> is hard.
>
> The point of the “less RC” process it to try to make it easier on everyone
> to pa
Hi,
>> As per our guidelines the votes need to be carried other in the VOTE for the
>> RC and I didn't do that.
>
> That’s simply not true.
Yes it is: [1]
"When voting on release candidates the release manager at their discretion can
carry over votes from the previous release candidate if ther
On Dec 5, 2014, at 11:18 AM, Justin Mclean wrote:
> Being the release manager many time I can say that getting 3 or 4 vote is
> hard.
The point of the “less RC” process it to try to make it easier on everyone to
participate, so the hope is that this will improve over time. If getting votes
is
On Dec 5, 2014, at 11:28 AM, Justin Mclean wrote:
> As per our guidelines the votes need to be carried other in the VOTE for the
> RC and I didn't do that.
That’s simply not true.
A vote can be carried over if the person who voted requested it should be
carried over. It was stated by numerou
Hi,
> Om did ask his vote to be carried over, repeatedly and explicitly.
As per our guidelines the votes need to be carried other in the VOTE for the RC
and I didn't do that. I would of had to cancel that RC and make another one in
order to carry over votes. If it was a change to a read me or s
> Ok, I didn't study the details but I agree that you cannot carry over
> votes from one release candidate to the next, for example, without
> voters individually and explicitly indicating that you can do so. This
Om did ask his vote to be carried over, repeatedly and explicitly.
http://markmail.
HI,
> In this particular instance, Justin decided to discard 2 votes instead of
> carrying them over
As I (not unreasonably IMO) thought that changes to a NOTICE file required PMC
overview before making a release. But even with those 2 votes were counted
there were only 4 votes. The final rele
On Fri, Dec 5, 2014 at 10:07 AM, Justin Mclean wrote:
>> ...Does this PMC have trouble getting 4 people voting on a release?
> Yes, sometimes it hard to get 3 or 4 votes
Ok, so that's something that this PMC should eventually fix - either
by electing more deserving PMC members, or convincing
On Fri, Dec 5, 2014 at 10:01 AM, Erik de Bruin wrote:
> ...In this particular instance, Justin decided to discard 2 votes instead
> of carrying them over, which the majority of the participating PMC
> members were advocating...
Ok, I didn't study the details but I agree that you cannot carry over
Hi,
> Does this PMC have trouble getting 4 people voting on a release?
Yes, sometimes it hard to get 3 or 4 votes.
> Either there's not enough active PMC members
That's certainly part of it.
Justin
> If you guys have trouble getting 4 voters, something's wrong. Either
In this particular instance, Justin decided to discard 2 votes instead
of carrying them over, which the majority of the participating PMC
members were advocating. He put himself in the position he's now
complaining about.
EdB
Hi,
On Fri, Dec 5, 2014 at 9:19 AM, Justin Mclean wrote:
> ...The process is described here [1] which references [2] and
> best practise described here [3]...
Apart from not having vetoes on release votes, the only things that
the ASF requires about releases are captured in this excerpt from [1]
Justin,
This shows you do not understand the 'less-RC' process. The major
difference between current and 'less-RC' is in the period leading up
to the creation of the first RC. The process once the first RC has
been posted and a vote has been started is the same and therefore
remains in accordance
None of the links you provided describe anything to do with how a progression
towards a release should work. It only described the release process itself.
Nor do they describe how discussions should work. (Not should they.)
I’m not sure what these “several bits” that you refer to are. The one th
Hi,
> Could you please show us where this “standard release process” is documented,
> and explain how we are somehow deferring from this “standard”?
The process is described here [1] which references [2] and best practise
described here [3] and there is a work in progress with clearer MUSTs and
Justin,
Could you please show us where this “standard release process” is documented,
and explain how we are somehow deferring from this “standard”?
Thanks,
Harbs
On Dec 5, 2014, at 9:12 AM, Justin Mclean wrote:
> Hi,
>
>> That's why I recommend following the standard Apache rules and
>> rec
Hi,
> That's why I recommend following the standard Apache rules and
> recommendations. at [1] And also, as I said, because Flex is a
> relatively small PMC that can save energy by just sticking to the ASF
> standard things, without having to spend much time discussing its own
> variants.
I'm int
Hi,
On Thu, Dec 4, 2014 at 6:28 PM, Alex Harui wrote:
> ...the reason our guidelines require consensus for adding
> people is because of this document [1] and some advice from other
> experienced non-Flex Apache people that having consensus for adding folks
> is important...
I agree if consensus
Hi,
> For some context, the reason our guidelines require consensus for adding
> people is because of this document [1]
And also was inline with other project Guidelines we looked at.[1]
We actually relaxed some of the HTTP projects guidelines ie only PMC members
can veto code changes (we allow
On 12/4/14, 5:47 AM, "Bertrand Delacretaz" wrote:
>On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
>> ...If you feel it should be changed anyway, I have no objections to
>>that...
>
>I havent checked if allowing vetoes for many things has caused
>problems or not so far but I see a potential for c
On Dec 4, 2014 7:19 AM, "Bertrand Delacretaz"
wrote:
>
> On Thursday, December 4, 2014, OmPrakash Muppirala
> wrote:
>
> > BTW, what does the TTH in the subject line strands for?
>
> Trying To Help - I made that up a few days ago,
> http://flex.markmail.org/thread/re2q3mxlzws76x26
Ah, I missed t
On Thursday, December 4, 2014, OmPrakash Muppirala
wrote:
> BTW, what does the TTH in the subject line strands for?
Trying To Help - I made that up a few days ago,
http://flex.markmail.org/thread/re2q3mxlzws76x26
-Bertrand
I'm on board with this. I like the idea of taking "the edge off" a -1 vote
On Thu, Dec 4, 2014 at 6:47 AM, Bertrand Delacretaz
wrote:
> On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> > ...If you feel it should be changed anyway, I have no objections to
> that...
>
> I havent checked if allowin
BTW, what does the TTH in the subject line strands for?
Thanks,
Om
On Dec 4, 2014 7:14 AM, "OmPrakash Muppirala" wrote:
>
> On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz"
> wrote:
> >
> > On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> > > ...If you feel it should be changed anyway, I have no ob
On Dec 4, 2014 5:47 AM, "Bertrand Delacretaz"
wrote:
>
> On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> > ...If you feel it should be changed anyway, I have no objections to
that...
>
> I havent checked if allowing vetoes for many things has caused
> problems or not so far but I see a potential f
On Thu, Dec 4, 2014 at 9:14 AM, Harbs wrote:
> ...If you feel it should be changed anyway, I have no objections to that...
I havent checked if allowing vetoes for many things has caused
problems or not so far but I see a potential for creating blocking
problems, so fixing that now is probably a g
On 04/12/14 08:14, Harbs wrote:
I just readhttps://cwiki.apache.org/confluence/display/FLEX/Guidelines
>and I think allowing vetoes for most everything
Really?
I thought the only votes where vetoes are allowed are for voting in new
committers/PMC members/PMC Chair.
Code change is 'lazy' which
On Dec 4, 2014, at 10:05 AM, Bertrand Delacretaz wrote:
> I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
> and I think allowing vetoes for most everything
Really?
I thought the only votes where vetoes are allowed are for voting in new
committers/PMC members/PMC Chair.
On Thu, Dec 4, 2014 at 10:48 AM, Tom Chiverton wrote:
> ...I'm sure if we got
> to the point of voting on something, and there were a large fraction of -1
> (but more +1) we'd still take that as a signal to evaluate whatever it was
> more strongly...
That would be great, yes. And even a single -1
On Thu, Dec 4, 2014 at 9:24 AM, Erik de Bruin wrote:
> ...The only Consensus votes remaining in our guidelines (that I can find)
> are for the addition or removal of people in 'official' Apache
> positions (Committers and PMC members)
FWIW I am even suggesting that you guys drop this "consens
Reducing the types of votes available would make getting my head around
them easier, certainly.
I think the 'lazy consensus' we have listed on our Wiki also conflicts
with the Apache version because of the -1 veto, which should certainly
be corrected; we should just link to the Apache page there
> I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
> and I think allowing vetoes for most everything, as those guidelines
> do, is calling for trouble.
We recently voted to change the default vote type from Consensus to
Majority Approval.
The only Consensus votes remaining
Hi,
I just read https://cwiki.apache.org/confluence/display/FLEX/Guidelines
and I think allowing vetoes for most everything, as those guidelines
do, is calling for trouble.
The standard Apache voting process [1] specifies vetoes for commits only.
My recommendation would be to make those guidelin
44 matches
Mail list logo
