Re: [PHP-DEV] release process with git
On Tue, April 17, 2012 3:34 am, Martin Jansen wrote: On 17.04.12 10:24, Bas van Beek wrote: Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. Willing to? Yes. Happy about it? No. Deciding PHP is a PITA because it keeps making them work on weekends? Bad Idea. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
On Mon, Apr 9, 2012 at 08:54, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked backforth a bit, but I assume we'll usually release on Thursday and count back from that). (tiny hijacking). The whole point of releasing on Thursdays is so sysadmins have the chance to update their servers in the event of known security problems before the weekend. This point however becomes void when we release late Thursdays evening American time, and we could just as well release on Saturday nights as noone in Europe will be able to update their servers, and the Americans will probably not be updating theirs either when they notice the release Fridays after lunch. Even keeping in mind most sysadmins probably use distro packages, these packages won't be built by their maintainers late Fridays and therefore never rolled out to the public until after the weekend. If we however switch to Tuesdays we atleast give the sysadmins (and package builders) a fighting chance of not needing to decide between running possibly very unsecure environment over the weekend or risk breaking the production environment due to unforeseen mishaps. Could we swap the release day to Tuesday? Or atleast very very very very early morning Thursdays? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
Op 17-4-2012 9:47, Hannes Magnusson schreef: On Mon, Apr 9, 2012 at 08:54, Stas Malyshevsmalys...@sugarcrm.com wrote: Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked backforth a bit, but I assume we'll usually release on Thursday and count back from that). (tiny hijacking). The whole point of releasing on Thursdays is so sysadmins have the chance to update their servers in the event of known security problems before the weekend. This point however becomes void when we release late Thursdays evening American time, and we could just as well release on Saturday nights as noone in Europe will be able to update their servers, and the Americans will probably not be updating theirs either when they notice the release Fridays after lunch. Even keeping in mind most sysadmins probably use distro packages, these packages won't be built by their maintainers late Fridays and therefore never rolled out to the public until after the weekend. If we however switch to Tuesdays we atleast give the sysadmins (and package builders) a fighting chance of not needing to decide between running possibly very unsecure environment over the weekend or risk breaking the production environment due to unforeseen mishaps. Could we swap the release day to Tuesday? Or atleast very very very very early morning Thursdays? -Hannes Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. Bas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
On 17.04.12 10:24, Bas van Beek wrote: Sounds like facilitating wrong security protocols to me. In this 365/24/7 environment, sysadmins should be willing and able to patch, fix and secure systems at any time. Weekend should be no excuse. There are a lot of (very serious) shops out there without a 24/7 ops schedule. Let's not hurt them without a solid reason. - Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
On 04/10/2012 03:46 PM, Stas Malyshev wrote: Hi! I think my main point still stands: if the git emails are too obscure to follow, let us know what goes in via email to internals. Do you want to bring the NEWS updating process into this discussion? Sure, though that would be another discussion IMHO. In this discussion, I just wanted to see if there are any objections to this clean release model. Stas, Currently is seems the PHP-5.4 branch is building version 5.4.1RC1-dev while the PHP-5.4.1 branch builds version 5.4.1RC2. I think that once PHP-5.4.1 was branched, then PHP-5.4 should have become 5.4.2-dev. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
Hi! I think that once PHP-5.4.1 was branched, then PHP-5.4 should have become 5.4.2-dev. You're right. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
On 04/16/2012 01:12 PM, Stas Malyshev wrote: Hi! I think that once PHP-5.4.1 was branched, then PHP-5.4 should have become 5.4.2-dev. You're right. As an exercise, I submitted a pull request fixing this. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] release process with git
Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked backforth a bit, but I assume we'll usually release on Thursday and count back from that). 2. This branch is checked by RM to compile, pass unit tests satisfactory, etc. and is released as 5.4.X RC1 3. In two weeks, if no critical errors is found in RC1, the same branch is released as 5.4.X. If any critical errors are found, RM cherry-pick fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks after no criticial bugs are in 5.4.X branch. 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from 5.4.X. If not, it is postponed by 2 weeks. It is somewhat different from what we did before as we never disallow committing into 5.4 and never allow (direct) committing into 5.4.X. This also means we will be releasing 2-weeks-old code (or maybe older), i.e. we will frequently be releasing code which has known (and fixed in other branch) bugs. This will also mean we will have to define what constitutes critical error, and maybe raise the bar a bit. I would like to propose the following criteria for critical error: 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe some others at RM discretion) 2. Remotely exploitable security problem 3. Bug that breaks a large piece of widely used functionality, effective rendering it unusable (i.e. if somebody broke fopen() and it always returned false). Other things may be added on case-by-case basis but this will be the guidelines. All other changes go into the next release. I think doing it this way will allow us to have 5.4.X releases monthly as we planned in the release RFC. This will also mean that there would be almost constant lag between committing regular fix and releasing it, which may be larger than we had before. I think it won't be too bad if we had regular monthly releases. Comments? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] release process with git
This is a very similar process to what OpenStack uses, it seems to work well for them. They have a few guys on freenode in #openstack-infra that have shown themselves more than willing to go into detail about their setup and its pro/con's.. It would be worth asking them for their experience... Thanks, Kiall Sent from my phone. On Apr 9, 2012 7:54 a.m., Stas Malyshev smalys...@sugarcrm.com wrote: Hi! 5.4.1 will be the first release we're releasing using our new git setup. I would like to refine a process that we used to have for releases and make small tweaks hopefully to allow us more predictable release schedule and faster releases. What I am proposing is the following: 1. At the start of the cycle, PHP-5.4.X is branched off PHP-5.4. This is done on Monday/Tuesday (days can be tweaked backforth a bit, but I assume we'll usually release on Thursday and count back from that). 2. This branch is checked by RM to compile, pass unit tests satisfactory, etc. and is released as 5.4.X RC1 3. In two weeks, if no critical errors is found in RC1, the same branch is released as 5.4.X. If any critical errors are found, RM cherry-pick fixes from 5.4 and release RC2 (RC3, etc. as needed) each two weeks after no criticial bugs are in 5.4.X branch. 4. In two more weeks, 5.4.(X+1) starts, provided we have changes from 5.4.X. If not, it is postponed by 2 weeks. It is somewhat different from what we did before as we never disallow committing into 5.4 and never allow (direct) committing into 5.4.X. This also means we will be releasing 2-weeks-old code (or maybe older), i.e. we will frequently be releasing code which has known (and fixed in other branch) bugs. This will also mean we will have to define what constitutes critical error, and maybe raise the bar a bit. I would like to propose the following criteria for critical error: 1. Compilation failure on a major platform (Linux, Windows, Mac, maybe some others at RM discretion) 2. Remotely exploitable security problem 3. Bug that breaks a large piece of widely used functionality, effective rendering it unusable (i.e. if somebody broke fopen() and it always returned false). Other things may be added on case-by-case basis but this will be the guidelines. All other changes go into the next release. I think doing it this way will allow us to have 5.4.X releases monthly as we planned in the release RFC. This will also mean that there would be almost constant lag between committing regular fix and releasing it, which may be larger than we had before. I think it won't be too bad if we had regular monthly releases. Comments? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
