Zeev Suraski wrote:
> I don't get it. So if it was two weeks ago, a second before I said
> "4.0.5RC1 is out" it was ok, and now it isn't?
yes, IMHO that's it
> It doesn't make any sense.
> [...]
> New modules do not significantly increase the chances of messing up the
> release. Furthermore, if they do mess up the release, it's trivial to find
> that out. Nothing of what was said on php-dev/php-qa in this thread
> contradicted it (it doesn't mean that the build process is not important or
> anything; it does mean that it's trivial to determine whether it got
> messed up or not by a new module).
i'm not really sure about the side effects this could have,
and i definetly do not want to even think about it in a RC stage
IMHO experimental stuff shouldn't be in a release version at all,
but thats a different story
> Because of the clear gain vs.
> negligible loss, when Ben approached us and asked whether it's ok to put it
> in 4.0.5, knowing that there's another RC coming up in a couple of hours -
> we said that it's fine.
maybe this is the real point here: who was 'we'?
to me this appeared totally out of the blue, when searching my personal
and
the public archives i see Bens message on 15th, his checkin on 19th and
the merge to 4.0.5 on 20th with 'MFH' being the only comment on it
if the arguments for including it had been given _before_ doing so, or
maybe
even in parallel to the mearge from head, there might have been far less
contradiction here
> If it's going to take changing RELEASE_PROCESS to
> 'allow' this to keep things quiet, then we should do it.
s/do/talk about and do/ ?
> We shouldn't consider RELEASE_PROCESS as the bible,
with the release intervals of the bible spanning milleniums
we definetly shouldn't
> but as guidelines to work by and improve on as we gather experience.
reading Saschas reaction on this i assume this wasn't even announced/
discussed on group@...?
so this all sounds like 'guidelines may be ignored if they don't fit
important
peoples needs or thougts'
i do _not_ say or believe this was your intention (or Andis in the first
place
when he did the MFH)
but chances are that others might, and that gives it a bad taste IMHO
i guess i personaly would have said 'go for it' if i had seen an
annoncement
like 'we are going to add this ... we don't think it will break anything
non-obvious,
... and we consider it to be an important feature ... even if it might
be not
stable
yet for itself ... does anybody disagree?'
but this silent redefinition of the rules or guidelines or however you
like to
call it was, hm, lets say 'rather suboptimal'
hartmut
(beeing accused for trying to break a release last time for merging in
last
minute fixes for a function that was definetly broken and to a module
that
was clearly marked as EXPERIMENTAL (which fastcgi isn't, just for the
records))
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
