On Tue, Sep 27, 2011 at 9:23 AM, Fathi Boudra fathi.boudra@linaro.orgwrote:
On 27 September 2011 09:59, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra fathi.boudra@linaro.org
wrote:
Hi Ricardo,
On 27 September 2011 06:23, Ricardo Salveti ricardo.salveti@linaro.org
wrote:
Any specific reason why using the build from 0926 as the RC instead of 0927?
According to the schedule, RC images are delivered 3 days before the
release,
Monday at 16:00 UTC. That's why for Linaro 11.09 RC, it's the the build 20110926.
This is just because the images are created after 00 UTC, so the images from 0926 are actually the ones built at the beginning of monday, and not after monday. This is critical for us because we usually have friday and monday for final integration, and getting the images created at monday will actually reduce one day of work for us. One example is that I usually update the base-files package at monday, but this time the RCs are still using the old base-files package, requiring then an image respin for the final release.
For your specific example, base-files should be updated on Thursday,
with
Linaro components release. This changes doesn't affect the testing.
Don't know if updating it on thursday would be the best case, but sure, it can be done at least at friday.
And it doesn't change the testing, but we need an image respin.
IMO, we should stick to Monday for the RC images and call for testing. It gives 3 full days to collect the reports and fixes critical issues. Though, using autobuilt images isn't optimal. What about triggering a manual rebuild on Monday at 16:00 UTC to get the RC images? This way it gives some extra time for integration, but not a full day. Unfortunately, the schedule is tight on a monthly release cadence... so we don't have much flexibility.
We could just have a build job scheduled at 16 UTC at offspring, so we avoid requiring manual builds. I believe this would be our best option (and it usually takes around 3 hours to build all images).
sounds a good compromise.
Then the other question is how are you tracking an image respin during the call for testing, as you're pointing the image links and not just the directory containing the images?
An image respin is tracked with bugs and is handled by the release response team. The point of contacts are in charge of testing the new images.
Sure, but I also believe we should have a better way to communicate the community and others about an image respin, so we avoid people testing the images provided by the call for testing email when another one is already available.
I'll try to better communicate to our wider community on the testing progress on linaro-dev ml by doing follow-up on the call for testing mail.
I got this idea to setup a linaro-release twitter/google+ feed to update folks about RC, release progress, critical bugs discovered during testing, respins etc.
You would probably announce one time before release week on linaro-dev that detailed release updates go there there and folks can then opt-into following the release team. Next, we can also write a bot that auto posts respins during release week there.