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
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