Re: RFC:PHP Release Cycle

>At 11:49 PM 11/8/00 +0000, James Moore wrote: > > I don't disagree that there needs to be some method put into place to > > control the code that is being tested for the RCs. > > > > However, I seem to remember that one or more of the developers (Zeev ?) > > really hate branching (AFAIR due to problems with merging the branch > > back into the main tree.) > > > > Personally, I am afraid to get into this discussion - it is outside the > > scope of my experience. > > > > However, not knowing what I am doing has rarely stopped me in the > > past, so > > here are my thoughts on this topic. > > > > I think that QA and preparations for a release should be an ongoing, > > semi-automated process. > > > > The QA team members set up a cron event to update cvs. > > Each morning, build the source, run the tests and report any bugs or > > problems. Bugs will be marked for fix on an upcoming release. > >Yes but I have (as others do limited time) plus I work on windows so cron >is possible but is a bitch I also pay for internet access and dont want to >have to automate anything as it varies from day to day when I am on the >internet (althought that might well just be me...). To be honest running >the same tests again ang again daily on the three platforms I test isnt >realistic. Im happy to do it once every release and may be more often on my >primary platforms but daily for me at least isnt an option. That is true - not everyone is on a system that is friendly to doing this. The bulk of the smoke tests would have go to the people who have the connections and resources to do this. Or perhaps a team effort - 3 people per MS platform or something? > > When it is time for a new RC, the codebase gets frozen for a day. > > Problems get reported, changes get made and either a new RC gets > > rolled or the release gets rolled. > >I personally think we need more time for testing and you will get far more >opposition to freezing the cvs than branching it, branching does not >involve any disruption to most people and only some to bug fixers. It would be a very short freeze - perhaps still too disruptive - who knows? It really isn't our decision what happens :) > > Having a group of people building and testing each day should really cut > > down the accumulation of bugs, making the whole RC process a lot > > faster and > > easier. > >How?? It all comes down to bug visibility. If the developers don't know about a bug, then they can't fix it. If a more bugs are known, then the developers can have a much better idea of when to start on an RC. If the RC is underway and a change introduces a bug (assuming that we find it :), then the bug can be fixed or the code can be rolled back til after the release. > What tests do we run.. None AFAIK - I personally favor the following formal method: If it builds and nothing explodes, then I consider everything good. ;) >we need to get a better testing base first and then to build on that, I >think every bug that a qa member verifies should be added to the test >scripts and tested. >Then its easy to spot and we will soon get some good test scripts. we >should also write scripts to check how functions are working (IE what they >should output) but this will have to be done over a period of time once we >have sorted everything else (IE release cycle). I couldn't agree more. I am off to read Richard's message... --zak