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.
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
- 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
- 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.
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.
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
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
