On Jun 8, 2012, at 11:07 AM, Caleb James DeLisle wrote: > > It seems that if we want to shorten a release cycle, we have 2 options: > > #1 No RC release > #2 No staging > > I think it would be a shame to scrap staging over this, especially since > my understanding is we want to move toward frequent releases with no > release candidates or milestones so staging would be a requirement. > > This is an interesting topic which can be discussed. > > Right now for 4.1 I think we need a coherent proposal rather than an adhoc > chop-and-slice of the agreed upon schedule and dates. > Finally, I'm concerned about changing our release process in the middle > of a release which is behind it's normal schedule. I'm not completely
We're not behind schedule at all. Again the dates we've shown to the world are those listed on http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap And they say: * RC1 released on 11th * Final released on 18th So we're still good :) Thanks -Vincent > opposed to a change but IMO if we want to change it we need to proceed with > extra caution. > > Thanks, > > Caleb > > > On 06/08/2012 03:15 AM, Vincent Massol wrote: >> Hi guys, >> >> I'd like to bring an issue with this VOTE below. >> >> When I initially read it I didn't realize that this was about doing >> double-staging: >> * once with nexus staging >> * another one with the RC release >> >> So it increases the time we spend for doing releases instead of reducing it >> which is the direction we would like to go. >> >> The increase is bad because we're already spending too much time just on the >> release itself while we should reduce it to a minimum so that we can focus >> on developing new features/improvements/fixing bugs. >> >> So IMO if we really want to go with staging we need to remove the RC phase >> and go from M2 to Final directly. However if we were to do this we would >> need to find a way to advertise it as a release on all channels because this >> is the time when we need to most testers. Right now it seems to me that an >> official RC is much more powerful than staging >> >> Thus I'd like to retract my vote on this (if it's not possible I'll send a >> new vote to not do double staging). >> >> Thanks >> -Vincent >> >> PS: Sorry for not realizing this earlier... >> >> On May 22, 2012, at 10:55 AM, Caleb James DeLisle wrote: >> >>> Hi, >>> >>> I'd like to add staging to our official release process. >>> For milestone releases, I propose the staging cycle be for "0 time" (this >>> may be revisited later). >>> For RC or finals, we place the release in staging and immediately call a >>> VOTE to publish the release, this gives our testing team (everybody!) 72 >>> hours to raise a potential issue. >>> >>> Why: >>> >>> #1. After some chat on IRC I decided that it is advantageous to move toward >>> a faster release cycle and begin moving away from milestone releases in >>> favor of staging. This will set the stage for the release method we will >>> need. >>> >>> #2. Staging is easy, I've modified the release script to include staging >>> and with the script, it is a simple matter of about 5 clicks on nexus to >>> "login", "close repository", "release repository". >>> >>> #3. Staging is safe, the RM need not worry about fat fingers breaking the >>> release, all it costs is time. >>> >>> #4. The release process should be as close to the same as possible for >>> milestone and RC/final releases. This simplifies scripting of the process, >>> decreases the amount the RM must remember and makes every milestone release >>> a rehearsal. >>> >>> #5. Everybody else is doing it (is that even a reason?!) >>> >>> >>> Mandatory? >>> I would rather impress the RM with how easy and helpful staging can be than >>> bind him with rules. >>> If I had followed the existing process to the letter, I would not have had >>> any experience with staging to begin with. >>> In the interest of continuous improvement I would like to make this a >>> strong recommendation, not a strict rule. >>> >>> >>> Here's my +1 >>> >>> Caleb >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
