On 24 August 2012 14:49, Amit Kucheria amit.kucheria@linaro.org wrote:
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.
Hi Amit,
Following are the dates when I have published releases:
V1 - 4th July V2 - 11 July V3 - 16 July V4 - 25 July V4 (resend) - 26 July: Patches requested by Paul E. McKenney V5 - 14 Aug V6 - 17 Aug - removed Vincent's patch V6 (resend) - 23 Aug - Vincent's patch again required :) V7 - 24 Aug
Most of the times, release were due to: - New branch/topic - New Version of earlier patchset - Sometime fixes
Till now, the stats are pretty ugly :( Mostly because of the cases, where i just publish a version and somebody asks me to include/exclude something. That makes the resend versions found above.
I would like to go for 5th and 20th of every month, as 20th is a bit close to WG freeze date for the month.
In the mean time, for whatever updates we have, I will create the next version branch and publish it. But will not send a pull request for it.
How does that sound to you guys?
-- viresh