[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
I think we should be realistic about what we can and cannot pull. Using this approach as the standard release process is simply not going to work - we barely manage an RC branch and a dev branch properly, and having to maintain an old release branch sync'd with bug fixes is not going to be within our reach. In very specific cases, such as the 4.1.0 - 4.2.0 change, if there are going to be some key bugs in 4.1.0, releasing a 4.1.1 based on 4.1.0 would be in order. Otherwise, though, I would say that we're only toying with a non practical idea :) Zeev At 02:36 14/11/2001, Stig S. Bakken wrote: Andi Gutmans wrote: At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). - Stig -- PHP Quality Assurance 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] -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
Andi Gutmans wrote: At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote: I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). Stig, I understood the point from the beginning and I have no problem in trying. I was just skeptical about how well it will work in real life. I think it will work if we can streamline the release process so it takes a couple of weeks instead not six months. This way HEAD and the release branch won't be too different when the release is out. If we also get rid of extensions, there's even fewer potential conflicts. He who lives will see. :-) I think it's definitely worth an try. - Stig -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
Andi Gutmans wrote: At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). - Stig -- 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote: I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). Stig, I understood the point from the beginning and I have no problem in trying. I was just skeptical about how well it will work in real life. Andi -- 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]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 05:28 12/11/2001, Jani Taskinen wrote: Zeev suggested at some point that we should drop the last number altogether. I *what*? Perhaps I was high on that Kossu :) I was never in favour of dropping the 3rd digit. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. Indeed. What I suggested: Only bug fixes go into the release branch. And all the nifty new features and big changes and BC breaking stuff go into the next release branch (HEAD). (ie. version 4.x+1.0 ) As I've said repeatedly, there's no reason *at all* to move from our old, de-facto standard versioning scheme to this one. The process is fine, but the following version should be a .0.1 add-up. I really fail to see why you mix the version number with what a new version may include. And, of course, it has nothing to do with the fact that once we branch a release branch, be it 4.0.7 or 6.4.2.4.6.1.2.5.4, no new features should go to it - only bug fixes. It's not very far from what we are doing right now. We have two branches, the release one and HEAD. But what I suggested was to keep the release branch and commit bug fixes into it and release bug-fix-only-releases from it. Why would it be hard time doing it? It's not hard as long as certain rules are followed. It needs a bit more work and people who are dedicated for doing it. But the core developers ([EMAIL PROTECTED]) should first ratify all this stuff. :) Jani, it's simply not going to work. New features and bug fixes are often closely interweaved. Also, *bugs* and new features are often closely interweaved. What you are suggesting is basically to step with full steam into the biggest synchronization nightmare possible. The system and rules we have right now are good. The flaw, if any, is in the amount of work that goes into bug fixing, from your point of view, which I can certainly understand. But changing the system to what you propose will not improve things - only more efforts towards bug fixing will. Not only that - it's bound to create synchronization problems from hell, things you don't even dream about when you use a simple linear development model as we do today. It has nothing to do with whether or not php-dev can live up to certain rules, or whether it should or shouldn't do so. Rules are not the problem here. Zeev -- 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]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 05:28 AM 11/12/2001 +0200, Jani Taskinen wrote: On Sun, 11 Nov 2001, Andi Gutmans wrote: I didn't quite understand what you mean :) I didn't get it first either. :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. The idea is NOT to go on for _months_ with the HEAD. The idea is to make it shorter by keeping the amount of testing smaller. And this is what the versioning stuff was aimed at too. Most people out there think that when a version number changes on the 'micro' part (4.1.x) it means that there are only bug fixes in this release and I can safely go ahead and update without fearing that something breaks. At the moment, you can't trust on this. It's definately NOT like all the other projects do. Zeev suggested at some point that we should drop the last number altogether. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. What I suggested: Only bug fixes go into the release branch. And all the nifty new features and big changes and BC breaking stuff go into the next release branch (HEAD). (ie. version 4.x+1.0 ) It's not very far from what we are doing right now. We have two branches, the release one and HEAD. But what I suggested was to keep the release branch and commit bug fixes into it and release bug-fix-only-releases from it. We can try and do this. I'm not quite sure it'll work in real life but I think it's it's worth a try. I agree that it is not much different than today but it requires someone who will take the job of screaming at ppl if they commit a bug fix to HEAD and not to the release branch. Also at some point we have to decide not to release bug fixes anymore for a certain version but I'm quite sure it'll come naturally with the release of the next more major version. Why would it be hard time doing it? It's not hard as long as certain rules are followed. It needs a bit more work and people who are dedicated for doing it. But the core developers ([EMAIL PROTECTED]) should first ratify all this stuff. :) Oh, I forgot..rules are bad..we're all volunteers..etc. crap. Why can't we improve this? It has worked for so long now.. and that is bull too. It might have worked and might work for a while but if we really want to make the quality better, we have to make some changes. All I meant by it has worked for so long is that it's not as if the situation has been horrible. It's been pretty decent but I am all for improvement. IMO opinion we need to appoint a couple of people so that when there is a concensus to branch and start the release process they will make sure it is pushed a bit. Look at the bug database: 803 open bug reports (feature requests, doc probs and website probs excluded) of which about 70% are not bugs but user errors and such. That still leaves us with over 200 reports that are real bugs. Some of them are in extensions which have been abandoned or the people who 'maintain' them don't simply care. But this is another story. (btw. in Scripting Engine related bugs there are 69 open reports.. :) Anything interesting? :) --Jani ..who's getting pretty tired at banging head on the wall.. I think we're actually getting somewhere. Andi -- 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]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. - Stig -- 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]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Jani Taskinen wrote: On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms - Create a build tracker to qa.php.net (Bat[e] ?) - Make the bug system to send bug reports to php-qa list and only confirmed reports to php-dev thus making it easier for developers to notice which reports are real bugs. Huge amount of the reports coming in are bogus. With all this I think we can avoid this kind of situations in the future as the amount of testing will get smaller. And democracy doesn't always work. :) Of course these release-dictators should be elected somehow so that evil dictators never get the power again. :) I think all of these are good ideas that will contribute to getting us out of this mess.
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Andi -- 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]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
Guys, I mentioned this in the conference. Version numbers aren't going to change anything significant. If we're concerned about the users' perception of what the version number means, moving to Jani's versioning scheme, I'm pretty confident it'll mean less to more people. The reason being the fact that people are used to PHP's existing versioning scheme, which is the de-facto standard in the opensource world, and you should be quite aware that the vast majority of users will never read our explanation as to what the version number means, no matter how nicely we put it. That's the advantage of using a standard. I think that we're too harsh on the system we have in place right now. It usually works. It really does. True, 4.0.7 lingered on for a variety of good and bad reasons, but even in this extreme case - we're not faced with a tragedy, but some dilemma, at most. *Every* system has its advantages and its disadvantages, there's no perfect system. Those who suggest that we switch should think carefully about what the gains will be, and whether they'll be worth the losses. I have a feeling that currently people feel that 'anything would be better than what we have now', when in reality, we have a system that works at say 70% or 80% efficiency, and switching may very well make things worse at the bottom line (i.e., worse product for the end user) than they are today. Zeev At 01:31 11/11/2001, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. - Stig -- 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] -- 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]
[PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms - Create a build tracker to qa.php.net (Bat[e] ?) - Make the bug system to send bug reports to php-qa list and only confirmed reports to php-dev thus making it easier for developers to notice which reports are real bugs. Huge amount of the reports coming in are bogus. With all this I think we can avoid this kind of situations in the future as the amount of testing will get smaller. And democracy doesn't always work. :) Of course these release-dictators should be elected somehow so that evil dictators never get the power again. :) --Jani -- 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]
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi At 10:34 PM 11/10/2001 +0200, Jani Taskinen wrote: On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms
Re: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Because that appears to be rediculous idea. At present, unless you have a problem which requires you to upgrade, you stick with the stable proven release. The only reason why Linux kernel gets released so often is because it contains security fixes that affect everyone and are in the public. Security fixes should be released immediately. Just bug fixes, added features and optimized functions should only be done in major releases. Keep in mind, with every new feature, we break another two. Do you _really_ want that many new things on production machines that haven't been properly testes. In 4.0.7, there was a complete rework of the Zend memory management by my understanding- Imagine not testing that at all and putting it out. You are asking for serious problems. Administrators do not want to be upgrading on a weekly basis (or less). We need to keep stable, quality, secure releases- and that only comes from extensive testing. My point- yes it is more work, but let's make a new release candidate from 4.0.7 and release it. It's stable and seems very reliable. It also makes less work for Zend releasing thier optimizer for each release of PHP. Please guys- do not consider regular small releases. Major releases that are properly tested and released (and yes I do keep up on CVS much of the time to test and contribute to the code- I am one of those properly testing it) -- -- Mike - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, November 10, 2001 4:34 PM Subject: [PHP-DEV] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0) On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.h tml This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version
