Hi Alex,
On Mon, Dec 8, 2014 at 5:47 PM, Alex Harui wrote:
> ...My takeaway is that we can vote +1 without checking everything each time...
Definitely, OTOH it's good for voters to briefly indicate what they
checked (signatures, build on platform X, etc.) along with their votes
- also so that o
Hi Bertrand,
Again, thanks for taking the time to follow all of these lengthy threads.
I just want to makes sure I understand one point (in-line below):
On 12/8/14, 3:02 AM, "Bertrand Delacretaz" wrote:
>Git or svn diffs will show how much changed between that new release
>and the one that fail
Hi,
I agree that the key thing here is that your releases have to be
approved according to [0], from the ASF's point of view that's all.
This means that before you publish the release artifacts the
apache.org archive of this list needs to contain a documented trace
that shows that you indeed got
Would you guys quit arguing? This place sounds like a kindergarten. (and yes,
I’m sometimes at fault on that count as well)
Simply stated: What Justin calls "new votes" is what we call "carried votes".
Everyone agrees on what a voter can do, the only question is what to call it.
Semantics is NO
> A clarification please. Are you also saying that this should also apply in
> all cases even when there have been code changes?
The way a person votes and how they came to decide on that vote is
their business, and their business only. There is no super-authority
that gets to decides which votes
arried or not (the voter should be trusted that he understand what he
does asking for his vote to be carried), can you tell me what I'm missing ?
Thanks,
Frédéric THOMAS
> Subject: Re: Carried RC Votes
> From: jus...@classsoftware.com
> Date: Mon, 8 Dec 2014 00:32:32 +1100
> To
HI,
> Do you mean the RM is more qualified than other voting people for what is
> regarding legal issues or has more responsibilities on legal as RM ?
The RM has more at risk as they are responsible for the release. If for some
reason there was a issue with a release and it was determined that
t; Subject: Re: Carried RC Votes
> From: jus...@classsoftware.com
> Date: Sun, 7 Dec 2014 23:31:41 +1100
> To: dev@flex.apache.org
>
> Hi,
>
> > A vote is a personal thing. Everyone is responsible for their own vote.
>
> As long as it complies with this:
> htt
Hi,
> A vote is a personal thing. Everyone is responsible for their own vote.
As long as it complies with this:
http://www.apache.org/dev/release.html#approving-a-release
> If the caster of a vote wishes to 'carry' that vote to a new RC, that
> means the vote should apply - without reservation -
Hi,
> I doubt if any voter checked all 300 samples,
I actually did for several RCs, but I didn't expect that of everyone who voted.
Any issues will be found, reported and we can fix in the next release.
Justin
A vote is a personal thing. Everyone is responsible for their own
vote. A vote must implicitly be taken to represent the best effort and
intentions of the caster. It follows that a vote should not be
questioned and is not up for discussion. That would discredit the
caster, which does not compute in
Hi,
> What in your mind is the difference between requesting to carry your vote and
> voting +1 (again)?
Requesting your previous vote is carried on may or may not mean you've checked
changes from the previous RC as described in the VOTE email (and if not IMO
there may be some doubt that it's
Hi Justin,
You only answered half my question. Sorry for asking again, but I’m really
trying to clarify if there’s even a difference of opinion here.
What in your mind is the difference between requesting to carry your vote and
voting +1 (again)?
Thanks,
Harbs
On Dec 7, 2014, at 12:58 AM, Jus
I would want Rich and/or Bertrand to confirm that you can in fact vote +1
without checking sigs and running the build and doing some sort of test,
but I would be surprised if anyone felt that you had to run the same tests
on RCN that you ran on RCN-1 if no code changed. On TDF, I doubt if any
vote
Hi,
> If the guidelines are clear, where does the need for RM's discretion arise?
The term non code change could be open to interpretation (and I recall has
been) so I'd prefer if that was left in. For instance is changing an xml config
file, a html file, or a build script considered a code cha
HI,
> Do I understand your position correctly? (i.e. you believe carried votes do
> not indicate that the voter is aware of the changes and affirms their vote
> still applies, and you believe one can (re)vote on a new RC without checking
> all artifacts)
You would only need to check what has c
Before we discuss what the guidelines say, I think we need to get our
definitions in sync.
Two really simple questions:
1) When someone asks to have their vote carried over, are they stating that
they know their previous vote is still valid? Yes or no?
2) When someone votes +1 on RC #1 and then
On Dec 6, 2014 2:04 PM, "Justin Mclean" wrote:
>
> Hi,
>
> > When voting on release candidates the release manager at their
discretion
> > can carry over votes from the previous release candidate if there are
*non-code
> > related* changes between release candidates.
>
> I'd suggest going one step
Hi Justin,
It seems to me that the vote might just be the result of different
interpretations of carrying votes and we all agree on procedure but are using
different terminology.
Do I understand your position correctly? (i.e. you believe carried votes do not
indicate that the voter is aware of
Hi,
> When voting on release candidates the release manager at their discretion
> can carry over votes from the previous release candidate if there are
> *non-code
> related* changes between release candidates.
I'd suggest going one step further:
When voting on release candidates the release ma
On Sat, Dec 6, 2014 at 12:32 PM, Harbs wrote:
> If we’re wrong on the second point, then I think the entire discussion of
> carrying votes became moot, and we’ve spent an awful lot of time and energy
> on a non-issue.
>
> We can simply state that to vote on a new RC one either needs to recheck
>
If we’re wrong on the second point, then I think the entire discussion of
carrying votes became moot, and we’ve spent an awful lot of time and energy on
a non-issue.
We can simply state that to vote on a new RC one either needs to recheck all
artifacts of the RC or be confident that their origi
Me too, but something Bertrand said about typing +1 is quicker than typing
carryover made me wonder if we are correct. I'm hoping when Bertrand catches up
on these threads he'll see my question to him about this and clarify.
Sent via the PANTECH Discover, an AT&T 4G LTE smartphone.
Erik de Bruin
I understood the issue the same way.
EdB
On Saturday, December 6, 2014, Harbs wrote:
> I don’t want to prolong discussion, but I think there’s one point which
> needs to be clarified:
>
> Discussion in the VOTE thread made me realize that there might be a
> differing of understanding in what
24 matches
Mail list logo
