On 2011-06-06, Chad Fulton wrote:
> So, I would advocate a "white list" of core devs for formal voting (of
> which, for example, I would not be a member). I think this mailing
> list has grown sufficiently that "public opinion" can be gauged from
> here: everyone can write their opinion without gi
On Mon, Jun 6, 2011 at 12:27 PM, dukeofgaming wrote:
>
> I have a little proposition here.
>
> I'm not —at least currently— known for any app or framework, but I'd like my
> voice to count, that is, if and only if the rest of the community thinks I
> make sane arguments that are worth considering.
On Sun, Jun 5, 2011 at 5:20 PM, Pierre Joye wrote:
>
>
> I'd to go with a 60% for language syntax, 50+1 for new exts or sapis.
> Other question is who can vote. For one, I like to have external
> people being able to vote, like frameworks/apps lead developers as
> well as @php.net in general (docs
On 2011-06-05, Zeev Suraski wrote:
> I'm fine if the entire 'Feature selection and development' part goes
> out of the RFC, but if there's any reference to how features are
> determined, we'd better get it right.
>
> Making changes once we've approved this RFC is going to be much
> tougher. This
> -Original Message-
> From: Pierre Joye [mailto:pierre@gmail.com]
> Sent: Monday, June 06, 2011 1:46 AM
> To: Zeev Suraski
> Cc: PHP Internals
> Subject: Re: Voting Process (was: [PHP-DEV] Re: Voting does not belong on
> the wiki! (Was: [PHP-DEV] 5.4 moving forward))
>
> In any case
Am 05.06.2011 22:05, schrieb Zeev Suraski:
> - There wasn't sufficient time, or nearly any time at all - between when
> Brian pulled it off the attic, and when a vote was called. If my proposal is
> accepted, there'll have to be at least two weeks between when a clearly
> marked [RFC] email hit
On Mon, Jun 6, 2011 at 1:16 AM, Stas Malyshev wrote:
>> The way I see it, we can't employ the voting part of this RFC unless
>> we can agree on rules on how this voting works; It's fine that we
>> don't decide exactly how we're going to do it. But then, it means
>> that we don't get to do it un
Hi!
The way I see it, we can't employ the voting part of this RFC unless
we can agree on rules on how this voting works; It's fine that we
don't decide exactly how we're going to do it. But then, it means
that we don't get to do it until we do decide.
Well, we'd have to vote somehow, e.g. on
take #4..
Hmmm, not sure I like the comparison (with Egypt).
> Major parts in the process weren't executed properly (I've spelled them out
> so I won't repeat them).
> It's quite possible that if they were executed properly, we'd have different
> results. Perhaps not, maybe even probably
[resending as the list appears to reject bit.ly URLs]
> As I agree on everything you wrote here, I don't feel like we need to redo it.
> The votes result is pretty clear, despite 2-3 people not willing to
> vote for whatever reasons:
>
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
Take a
> Currently the "Feature selection and development" basically says "we'd have
> a public vote on features". It doesn't specify how exactly is the process for
> a
> vote, and while again I think your proposal is good, I don't see why it has
> to be
> part of this RFC - e.g., if we agree that we ha
hi Zeev,
On Sun, Jun 5, 2011 at 10:05 PM, Zeev Suraski wrote:
> Pierre,
>
> I'm happy that we agree pretty much completely about the clarifications &
> updates needed for the RFC.
Same here :)
> I do however want to point out that the problematic way the short array
> syntax RFC was executed
On Sun, Jun 5, 2011 at 10:55 PM, Zeev Suraski wrote:
> I'm fine if the entire 'Feature selection and development' part goes out of
> the RFC, but if there's any reference to how features are determined, we'd
> better get it right.
Getting it totally out makes little sense as it brings us to the
Hi!
Honestly there are other parts about the voting process that are much
hotter potatoes than the points I brought up - such as who gets to
vote, is 50%+1 enough or do we need stronger majorities for
substantial language changes (67%/75%), can someone who failed
passing an RFC just put it up fo
I'm fine if the entire 'Feature selection and development' part goes out of the
RFC, but if there's any reference to how features are determined, we'd better
get it right.
Making changes once we've approved this RFC is going to be much tougher. This
is big stuff - it's no coincidence we didn't
Hi!
I'd still like to hear from others what they think about my proposal.
I'd like to update the Release Process RFC with these suggestions if
people like them.
I think these voting process additions totally make sense. But I am not
sure it makes sense to put everything in one release RFC. Th
For those of you who lost these proposals in the flood of RFC related emails of
recent days, here they are again:
---
First, we need to make sure that the RFC is properly evaluated by the members
of internals@, and that there's enough time for the RFC to be discussed here on
the list. As Phil
Pierre,
I'm happy that we agree pretty much completely about the clarifications &
updates needed for the RFC.
I do however want to point out that the problematic way the short array syntax
RFC was executed was the key reason that made me feel these updates were in
fact necessary - I don't thin
18 matches
Mail list logo
