Hi,
so, 5.3.1 out just a few weeks but due to the merge-based process and
some delays in there the changelog for 5.3 is already quite long and so
I'd like to restart the release process there soon.
My current plan has one RC this week, one more before Christmas, maybe
Tue 22nd, then a Christmas break, a RC early/mid January and release
late January. I don't think we could be faster but having some RC before
Christmas might get some people to test it on their new PCs they get,
people who won't test otherwise, while on the other side I don't expect
too much actual work being done during that time.
Given the discussions and ongoing refactoring work I would keep the FPM
SAPI out of 5.3.2 but aim for integration with 5.3.3. (Tony / Michael)
As a process: In general I think the release branch approach is a good
one while we had some trouble as there doesn't seem to be any software
to really manage release branches, but the wiki evolved to a good enough
merge tracker[1] imo. (The second problem with this approach was some
personal distraction I had)
Any comments?
johannes
Johannes,
While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch.
Hi,
so, 5.3.1 out just a few weeks but due to the merge-based process and
some delays in there the changelog for 5.3 is already quite long and so
I'd like to restart the release process there soon.My current plan has one RC this week, one more before Christmas, maybe
Tue 22nd, then a Christmas break, a RC early/mid January and release
late January. I don't think we could be faster but having some RC before
Christmas might get some people to test it on their new PCs they get,
people who won't test otherwise, while on the other side I don't expect
too much actual work being done during that time.Given the discussions and ongoing refactoring work I would keep the FPM
SAPI out of 5.3.2 but aim for integration with 5.3.3. (Tony / Michael)As a process: In general I think the release branch approach is a good
one while we had some trouble as there doesn't seem to be any software
to really manage release branches, but the wiki evolved to a good enough
merge tracker[1] imo. (The second problem with this approach was some
personal distraction I had)Any comments?
johannes
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Johannes,
While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch.
It was actually the exact opposite. We did not miss patches once we
were synced. The way we tracked the patches also let us actually
define what must go in and what not, avoiding the classical last
minute bad patches. The key to success is to do not let go months
between a commit and its merge to the release branch, which was a real
pain when we began 5.3.1.
Cheers,
Pierre
Pierre,
Actually patches were indeed missed, in fact we almost missed a security fix. As far as the wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't.
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Johannes,
While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch.
It was actually the exact opposite. We did not miss patches once we
were synced. The way we tracked the patches also let us actually
define what must go in and what not, avoiding the classical last
minute bad patches. The key to success is to do not let go months
between a commit and its merge to the release branch, which was a real
pain when we began 5.3.1.Cheers,
Pierre
Ilia,
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Pierre,
Actually patches were indeed missed, in fact we almost missed a security fix.
Which? We did review all 5.3 commits before going final.
As far as the wiki goes, most people don't even know it exists
If a PHP core developer does not know about it, then we have a serious problem.
, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't.
We can add a reason for the rejection (new features and non critical
patches have been rejected when we were in the RC phase, obviously :)
, but that does not mean the system is bad.
Cheers,
Pierre
As far as the wiki goes, most people don't even know it exists
If a PHP core developer does not know about it, then we have a serious problem.
I think it was mentioned on this list sufficiently often, but then again it came along fairly ad hoc. However I do agree that the wiki is not the right place for this in the long run. Like I said, I believe the bug tracker is the place for this by adding milestone support. This would also be the natural place to note why a patch is not merged for example.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Ilia,
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Pierre,
Actually patches were indeed missed, in fact we almost missed a security fix.
Which? We did review all 5.3 commits before going final.
The max # of file uploads was almost missed.
As far as the wiki goes, most people don't even know it exists
If a PHP core developer does not know about it, then we have a serious problem.
There are at least 4 people I spoke with that didn't know about it, I would say there are probably more.
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Ilia,
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Pierre,
Actually patches were indeed missed, in fact we almost missed a security fix.
Which? We did review all 5.3 commits before going final.
The max # of file uploads was almost missed.
It was not, and we did not forget it because of the automatic TODOs in
the wiki (it shows all commits in a list with their states,
http://wiki.php.net/todo/php531/log) :-).
There are at least 4 people I spoke with that didn't know about it, I would say there are probably more.
If one does not want to know something, then there is no way for us to
make him cluefull. The wiki has been mentioned hundred of times in
this list, but yes, one has to actually read the mails to get a clue
:)
Cheers,
Pierre
Which? We did review all 5.3 commits before going final.
The max # of file uploads was almost missed.
It was not, and we did not forget it because of the automatic TODOs in
the wiki (it shows all commits in a list with their states,
http://wiki.php.net/todo/php531/log) :-).
BS, I reminded Johannes about that patch right before the final RC, because it was still not merged.
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Which? We did review all 5.3 commits before going final.
The max # of file uploads was almost missed.
It was not, and we did not forget it because of the automatic TODOs in
the wiki (it shows all commits in a list with their states,
http://wiki.php.net/todo/php531/log) :-).BS, I reminded Johannes about that patch right before the final RC, because it was still not merged.
I think you should reconsider the way you see the whole thing. I did
remind Johannes as well while reviewing the commits. That's nice that
you did it as well as it just shows that the system worked, double
safety.
Now, about the way we do releases. Everyone agrees that is a mess, no
real plan or ability to define a clear roadmap. 5.3.1 has shown that
there is a way to solve that problem without influencing the day to
day job of the other core developers while making the release process
safer (no last minute breakage due to wild commits for example). There
is stilll a lot to do to make this process better and friendly but we
are on the right track.
Cheers,
Pierre
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Which? We did review all 5.3 commits before going final.
The max # of file uploads was almost missed.
It was not, and we did not forget it because of the automatic TODOs in
the wiki (it shows all commits in a list with their states,
http://wiki.php.net/todo/php531/log) :-).BS, I reminded Johannes about that patch right before the final RC, because it was still not merged.
I think you should reconsider the way you see the whole thing. I did
remind Johannes as well while reviewing the commits. That's nice that
you did it as well as it just shows that the system worked, double
safety.
If anything it shows the "system" had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of "no" and "?" is rather alarming, especially when there is no indicator as to why.
Additionally, would be possible to get some clarity as to who is actually is the RM for the 5.3.X tree, first it was Johannes, then Johannes and Lukas, now you seem to be playing a big role in it. Can I (we) get some clarity around that.
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
If anything it shows the "system" had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of "no" and "?" is rather alarming, especially when there is no indicator as to why.
Wait, and now developers do not read NEWS either? Oh my... it is worst
that I initially thought :)
Additionally, would be possible to get some clarity as to who is actually is the RM for the 5.3.X tree, first it was Johannes, then Johannes and Lukas, now you seem to be playing a big role in it. Can I (we) get some clarity around that.
Given that I work full time on PHP itself (or closely related
projects, and not only for the windows part of them), I give a hand to
Johannes to keep 5.3 releases on track, merges, etc. I don't think
there is such a need of a clarification or do you consider that having
people helping other developers or RM cannot happen without an
official statement on the mailing list ? </joking> :)
Cheers,
Pierre
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
If anything it shows the "system" had failed and aside from yourself and Johannes most developers have no idea what is and isn't part of the release. More over there is a whole pile patches that were not merged with no indication as to why... The amount of "no" and "?" is rather alarming, especially when there is no indicator as to why.
Wait, and now developers do not read NEWS either? Oh my... it is worst
that I initially thought :)
The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them.
As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-).
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them.
As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-).
Ok, so what you are arguing about is that you don't know why something
was not merged. That's something we like to improve but it has nothing
to do with the extra branch, absolutely nothing.
Cheers,
Pierre
Pierre,
It has everything to do with the separate branch. Our current approach, (as flawed as it maybe) ensures patches are not missed, since there is no separate branch, so patches go into the release tree. With the new approach if something is not merged it is not part of the release. This also makes it confusing for the users, since the dev fixing the bug indicates on the bug tracker the issue was resolved, and will be part of the next release. And then the next release comes out and the bug/issue is still there...
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them.
As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-).Ok, so what you are arguing about is that you don't know why something
was not merged. That's something we like to improve but it has nothing
to do with the extra branch, absolutely nothing.Cheers,
Pierre
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Pierre,
It has everything to do with the separate branch. Our current approach, (as flawed as it maybe) ensures patches are not missed, since there is no separate branch, so patches go into the release tree. With the new approach if something is not merged it is not part of the release. This also makes it confusing for the users, since the dev fixing the bug indicates on the bug tracker the issue was resolved, and will be part of the next release. And then the next release comes out and the bug/issue is still there...
Ok, so we are running in circle.
We agreed on that:
- we need to add a field to explain why a patch was not merged
- a real bug tracker
- with roadmap
- allow to set a bug as part of a given release roadmap, like when a
patch is commited to the dev branches, it can be set to "5.3.2" so the
RM can appove merge it - be sure that the merge commits are shown in the bug reports as well
However, given that:
- we did NOT miss any patches in 5.3.1
- the process was open, mails have been sent to the list, etc.
- the deadlines were respected, 1st time in 5.3 releases history
I do not understand why you keep saying that it was a major mistake to
do it this way.
I can understand that the chaotic way fits more to your ideas about
how things should work however it totally fails to actually get 3rd
parties involved more deeply in our developments (be QA or to
integrate latest releases to their products, like most unix distros).
What I suggest is to do it again the same way for 5.3.2, I will
improve the tools to make it more transparent and full fills your
requests (except the bug trackes, which is another major issue that we
will have to address very soon as well). Then we can have this
discussion again. The reason is that both Johannes and I were happy
(not 100% but more than 50% :) with it and it allows us to sleep
better during the release phases.
Cheers,
Pierre
Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
The NEWS file would tell me why patches were not merged? Also the news file does not contain entries about many fixes that don't have corresponding bug # attached to them.
As I recall the 5.3.1 NEWS entry were merged back to the PHP_5_3 6 days after the release by you ;-).Ok, so what you are arguing about is that you don't know why something
was not merged. That's something we like to improve but it has nothing
to do with the extra branch, absolutely nothing.Cheers,
Pierre,
What's the status of the SNMP fixes? I see that SNMP is still not in
the 5.3.x code.
Larry
hi,
What's the status of the SNMP fixes? I see that SNMP is still not in the
5.3.x code.
Don't hijack threads with off topic questions, thanks (and use text email :).
I suppose you refer to the netsmnp library, then I return you the
question, what's the status of your work and tests?
Cheers,
Pierre
hi,
What's the status of the SNMP fixes? I see that SNMP is still not in the
5.3.x code.Don't hijack threads with off topic questions, thanks (and use text email :).
Eh? How is his question off topic? As far as fixes this could be what he is referring to
Fixed bug #49990 (SNMP3 warning message about security level printed twice).
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
hi,
What's the status of the SNMP fixes? I see that SNMP is still not in the
5.3.x code.Don't hijack threads with off topic questions, thanks (and use text email :).
Eh? How is his question off topic? As far as fixes this could be what he is referring to
Because it has nothing to do with PHP releases or ext/snmp directly
but the snmp library on Windows for PHP 5.3 and later. We don't use
because the latest smnp releases do not work on Windows.
Cheers,
Pierre
Pierre Joye wrote:
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
hi,
What's the status of the SNMP fixes? I see that SNMP is still not in the
5.3.x code.Don't hijack threads with off topic questions, thanks (and use text email :).
Eh? How is his question off topic? As far as fixes this could be what he is referring to
Because it has nothing to do with PHP releases or ext/snmp directly
but the snmp library on Windows for PHP 5.3 and later. We don't use
because the latest smnp releases do not work on Windows.Cheers,
They do work. However, Pierre and I have to close the loop on a few
things related to VC9. I'll re-engage. Pierre is very busy I know. We
all are.
Regards,
Larry Adams
aka TheWitness at cacti dot net
It was not, and we did not forget it because of the automatic TODOs in
the wiki (it shows all commits in a list with their states,
http://wiki.php.net/todo/php531/log) :-).BS, I reminded Johannes about that patch right before the final RC, because it was still not merged.
Which only the value in the sample php.ini files was, the fix itself
was. And no I don't claim it was perfect and I opened this discussion
for the purpose to decide on this. I think if we all want the release
branch is the better process to create a stable release with less risk.
But I can live with either approaches.
johannes
As far as the wiki goes, most people don't even know it exists
If a PHP core developer does not know about it, then we have a serious problem.
There are at least 4 people I spoke with that didn't know about it, I would say there are probably more.
Well that only means we need to make sure that developers know about stuff like this. Do we need an (irregular) newsletter to inform people? I mean we have had this problem as well with commit freezes, but there it was actually a bigger problem. If we do stick with the wiki for now .. then all that needs to happen is to inform relevant developers once .. and nothing breaks if they do not know about it at a fixed date .. like with a commit freeze.
In other words, the problem might exist, but its solvable and is unrelated to using a branch or not.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
As Lukas pointed out, both approaches have flaws, but I think
the new merging approach is much cleaner and prevents people
from committing during a freeze.
Although the wiki might not be the perfect place to do things,
I think the general approach is good. Core developers should
know what's going on in the wiki, or at least don't complain.
Cheers
Pierre,
Actually patches were indeed missed, in fact we almost missed a security fix. As far as the wiki goes, most people don't even know it exists, let alone where to find it. Also, looking at the wiki there are a whole series of patches that did not go in into 5.3.1, that there is little indication as to why they didn't.
2009/12/7 Ilia Alshanetsky ilia@prohost.org:
Johannes,
While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch.
It was actually the exact opposite. We did not miss patches once we
were synced. The way we tracked the patches also let us actually
define what must go in and what not, avoiding the classical last
minute bad patches. The key to success is to do not let go months
between a commit and its merge to the release branch, which was a real
pain when we began 5.3.1.Cheers,
Pierre
While the separate branch release for 5.3.1 was a worthwhile experiment, I think it creates too much opportunity for missed patches and quite frankly makes the whole release process confusing and complicated. My personal preference would be that 5.3.2, not be released from a separate branch.
I remember that when I was RM that the need for code freezes was one of the most painful things to manage. So not having to deal with that seems like a very appealing target for all involved.
As for risk of missed patches and confusion. I think Pierre did the best he could to improve the transparency of the process with the wiki page. However we still have plenty of ways to make this even clearer and more obvious to follow. Especially integration into the bug tracker (aka milestone support) would go a long way here. Making sure that every commit has a bug id attached (or if necessary gets a bug ticket created on the fly and the id injected into the commit) could also help.
Obviously such infrastructure will not materialize over night, but I would urge everything to not drop the idea entirely.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
While the separate branch release for 5.3.1 was a worthwhile
experiment, I think it creates too much opportunity for missed patches
and quite frankly makes the whole release process confusing and
complicated. My personal preference would be that 5.3.2, not be
released from a separate branch.
I second that; I had no clue what was going on, and I only found out
about this wiki thing afterwards. Please get things back to normal like
we do with 5.2.
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
Derick Rethans wrote:
While the separate branch release for 5.3.1 was a worthwhile
experiment, I think it creates too much opportunity for missed patches
and quite frankly makes the whole release process confusing and
complicated. My personal preference would be that 5.3.2, not be
released from a separate branch.I second that; I had no clue what was going on, and I only found out
about this wiki thing afterwards. Please get things back to normal like
we do with 5.2.
Aye. No more wikis or branches. The way 5.2 releases have been done has worked
just fine 11 times. No need to reinvent the wheel here.
Also, 5.3.2 should include the new output buffering code that fixes about 10
open bugs currently in the tracker. Johannes, you seem to ignore emails, so try
check the bugs assigned to you. And hopefully you won't disappear again for weeks.
--Jani
Hi!
Aye. No more wikis or branches. The way 5.2 releases have been done has
worked just fine 11 times. No need to reinvent the wheel here.
Actually, it didn't work just fine, it was quite painful (each time one
wants to fix the bug one needs to see if we are in freeze or not and
then not forget to merge it after freeze is over, and RM can't really
keep track of the stuff because he doesn't know how many patches people
withheld because of the freeze). The fact that we learned to put up with
that does not mean it can't be improved.
P.S. for your enjoyment: http://despair.com/tradition.html
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Personally, I like release branch approach better, provided:
-
For the announced release period, each commit into the tree is logged
automatically (I understand the wiki does that? if not we may need to do it) -
RM takes on himself to make a decision (which is recorded - say, in
wiki) on each commit. I.e. if one is not merged, there should be a mark
saying RM has reviewed it and decided not to merge, not just forgot it. -
The URL of this log page is included in RC announcements so people
could see what's going on.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
2009/12/7 Stanislav Malyshev stas@zend.com:
Hi!
Personally, I like release branch approach better, provided:
For the announced release period, each commit into the tree is logged
automatically (I understand the wiki does that? if not we may need to do it)RM takes on himself to make a decision (which is recorded - say, in wiki)
on each commit. I.e. if one is not merged, there should be a mark saying RM
has reviewed it and decided not to merge, not just forgot it.The URL of this log page is included in RC announcements so people could
see what's going on.
+1 (even though I hate wikis)
With one tweak:
2a)
Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits
should be explicitly merged in separate commit.
-Hannes
Hi!
With one tweak:
2a)
Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits
should be explicitly merged in separate commit.
Right, I agree (I implied that but it's good to say this explicitly).
As for wiki, I don't care if it's wiki, shmiki or anything - only thing
important is that we have a list of things which is public so RM has it
and anybody can see what happens with it.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
With one tweak:
2a)
Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits
should be explicitly merged in separate commit.Right, I agree (I implied that but it's good to say this explicitly).
As for wiki, I don't care if it's wiki, shmiki or anything - only thing important is that we have a list of things which is public so RM has it and anybody can see what happens with it.
I think the wiki can only be a temporary solution and this should be managed entirely inside the bug tracker (dream). A new bug tracker that addresses our needs as they are today would really help in so many ways. But its obviously a big task.
However for 5.3.2 it would be ideal to at least parse out bug ticket id's from the commit messages and when a reason for not merging a ticket is added to the wiki it would be automatically submitted to the bug tracker as a comment. Not sure how easily this could be done though and I cannot commit time to checking this out myself :-/
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
I think the wiki can only be a temporary solution and this should be
managed entirely inside the bug tracker (dream). A new bug tracker
that addresses our needs as they are today would really help in so
many ways. But its obviously a big task.
yes, it will be temporary, but it will be an improvement. If somebody
would want to work on Bugtracker NG - all power to him, but in the
meantime if we have solution that we can make work for now, and we have
people willing to take it - let's do it.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
I'm +1 on the release branching, but i'm only a test committer so my
opinioin miht not weight that much here. I am however using this exact
model in my own team and it has proven to do very well when tied in to
Trac for tracking merges and all that.
How hard would this be to add to the bug tracker?
I'm kinda out of time, but i'm sure i can conjure up someone in the
Brazilian Community that can take a look into it, any RFC's around?
--
Rafael Dohms
PHP Evangelist and Community Leader
http://www.rafaeldohms.com.br
http://www.phpsp.org.br
Just out of curiosity, is there any open source bug tracker out there
that would lend itself well to these needs? Currently the bug tracker
is highly customized so when thinking about adding those new features,
it may also be a good time to look around ;-)
Hi!
With one tweak:
2a)
Committing to 5_3 and 5_3_2 in one go is bad bad. The 5_3_2 commits
should be explicitly merged in separate commit.Right, I agree (I implied that but it's good to say this explicitly).
As for wiki, I don't care if it's wiki, shmiki or anything - only thing
important is that we have a list of things which is public so RM has it
and anybody can see what happens with it.I think the wiki can only be a temporary solution and this should be managed
entirely inside the bug tracker (dream). A new bug tracker that addresses
our needs as they are today would really help in so many ways. But its
obviously a big task.However for 5.3.2 it would be ideal to at least parse out bug ticket id's
from the commit messages and when a reason for not merging a ticket is added
to the wiki it would be automatically submitted to the bug tracker as a
comment. Not sure how easily this could be done though and I cannot commit
time to checking this out myself :-/regards,
Lukas Kahwe Smith
mls@pooteeweet.org--
--
Tjerk
2009/12/7 Johannes Schlüter johannes@php.net:
Any comments?
Only one remains at this stage, where do we stand? I worry a little
bit about mysql, always seeing so many commits right before we begin a
release does not sound right to me. What's the status there?
Cheers,
Pierre