On 24 August 2012 14:49, Amit Kucheria <amit.kuche...@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
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
