On Tue, Nov 23, 2010 at 3:58 PM, Derick Rethans <der...@php.net> wrote:

> On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
>
> > On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans <der...@php.net> wrote:
> >
> > > On Tue, 23 Nov 2010, Ferenc Kovacs wrote:
> > >
> > > > > All the rest you write in the RFC is basically already as we do it.
> > > >
> > > > yeah, maybe, but they aren't written down, accepted and well-known
> > > > rules, so you can forgot/misunderstand/bend them. :/
> > >
> > > And I don't think that is a bad thing. It's good to be able to be
> > > flexible.
> > >
> > Its good for you, but its bad for the people, who expect you to follow
> the
> > rules, you know, the vendors, developers, etc.
>
> Well, vendors don't follow rules in the first place.


you are sure that there aren't any vendor out there that don't following
your rules, which you think it better if it isn't documented or followed?


> They just add
> random patches anyway.


usually they more lazy, than the original developers, so I think they don't
add random shit just for fun.


> Developers are pretty much aware what a bug fix,
> security bug fix and development tree means.


as long as you and Zeev can't agree on what is the trunk (either be that a
development/experience branch, or the next stable version), then I think
they aren't aware.


> With an annoucement (which
> should really be a regular thing, sortof) of a new minor release, isn't
> it clear?


sorry, I lost you here. what is clear? that you want to release the current
trunk? thats crystal clear.
What it's not clear to me, that who decided when that you will be the
current RM, and that the current trunk is ready for an alpha release.
what is an alpha release? when did we started releasing
and announcing alphas, who decided that? can we add new features after the
alpha? or can we remove something if the feedback is bad about some change?
so this is what I'm talking about, lack of


> In case you say no, don't write an RFC that requires really
> strict following, but instead write guidelines that match current
> practise.
>
>
from my POV, I don't mind, if you guys decide that the current process is
the best, and create a wiki for that, but please decide on that, write it
down, and at least try to stick with it, if it works.

thats the point.

Tyrael

Reply via email to