On Fri, Aug 24, 2012 at 12:37 PM, Viresh Kumar firstname.lastname@example.org wrote:
On 24 August 2012 12:32, Jon Medhurst (Tixy) email@example.com wrote:
Is this critical for this month's release? The release candidate builds are possibly already in testing so we would have to request that they are stopped and redone?
Not sure, what is fixed in this version? Maybe Morten can tell if anything crucial for task placement work is there or not.
I just noticed a new version and applied it. Can be pulled in later if there is nothing very important in it.
While our goal is to keep track of the bleeding edge, and I think you're doing a great job there, let's figure out a plan to minimise the number of kernel releases we make.
Can you look at your previous 6 releases and their dates and figure out if it would be ok to do only 2 releases a month? Were there urgent bug fixes that need to be fed in, or was it just new revs of the patchsets? If the former, then making immediate releases is the best course, if the latter, perhaps we can batch up all changes and make a release on predictable dates - say 1st and 15th of every month. This will lighten the load for everyone concerned: you, Andrey, build team with one downside: integration problems will not get detected until late.
I'd like to hear your views.