On 06/09/2012 12:28 AM, Sergiu Dumitriu wrote: > On 06/08/2012 05: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 >> opposed to a change but IMO if we want to change it we need to proceed with >> extra caution. > > The purpose of the RC releases was as a kind of staging, without actually > using real staging. So I'd say that for the next releases we should only have > milestones, and staged final releases. > > However, for 4.1 we should keep the rc-1 release in the plan, since our > staging process is new and not thoroughly tested yet.
+1 also I think changing the rules in the middle of a release misrepresents the seriousness of the project. > > The way I simulated "staging releases" when I had the RM hat was to leave a > window between uploading the artifacts in our maven repository and pushing > them further, and in this window I did quick smoke tests to see that > everything works (with the help of Sorin and the rest of the QA team at XWiki > SAS). > > So, I propose this as the strategy for our next releases: > - Each release goes to a staging repository first +1 > - Milestone releases spend a little time in staging, enough for a few quick > smoke tests; depending on the time of day, this could last from an hour to at > most a day +1 > - There are no RC releases, there are only RC staging repositories. Currently > the staging repositories have random names, but the RM should rename each > repository with the proper RC name: 4.2-rc-1, 4.2-rc-2 if the first build was > busted, and so on. The version written inside the packages is the final one, > like 4.2, without a rc-x suffix. While in staging, a RC release goes through > more intensive tests, including smoke testing, the full MTR, and developers > that contributed to the release should > test their committed features. Maybe even a Jenkins job could be executed for > that release, with all the automated tests. +1 > > Timing? Since we don't know how many times we have to stage releases, I'd say > that we can start building RCs one week before the planned final release > date, and if bugs are found, a new RC is build the next day (to let issues > accumulate), hoping that there will be a stable successful build before the > final release date, without a 72h mandatory waiting period. +1 Since this has become a bit of a brainstorming session I think it makes sense to have another official vote. Thanks, Caleb > >> 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
