Good evening,
This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21).
https://wiki.php.net/rfc/integer_semantics#vote
Thanks!
Andrea Faulds
http://ajf.me/
This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21).
A few people have asked why I voted no; the only reason is that
division by zero will return false and emit a warning. Integers can
be converted to floating point numbers and dividing by zero in IEEE
754 is defined as INF. I would rather leave behavior undefined by
voting no on this RFC than by defining it to a value which does not
make sense to me. The value false will get converted to zero in any
additional math, which is not the same as INF.
The rest of the RFC looks very good, and would vote yes to it if
division by zero was untouched or modified to use floating point
division by zero.
This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21).
A few people have asked why I voted no; the only reason is that
division by zero will returnfalseand emit a warning. Integers can
be converted to floating point numbers and dividing by zero in IEEE
754 is defined as INF. I would rather leave behavior undefined by
voting no on this RFC than by defining it to a value which does not
make sense to me. The value false will get converted to zero in any
additional math, which is not the same as INF.
The RFC does not touch division by zero. That was a suggestion for a future RFC.
I’ve now removed that section to avoid confusion.
Andrea Faulds
http://ajf.me/
Hi Andrea,
Shifts by negative number may make sense. (N << -1) => (N >> 1)
At least receiving "false" from shift is not very pleasant.
In the patch you use SIZEOF_LONG. It probably should be changed to
SIZEOF_ZEND_LONG.
Thanks. Dmitry.
This RFC has been put to a vote. It starts today (2014-09-14) and ends
in a week’s time (2014-09-21).A few people have asked why I voted no; the only reason is that
division by zero will returnfalseand emit a warning. Integers can
be converted to floating point numbers and dividing by zero in IEEE
754 is defined as INF. I would rather leave behavior undefined by
voting no on this RFC than by defining it to a value which does not
make sense to me. The value false will get converted to zero in any
additional math, which is not the same as INF.The RFC does not touch division by zero. That was a suggestion for a
future RFC.I’ve now removed that section to avoid confusion.
Andrea Faulds
http://ajf.me/
Shifts by negative number may make sense. (N << -1) => (N >> 1)
At least receiving "false" from shift is not very pleasant.
The problem is that changing from the current behaviour (undefined in C, but typically a shift by (PHP_INT_MAX - $bits)) to do what you’d expect (shift in the opposite direction) would be a silent BC break. I think it’s better to just stop it altogether and raise an E_WARNING, where it’s at least obvious something went wrong, than change this behaviour silently.
In the patch you use SIZEOF_LONG. It probably should be changed to
SIZEOF_ZEND_LONG.
Will fix, thanks for spotting that.
--
Andrea Faulds
http://ajf.me/
you already made silent break for N << 64 and N >> 64, but it may be
explained as more consistent behaviour.
I don't see a big difference with negative shifts.
The real thing that I don't like - is a "boolean" result. Warning is not a
big problem.
Thanks. Dmitry.
Shifts by negative number may make sense. (N << -1) => (N >> 1)
At least receiving "false" from shift is not very pleasant.The problem is that changing from the current behaviour (undefined in C,
but typically a shift by (PHP_INT_MAX - $bits)) to do what you’d expect
(shift in the opposite direction) would be a silent BC break. I think it’s
better to just stop it altogether and raise an E_WARNING, where it’s at
least obvious something went wrong, than change this behaviour silently.In the patch you use SIZEOF_LONG. It probably should be changed to
SIZEOF_ZEND_LONG.Will fix, thanks for spotting that.
--
Andrea Faulds
http://ajf.me/
you already made silent break for N << 64 and N >> 64, but it may be
explained as more consistent behaviour.
I don't see a big difference with negative shifts.The real thing that I don't like - is a "boolean" result. Warning is not a
big problem.
I'm inclined to agree with this. The warning makes sense as it's
almost certainly a userland bug, and if the expected old behaviour is
desired it can easily be modified in userland, but returning FALSE
doesn't make a huge amount of sense. This will almost certainly be
immediately cast to int(0) by the next operation - almost no-one is
going to actually check for a return value of FALSE - so it makes more
sense to just return 0 and avoid the implicit cast. This would also
produce possibly-unexpected results if a future operation was to
stringify the result, as FALSE would cast to the empty string.
I have voted in favour of the RFC as it stands as I believe that
overall the changes are positive, but ideally this particular case
would be addressed.
Thanks. Dmitry.
Shifts by negative number may make sense. (N << -1) => (N >> 1)
At least receiving "false" from shift is not very pleasant.The problem is that changing from the current behaviour (undefined in C,
but typically a shift by (PHP_INT_MAX - $bits)) to do what you’d expect
(shift in the opposite direction) would be a silent BC break. I think it’s
better to just stop it altogether and raise an E_WARNING, where it’s at
least obvious something went wrong, than change this behaviour silently.In the patch you use SIZEOF_LONG. It probably should be changed to
SIZEOF_ZEND_LONG.Will fix, thanks for spotting that.
--
Andrea Faulds
http://ajf.me/
you already made silent break for N << 64 and N >> 64, but it may be
explained as more consistent behaviour.
I don't see a big difference with negative shifts.The real thing that I don't like - is a "boolean" result. Warning is not a
big problem.I'm inclined to agree with this. The warning makes sense as it's
almost certainly a userland bug, and if the expected old behaviour is
desired it can easily be modified in userland, but returningFALSE
doesn't make a huge amount of sense. This will almost certainly be
immediately cast to int(0) by the next operation - almost no-one is
going to actually check for a return value ofFALSE- so it makes more
sense to just return 0 and avoid the implicit cast. This would also
produce possibly-unexpected results if a future operation was to
stringify the result, asFALSEwould cast to the empty string.I have voted in favour of the RFC as it stands as I believe that
overall the changes are positive, but ideally this particular case
would be addressed.
The choice of bool(false) was due to precedent. This is what we do for a division by zero. I agree that some other value would make more sense, but I couldn’t think of a better one, so I just stuck with the existing behaviour for div0.
Andrea Faulds
http://ajf.me/
Good evening,
This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21).
https://wiki.php.net/rfc/integer_semantics#vote
Thanks!
The vote has now closed. The result was 16:8 Yes:No, which meets the 2/3 majority and therefore the RFC is accepted. I’ll merge the patch soon.
I understand some people objected to (int)INF and (int)NAN resulting in zero. For that reason, I’m going to consider writing an RFC to make them error instead sometime soon.
Thanks!
--
Andrea Faulds
http://ajf.me/
Hey:
Good evening,
This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21).
https://wiki.php.net/rfc/integer_semantics#vote
Thanks!
The vote has now closed. The result was 16:8 Yes:No, which meets the 2/3 majority and therefore the RFC is accepted. I’ll merge the patch soon.
it should be closed tomorrow, not today.
I understand some people objected to (int)INF and (int)NAN resulting in zero. For that reason, I’m going to consider writing an RFC to make them error instead sometime soon.
Thanks!
--
Andrea Faulds
http://ajf.me/--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hey:
it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th and it's now 4am on the 21st. I don't see a problem.
Andrea Faulds
http://ajf.me/
Hey:
it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th and it's now 4am on the 21st. I don't see a problem.
the problem is, you only get 16:8 on today. and it's weekend.
that means your RFC is not very common acceptable. (I have strong
objection on it).
and it's weekend, so, it's better to wait one day more..
anyway, I see you already commit your patch... which is not very good.
thanks
--
Andrea Faulds
http://ajf.me/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi,
Hey:
it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th and
it's now 4am on the 21st. I don't see a problem.the problem is, you only get 16:8 on today. and it's weekend.
that means your RFC is not very common acceptable. (I have strong
objection on it).and it's weekend, so, it's better to wait one day more..
anyway, I see you already commit your patch... which is not very good.
I did not manage to vote while being on the road. But I am +1. So consider
it as, theoretically, 17:8.
However the nitpicking about votes periods, % and co is getting annoying. I
will see if we can clarify that. To use all possible ways to block or push
RFCs is getting counter productive and produce a bad experience.
Cheers,
Pierre
Hi,
Hey:
it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th and
it's now 4am on the 21st. I don't see a problem.the problem is, you only get 16:8 on today. and it's weekend.
that means your RFC is not very common acceptable. (I have strong
objection on it).and it's weekend, so, it's better to wait one day more..
anyway, I see you already commit your patch... which is not very good.
I did not manage to vote while being on the road. But I am +1. So consider
it as, theoretically, 17:8.
why you didn't?
there are lot's of people didn't vote. so how to count theirs vote?
(please if you have opinion.. then vote)
However the nitpicking about votes periods, % and co is getting annoying. I
will see if we can clarify that. To use all possible ways to block or push
RFCs is getting counter productive and produce a bad experience.
and nervemind. I respect the RFC process, even I don't like this RFC
thanks
Cheers,
Pierre
--
Xinchen Hui
@Laruence
http://www.laruence.com/
On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye pierre.php@gmail.com
wrote:Hi,
Hey:
it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th
and
it's now 4am on the 21st. I don't see a problem.the problem is, you only get 16:8 on today. and it's weekend.
that means your RFC is not very common acceptable. (I have strong
objection on it).and it's weekend, so, it's better to wait one day more..
anyway, I see you already commit your patch... which is not very good.
I did not manage to vote while being on the road. But I am +1. So
consider
it as, theoretically, 17:8.
why you didn't?there are lot's of people didn't vote. so how to count theirs vote?
(please if you have opinion.. then vote)
It is closed now.
However the nitpicking about votes periods, % and co is getting
annoying. I
will see if we can clarify that. To use all possible ways to block or
push
RFCs is getting counter productive and produce a bad experience.and nervemind. I respect the RFC process, even I don't like this RFC
:-)
thanks
Cheers,
Pierre--
Xinchen Hui
@Laruence
http://www.laruence.com/
On Sun, Sep 21, 2014 at 11:33 AM, Pierre Joye pierre.php@gmail.com
wrote:Hi,
Hey:
it should be closed tomorrow, not today.
It's the 21st in my timezone. I started the vote at 2am on the 14th
and
it's now 4am on the 21st. I don't see a problem.the problem is, you only get 16:8 on today. and it's weekend.
that means your RFC is not very common acceptable. (I have strong
objection on it).and it's weekend, so, it's better to wait one day more..
anyway, I see you already commit your patch... which is not very good.
I did not manage to vote while being on the road. But I am +1. So
consider
it as, theoretically, 17:8.
why you didn't?there are lot's of people didn't vote. so how to count theirs vote?
(please if you have opinion.. then vote)
It is closed now.
The vote is closed now, fact. That does not prevent further (hopefully
productive) discussion from happening, and it also doesn’t stipulate that
the RFC must be merged.
Closing the vote at the most convenient opportunity, when it suits the
author most, is not cool. Andrea has been pushing for a while to scrape
enough votes together to get this through, as a “prerequisite" for the
bigint RFC–which apparently would include these changes anyway, regardless
of the outcome of this vote– even asking “no” voters on multiple occasions
to rescind their votes. So. Not. Cool.
However the nitpicking about votes periods, % and co is getting
annoying. I
will see if we can clarify that. To use all possible ways to block or
push
RFCs is getting counter productive and produce a bad experience.and nervemind. I respect the RFC process, even I don't like this RFC
:-)
thanks
Cheers,
Pierre--
Xinchen Hui
@Laruence
http://www.laruence.com/
It is closed now.
The vote is closed now, fact. That does not prevent further (hopefully productive) discussion from happening, and it also doesn’t stipulate that the RFC must be merged.
The RFC is merged. I suppose you could revert the changes, though it’d be a significant hassle.
Closing the vote at the most convenient opportunity, when it suits the author most, is not cool.
I didn’t close it because the time suited me most. I made an honest mistake and closed it 22 or so hours early because I forgot I’d opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after merging the patch. This was definitely not intentional.
--
Andrea Faulds
http://ajf.me/
On 21 Sep 2014, at 22:49, Peter Cowburn <petercowburn@gmail.com
javascript:;> wrote:It is closed now.
The vote is closed now, fact. That does not prevent further (hopefully
productive) discussion from happening, and it also doesn’t stipulate that
the RFC must be merged.The RFC is merged. I suppose you could revert the changes, though it’d be
a significant hassle.
Immediately reverting a change is a knee-jerk reaction that should not take
place.
That said, this vote was closed early, whether deliberately or not, and
merged, which goes against everything we've been aiming for with the
RFC process.
Closing the vote at the most convenient opportunity, when it suits the
author most, is not cool.I didn’t close it because the time suited me most. I made an honest
mistake and closed it 22 or so hours early because I forgot I’d opened the
vote at ~23:00 and not ~02:00. Unfortunately, I realised my mistake after
merging the patch. This was definitely not intentional.
If you say so. Still, the asking of individuals to remove their votes so
that the tally is in you favour is inexcusable.
--
Andrea Faulds
http://ajf.me/
If you say so. Still, the asking of individuals to remove their votes so
that the tally is in you favour is inexcusable.
did I miss something? What is this "request to remove votes" thing?
--
Pierre
@pierrejoye | http://www.libgd.org
On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowburn@gmail.com
wrote:If you say so. Still, the asking of individuals to remove their votes so
that the tally is in you favour is inexcusable.did I miss something? What is this "request to remove votes" thing?
Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]
In summary, Andrea asked individuals, myself included, several times to
remove their “no” votes purely to cross the 2/3 majority threshold. That,
along with their timely concerns raised both on- and off-list about who can
vote, leads me to think… “shenanigans”. [6]
What’s done is done, the RFC passed and was merged… let’s move along to
getting stuff done.
--
Pierre@pierrejoye | http://www.libgd.org
[1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597
[2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500
[3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456
[4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542
[5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711
[6] http://dictionary.reference.com/browse/shenanigans
On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowburn@gmail.com
wrote:If you say so. Still, the asking of individuals to remove their votes so
that the tally is in you favour is inexcusable.did I miss something? What is this "request to remove votes" thing?
Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]
In summary, Andrea asked individuals, myself included, several times to
remove their “no” votes purely to cross the 2/3 majority threshold. That,
along with their timely concerns raised both on- and off-list about who can
vote, leads me to think… “shenanigans”. [6]
ask people to vote yes, close the vote immeditely once it reach the
2/3 requirement..
it's not cool, and it's not about RFC process... it's about manner...
thanks
What’s done is done, the RFC passed and was merged… let’s move along to
getting stuff done.--
Pierre@pierrejoye | http://www.libgd.org
[1] http://chat.stackoverflow.com/transcript/11?m=18895597#18895597
[2] http://chat.stackoverflow.com/transcript/11?m=18948500#18948500
[3] http://chat.stackoverflow.com/transcript/11?m=18986456#18986456
[4] http://chat.stackoverflow.com/transcript/11?m=18986542#18986542
[5] http://chat.stackoverflow.com/transcript/11?m=19003711#19003711
[6] http://dictionary.reference.com/browse/shenanigans
--
Xinchen Hui
@Laruence
http://www.laruence.com/
ask people to vote yes, close the vote immeditely once it reach the
2/3 requirement..it's not cool, and it's not about RFC process... it's about manner…
I didn’t close it because it reached the 2/3 requirement. I was lucky that one more person voted before I closed it. I made an honest mistake and closed it too early.
Andrea Faulds
http://ajf.me/
On Mon, Sep 22, 2014 at 11:02 AM, Peter Cowburn petercowburn@gmail.com
wrote:If you say so. Still, the asking of individuals to remove their
votes so that the tally is in you favour is inexcusable.did I miss something? What is this "request to remove votes" thing?
Pierre, it didn’t take place on-list. [1] [2] [3] [4] [5]
In summary, Andrea asked individuals, myself included, several times
to remove their “no” votes purely to cross the 2/3 majority threshold.
I would also like to point out that, just like a 8:8 vote is not a "50%
majority", 16:8 is technically also not a two thirds majority. The
RFC, like with many other important things is of course too vague on
this.
cheers,
Derick
I would also like to point out that, just like a 8:8 vote is not a "50%
majority", 16:8 is technically also not a two thirds majority. The
RFC, like with many other important things is of course too vague on
this.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1 majority.
A 16:8 vote is a 2/3 majority. 2/3 of people have voted in favour, with 1/3 against. It’s a very narrow one, but so far I’m yet to see anyone say it should be 2/3+1 and not plain 2/3.
--
Andrea Faulds
http://ajf.me/
I would also like to point out that, just like a 8:8 vote is not a
"50% majority", 16:8 is technically also not a two thirds
majority. The RFC, like with many other important things is of
course too vague on this.
The "+1" is only for 50% majorities.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
majority.A 16:8 vote is a 2/3 majority.
Yes, I think so, too.
--
Regards,
Mike
I would also like to point out that, just like a 8:8 vote is not a
"50% majority", 16:8 is technically also not a two thirds
majority. The RFC, like with many other important things is of
course too vague on this.The "+1" is only for 50% majorities.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
majority.A 16:8 vote is a 2/3 majority.
Yes, I think so, too.
I disagree, but the main point was something else.
The "voting RFC" should be more clear on this. I don't think it is now.
It's a pretty vague RFC in the first place, and leaves way too much
open for interpretation.
cheers,
Derick
I would also like to point out that, just like a 8:8 vote is not a
"50% majority", 16:8 is technically also not a two thirds
majority. The RFC, like with many other important things is of
course too vague on this.The "+1" is only for 50% majorities.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
majority.A 16:8 vote is a 2/3 majority.
Yes, I think so, too.
I disagree, but the main point was something else.
Right, but what would be 2/3 of 24 votes for you then?
The "voting RFC" should be more clear on this. I don't think it is now.
It's a pretty vague RFC in the first place, and leaves way too much
open for interpretation.
For? # of votes?
cheers,
Derick
I would also like to point out that, just like a 8:8 vote is not a
"50% majority", 16:8 is technically also not a two thirds
majority. The RFC, like with many other important things is of
course too vague on this.The "+1" is only for 50% majorities.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
majority.A 16:8 vote is a 2/3 majority.
Yes, I think so, too.
I disagree, but the main point was something else.
Right, but what would be 2/3 of 24 votes for you then?
The "voting RFC" should be more clear on this. I don't think it is now.
It's a pretty vague RFC in the first place, and leaves way too much
open for interpretation.For? # of votes?
I have actually been working with several other people trying to come up
with smarter rules for the way we work with RFCs. Undoubtably, confusion
about what constitutes a "language change" is a huge issue. To be
completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a
mature language; if we can't get 2/3 to agree on something it probably
isn't good for the whole of the PHP project.
I don't want to say anything else here, as technically this is thread
hijacking (sorry Andrea) but I am very interested in collaborating with
anyone who would like to try to improve the RFC process. Perhaps reply to
me off-list if you are also interested.
I don't want to say anything else here, as technically this is thread
hijacking (sorry Andrea) but I am very interested in collaborating with
anyone who would like to try to improve the RFC process. Perhaps reply to
me off-list if you are also interested.
This is already a bad start to make this process more open or clear.
I don't want to say anything else here, as technically this is thread
hijacking (sorry Andrea) but I am very interested in collaborating with
anyone who would like to try to improve the RFC process. Perhaps reply to
me off-list if you are also interested.This is already a bad start to make this process more open or clear.
No, you simply failed to understand it. Collaboration in a smaller group
first, then open it up later. This catches a significant number of issues
before hitting the list, making the time on-list more valuable. I wish
every RFC was conducted in this fashion.
Hi,
Just a side remark: from an external point of view, it seems like you need
an application to handle the RFCs. An application with a strict business
logic, which leaves no ambiguity as to when and how an RFC should be valid.
The "what" is more ambiguous however, and I'm not sure as to how it should
be handled.
Regards,
Florian Margaine
I would also like to point out that, just like a 8:8 vote is not a
"50% majority", 16:8 is technically also not a two thirds
majority. The RFC, like with many other important things is of
course too vague on this.The "+1" is only for 50% majorities.
An 8:8 vote is not a majority, no, but a 9:8 would be a 50%+1
majority.A 16:8 vote is a 2/3 majority.
Yes, I think so, too.
I disagree, but the main point was something else.
Right, but what would be 2/3 of 24 votes for you then?
The "voting RFC" should be more clear on this. I don't think it is now.
It's a pretty vague RFC in the first place, and leaves way too much
open for interpretation.For? # of votes?
I have actually been working with several other people trying to come up
with smarter rules for the way we work with RFCs. Undoubtably, confusion
about what constitutes a "language change" is a huge issue. To be
completely honest, I would prefer that we require 2/3 on all RFCs. PHP is a
mature language; if we can't get 2/3 to agree on something it probably
isn't good for the whole of the PHP project.I don't want to say anything else here, as technically this is thread
hijacking (sorry Andrea) but I am very interested in collaborating with
anyone who would like to try to improve the RFC process. Perhaps reply to
me off-list if you are also interested.
WTF is going on here? Looks like the vote was closed nearly 24 hours
early on a weekend. While the latter is not nice, closing early is a
no-go. So what are we going to do? Reopen the vote for another day or
completely restart it?
--
Regards,
Mike
WTF is going on here? Looks like the vote was closed nearly 24 hours
early on a weekend. While the latter is not nice, closing early is a
no-go. So what are we going to do? Reopen the vote for another day or
completely restart it?
This is getting really annoying. 2nd or 3rd time it happens, between
people changing contents during votes, closing too early, too late,
asking to change votes, etc.
As we can't fix the lobbying part of it we can fix the time, content
and periods issue. I will drop a mail later today to propose a
solution, avoiding this.
--
Pierre
@pierrejoye | http://www.libgd.org
This is getting really annoying. 2nd or 3rd time it happens, between
people changing contents during votes, closing too early, too late,
asking to change votes, etc.
At a very least a vote should not end until at least 7 days after the
last change to the RFC being voted on? But 7 days STILL seems too short
when like yourself Pierre, people can be out on the road for a week?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
WTF is going on here? Looks like the vote was closed nearly 24 hours
early on a weekend. While the latter is not nice, closing early is a
no-go. So what are we going to do? Reopen the vote for another day or
completely restart it?
If we’re going to reopen or restart, I’d prefer to completely restart it than to just reopen it. A clean slate.
Andrea Faulds
http://ajf.me/
If we’re going to reopen or restart, I’d prefer to completely restart it than to just reopen it. A clean slate.
Most of the issues I saw raised were related to one half of the RFC,
the shifts or the casts, perhaps you'd make better headway splitting
it in two.
Hi!
I didn’t close it because the time suited me most. I made an honest
mistake and closed it 22 or so hours early because I forgot I’d
opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised
my mistake after merging the patch. This was definitely not
intentional.
That's why we should not rush to merge changes on a vote when there are
significant objections. There's nothing that mandated this change to be
merged immediately after the voting closing, as far as I can see. Yes,
we do not want to make the process endless, but it's better to wait just
a bit and ensure everybody is satisfied or at least reasonably listened
to. Begging people off-list to retract the votes and then close it
earlier on a very marginal result definitely looks like gaming the
system, even if the intent was not to do that. But the intent is only
known to one person, and the actions can be seen by all, so I think it's
better to take extra care here. We want the voting to be means of
enhancing the consensus, not something that would leave people losing
the confidence in the whole process.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
On Mon, Sep 22, 2014 at 10:19 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:
Hi!
I didn’t close it because the time suited me most. I made an honest
mistake and closed it 22 or so hours early because I forgot I’d
opened the vote at ~23:00 and not ~02:00. Unfortunately, I realised
my mistake after merging the patch. This was definitely not
intentional.That's why we should not rush to merge changes on a vote when there are
significant objections. There's nothing that mandated this change to be
merged immediately after the voting closing, as far as I can see. Yes,
we do not want to make the process endless, but it's better to wait just
a bit and ensure everybody is satisfied or at least reasonably listened
to. Begging people off-list to retract the votes and then close it
earlier on a very marginal result definitely looks like gaming the
system, even if the intent was not to do that. But the intent is only
known to one person, and the actions can be seen by all, so I think it's
better to take extra care here. We want the voting to be means of
enhancing the consensus, not something that would leave people losing
the confidence in the whole process.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/--
yeah, and when there is like 12 minutes between the last required vote
casted and the vote being casted(almost a day earlier), it is easy to jump
to conclusions.
but putting that aside, what do we do now?
Personally I agree that it is a valid concern that some people could have
missed the voting period because of this: We already discussed recently
that even a week is a bit short (anybody can have a week of vacation etc.)
but that is the minimum mandated by the voting rfc, and seeing how close
the vote was, I think it would be a good idea to extend the voting.
What do you think?
ps: I would prefer not reverting the change to save some work/history
obfuscation in case if the result stays.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
yeah, and when there is like 12 minutes between the last required vote casted and the vote being casted(almost a day earlier), it is easy to jump to conclusions.
The vote closing soon after the last vote was not a coincidence, but it’s the other way round from what you might think. That vote was deliberately made by them just before it was going to close (they asked me when I was going to close it), because they didn’t want it to fail by one vote. Had I not got that vote I’d still have closed it when I did, and it would have failed.
but putting that aside, what do we do now?
Personally I agree that it is a valid concern that some people could have missed the voting period because of this: We already discussed recently that even a week is a bit short (anybody can have a week of vacation etc.) but that is the minimum mandated by the voting rfc, and seeing how close the vote was, I think it would be a good idea to extend the voting.
What do you think?ps: I would prefer not reverting the change to save some work/history obfuscation in case if the result stays.
If we’re re-opening things, let’s just hold the vote again, rather than extending the existing vote.
Andrea Faulds
http://ajf.me/