Hi internals,
it's been a great eight months now for PHP 5.4. We released 5.4.0 final
in february and since then we were able to deliver a new PHP version
every month (thanks to the hard work from stas).
As most people know we do not include patches in 5.4 that will break
backwards compatibility. Those patches are in the 5.5 branch and we
are also stockpiling some new features. We have implementations for
foreachlist, generators, hash_pbkdf2 and others are likely to get included
in the next weeks like the simplified password hashing API.
Following the release process RFC, I would like to start discussing the
beginning of the 5.5. series, that can include new features, do bc breaks
if necessary and overall provide a smooth move to a new series without
having the branches diverge for years and years again (like 5.4 and 5.3).
Last but not least, 5.3 is out since 2009 and it would be good to put
the series into a security fix only mode and give it an eol.
So I proposed to start off with 5.5 and focus on it, so we can get a
release going till Feb/March 2013.
As with every new release minor release (read minor as the Y in 5.Y.Z),
we choose a new RM. We had quite some confusion and debates around this
topic the last time, so I'll just go ahead and propose somebody right
away for the job.
I would like to go ahead and propose Julien Pauli as the RM for 5.5. He
is an active member of the PHP.net community, has deep knowledge of
the internals and the necessary backing from his company to be able to
dedicate the time needed to do the job. Knowing that things are kindof
rough at the start, I am willing to help out with intial releases,
reviews and settings things up until they can be handled by one person
(which is pretty much the state of 5.4 atm).
If you can think of a better candidate or want to step up, feel free to
do so.
Let's keep things simple here, stay on topic and debate if we want to
start with 5.5 and who can RM it.
- David
Let's keep things simple here, stay on topic and debate
if we want to start with 5.5 and who can RM it.
Hey,
sounds like a really good plan and apart from the probably most-often
named disadvantage, getting people to switch (hard enough to get minor
upgrades rolled out) I'm very much looking forward to this :)
Greetings,
Florian
Hi!
As most people know we do not include patches in 5.4 that will break
backwards compatibility.
We do not include them anywhere in any future 5.x release either.
That's clearly define in the RFC and we won't change that. Feedbacks
from users on that is clear and loud, best decision ever.
Those patches are in the 5.5 branch and we
are also stockpiling some new features.
There is o 5.5 branch, there is master. Master is the development
branch and as such can have such breakages. It does not mean that we
have these BC breaks in 5.5. 5.5 should be based on 5.4 with the
feature additions and improvements we want in, but definitively not
with BC breaks.
We have implementations for
foreachlist, generators, hash_pbkdf2 and others are likely to get included
in the next weeks like the simplified password hashing API.Following the release process RFC, I would like to start discussing the
beginning of the 5.5. series, that can include new features, do bc breaks
if necessary and overall provide a smooth move to a new series without
having the branches diverge for years and years again (like 5.4 and 5.3).
Last but not least, 5.3 is out since 2009 and it would be good to put
the series into a security fix only mode and give it an eol.
Yes, let start the 5.3 EOL discussion too and decide when it will
stop, or better said, end the discussion as we began it earlier this
year :)
As with every new release minor release (read minor as the Y in 5.Y.Z),
we choose a new RM. We had quite some confusion and debates around this
topic the last time, so I'll just go ahead and propose somebody right
away for the job.
Two persons, actually.
I would like to go ahead and propose Julien Pauli as the RM for 5.5.
Huge +1.
When we discussed that, you wanted to give up your role with 5.4 (one
is enough at this point) and be co RM for 5.5. Did you change your
mind?
Cheers,
Pierre
Hi!
As most people know we do not include patches in 5.4 that will break
backwards compatibility.We do not include them anywhere in any future 5.x release either.
That's clearly define in the RFC and we won't change that. Feedbacks
from users on that is clear and loud, best decision ever.
I agree. I missed the point that 5.5 should not include bc breaks either.
Those patches are in the 5.5 branch and we
are also stockpiling some new features.There is o 5.5 branch, there is master. Master is the development
branch and as such can have such breakages. It does not mean that we
have these BC breaks in 5.5. 5.5 should be based on 5.4 with the
feature additions and improvements we want in, but definitively not
with BC breaks.
We have implementations for
foreachlist, generators, hash_pbkdf2 and others are likely to get included
in the next weeks like the simplified password hashing API.As with every new release minor release (read minor as the Y in 5.Y.Z),
we choose a new RM. We had quite some confusion and debates around this
topic the last time, so I'll just go ahead and propose somebody right
away for the job.Two persons, actually.
I would like to go ahead and propose Julien Pauli as the RM for 5.5.
Huge +1.
When we discussed that, you wanted to give up your role with 5.4 (one
is enough at this point) and be co RM for 5.5. Did you change your
mind?
As some people are confused by what I mean with what I would do. I
can help with 5.5 and be the Co-RM again. The reason is simple, while
the main RM is bound to the series for 2-3 years, Lukas back then and
now I realize that after the first bumpy months it's a fairly straight
forward job (particularly thanks to the release process) and I am sure
Stas can manage 5.4 on it's own (and in case he is away for two weeks
i can still run the process). At that point I am bascially just doing
the announcements for 5.4.
Hi internals,
I would like to go ahead and propose Julien Pauli as the RM for 5.5. He
is an active member of the PHP.net community, has deep knowledge of
the internals and the necessary backing from his company to be able to
dedicate the time needed to do the job. Knowing that things are kindof
rough at the start, I am willing to help out with intial releases,
reviews and settings things up until they can be handled by one person
(which is pretty much the state of 5.4 atm).
A last bump on that. So nobody complained so far, I think Julien and
I can go ahead and start with 5.5 as soon as possible.
Hi internals,
I would like to go ahead and propose Julien Pauli as the RM for 5.5. He
is an active member of the PHP.net community, has deep knowledge of
the internals and the necessary backing from his company to be able to
dedicate the time needed to do the job. Knowing that things are kindof
rough at the start, I am willing to help out with intial releases,
reviews and settings things up until they can be handled by one person
(which is pretty much the state of 5.4 atm).A last bump on that. So nobody complained so far, I think Julien and
I can go ahead and start with 5.5 as soon as possible.
Hell yeah :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Roger captain :)
I'll soon be on IRC to check this out and get used to PHP build tools
and environment :)
Julien.P
Hi internals,
I would like to go ahead and propose Julien Pauli as the RM for 5.5. He
is an active member of the PHP.net community, has deep knowledge of
the internals and the necessary backing from his company to be able to
dedicate the time needed to do the job. Knowing that things are kindof
rough at the start, I am willing to help out with intial releases,
reviews and settings things up until they can be handled by one person
(which is pretty much the state of 5.4 atm).A last bump on that. So nobody complained so far, I think Julien and
I can go ahead and start with 5.5 as soon as possible.Hell yeah :)
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi internals,
I would like to go ahead and propose Julien Pauli as the RM for 5.5. He
is an active member of the PHP.net community, has deep knowledge of
the internals and the necessary backing from his company to be able to
dedicate the time needed to do the job. Knowing that things are kindof
rough at the start, I am willing to help out with intial releases,
reviews and settings things up until they can be handled by one person
(which is pretty much the state of 5.4 atm).A last bump on that. So nobody complained so far, I think Julien and
I can go ahead and start with 5.5 as soon as possible.
Somehow, I've expected a bigger discussion about the election of the RMs.
On a sidenote: it would be nice if we could have a wiki page/rfc about the
process of the election, as currently we don't have one.
Would be nice seeing what are the requirements, how are they
elected(voting, how long should the poll be open, etc.), if there is a
limit on the re-election, etc.
I think that both David and Julien will be nice RMs, but doing this
decision in this casual way somehow seems a little bit off for me.,
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Hi internals,
I would like to go ahead and propose Julien Pauli as the RM for 5.5. He
is an active member of the PHP.net community, has deep knowledge of
the internals and the necessary backing from his company to be able to
dedicate the time needed to do the job. Knowing that things are kindof
rough at the start, I am willing to help out with intial releases,
reviews and settings things up until they can be handled by one person
(which is pretty much the state of 5.4 atm).A last bump on that. So nobody complained so far, I think Julien and
I can go ahead and start with 5.5 as soon as possible.Somehow, I've expected a bigger discussion about the election of the RMs.
On a sidenote: it would be nice if we could have a wiki page/rfc about the
process of the election, as currently we don't have one.
Would be nice seeing what are the requirements, how are they
elected(voting, how long should the poll be open, etc.), if there is a
limit on the re-election, etc.
I think that both David and Julien will be nice RMs, but doing this
decision in this casual way somehow seems a little bit off for me.,
+1, we even have nothing or little info about RMs into the wiki. I
agree that must be taken care of.
Julien.P
hi Ferenc,
Somehow, I've expected a bigger discussion about the election of the RMs.
Right, but if only one team volunteers, there is no need of voting,
except if there were objections to one of the members, but there is
none :)
On a sidenote: it would be nice if we could have a wiki page/rfc about the
process of the election, as currently we don't have one.
yes, well, pretty much the same than any other RFCs, a list of RMs
pair instead of the usual RFC options (yes, no, or other).
Would be nice seeing what are the requirements, how are they
elected(voting, how long should the poll be open, etc.),
Durations and co are fixed by the voting RFC already.
if there is a
limit on the re-election, etc.
I think that both David and Julien will be nice RMs, but doing this
decision in this casual way somehow seems a little bit off for me.,
Idea is to have one experimented RM with a new one. In this case,
David and Julien. Once 5.5 is in the cruising mode, only Julien will
remain (like only Stas will remain pretty soon as well).
Feel free to create a page in the wiki for that.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi,
Let's keep things simple here, stay on topic and debate if we want to
start with 5.5 and who can RM it.
I wonder if we really need two RMs. This two-RM-thing was introduced
back when I was busy with different things at work, university,
live, ... when Lukas stepped in to do some of the administrative tasks.
Nowadays those administrative tasks are ruled way more in RFCs and the
role of the RM, in my opinion, is more a task overseeing things
(reviewing changes, reminding people about their "promises") etc. in the
end those are all things everybody should be doing. For the remaining
coordination though there should be a single person, who can judge on
implications, when there is doubt.
I'd therefore suggest that we go back to a single RM. This gives one
person to talk to, which eases communication a lot (even if the single
RM just delegates the issue back to some domain expert).
A single RM, of course, has the risk to "disappear" due to changes in
life or whatever but I don't think that's a major risk as the role might
transition. Such a transition might also be good when selecting a
successor - throw a successor on the prepared path after the .0 is done
instead of throwing them directly in the center of the field a short
time before a release where everybody tries to get his things in.
David, I think you're experienced enough to fill this role alone.
Thanks,
johannes
David, I think you're experienced enough to fill this role alone.
One benefit to having two RM's is that Julien is learning from DSP. If
there is a strong reason to have only one RM, then maybe we should consider
a RM/vice-RM kind of pairing.
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
David, I think you're experienced enough to fill this role alone.
One benefit to having two RM's is that Julien is learning from DSP. If
there is a strong reason to have only one RM, then maybe we should consider
a RM/vice-RM kind of pairing.
That's it, the idea has never been to have confusion, but help the new
RM at well ... RMing.
Getting used to tools and processes is not an easy task for the
begining of RMing :-P Whoever is the new RM that said.
Julien.P
Hi,
David, I think you're experienced enough to fill this role alone.
One benefit to having two RM's is that Julien is learning from DSP. If
there is a strong reason to have only one RM, then maybe we should consider
a RM/vice-RM kind of pairing.That's it, the idea has never been to have confusion, but help the new
RM at well ... RMing.
Getting used to tools and processes is not an easy task for the
begining of RMing :-P Whoever is the new RM that said.
There are very few special processes. In fact the only RM-specific
things are around packaging the tarballs up, while that's described in
an README. Besides that all processes affect everybody in the community
and everybody should be aware of it. The RM simply is the last instance
to identify/judge if things are unclear. the requirements for that are
a) knowing the code quite well b) knowing whom to ask for a given issue.
both things are good qualifications for any contributor.
In my mail I also suggested to "train" a successor later in the game.
Nowadays,thanks to all the RFCs and so on, the role of the RM is on the
one hand very limited and on the other hand requires maing clear
decisions. And well, two persons give two clear decisions or increase
workload for themselves (due to extra coordination) and everybody else
(for having two guys to follow)
I don't mind if an RM has an "assistant" or "apprentice" or such, but I
want a clear responsibility - I always describe the role as "the one who
takes the blame." All the good stuff comes from the contributors, the RM
is the one who in the end didn't catch the mistakes.
johannes
Am 17.09.2012 17:36, schrieb Johannes Schlüter:
There are very few special processes. In fact the only RM-specific
things are around packaging the tarballs up, while that's described in
an README.
Does this have to be manual process? Is there something in it that
cannot be described in a Makefile, build.xml, etc. instead?
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Am 17.09.2012 17:36, schrieb Johannes Schlüter:
There are very few special processes. In fact the only RM-specific
things are around packaging the tarballs up, while that's described in
an README.Does this have to be manual process? Is there something in it that
cannot be described in a Makefile, build.xml, etc. instead?
Even that would have to be triggered ;-)
And well, then there are tasks which can't be automated, like writing a
release announcement (human has to decide what's to be highlighted etc.)
but well, there automation there is the less we need two guys doing
that, the more you're confirming my point.
johannes
Am 17.09.2012 17:36, schrieb Johannes Schl?ter:
There are very few special processes. In fact the only RM-specific
things are around packaging the tarballs up, while that's described in
an README.Does this have to be manual process? Is there something in it that
cannot be described in a Makefile, build.xml, etc. instead?
Yes, merging NEWS, writing news entries, mails and generating Changelog-5
(the issue is related to NEWS). Most of the rest can be automated so once
a release hit .0 it's, as johannes pointed out, very straight forward
hi,
On Mon, Sep 17, 2012 at 5:36 PM, Johannes Schlüter
johannes@schlueters.de wrote:
There are very few special processes. In fact the only RM-specific
things are around packaging the tarballs up, while that's described in
an README. Besides that all processes affect everybody in the community
and everybody should be aware of it. The RM simply is the last instance
to identify/judge if things are unclear. the requirements for that are
a) knowing the code quite well b) knowing whom to ask for a given issue.
both things are good qualifications for any contributor.In my mail I also suggested to "train" a successor later in the game.
Nowadays,thanks to all the RFCs and so on, the role of the RM is on the
one hand very limited and on the other hand requires maing clear
decisions. And well, two persons give two clear decisions or increase
workload for themselves (due to extra coordination) and everybody else
(for having two guys to follow)
That's where you see it wrong. There is only one team to follow, not
two guys. The RMs have regular contacts, approve together important
changes (aka no one liner or similar), etc. They are also more keen to
get a better judgment than a single person (different views, etc.).
There is no extra work load, only benefits. Also seeing what happened
with the latest 5.3, I wonder if we should not have two again for 5.3
as well (kidding but.. ;-).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi
On Mon, Sep 17, 2012 at 4:44 PM, Johannes Schlüter
johannes@schlueters.de wrote:
I wonder if we really need two RMs. This two-RM-thing was introduced
back when I was busy with different things at work, university,
live, ... when Lukas stepped in to do some of the administrative tasks.
Well, I have a totally different view on that period, and the issues
were really not due to your activity at the university (or whatever
else). And yes, not alone because of the 5.3 experience, I am totally
convinced that we need a dual head RMs team.
David, I think you're experienced enough to fill this role alone.
That's the point. And Julien will get it while working with David and
the rest of the people involved in releases for the 1st months of 5.5.
Then Julien will do 5.5 alone, or David alone (if they change their
mind ;-).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org