On Tue, Sep 27, 2011 at 9:23 AM, Fathi Boudra <fathi.bou...@linaro.org>wrote:
> On 27 September 2011 09:59, Ricardo Salveti <ricardo.salv...@linaro.org> > wrote: > > On Tue, Sep 27, 2011 at 3:19 AM, Fathi Boudra <fathi.bou...@linaro.org> > wrote: > >> Hi Ricardo, > >> > >> On 27 September 2011 06:23, Ricardo Salveti <ricardo.salv...@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. -- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
