> As soon as 2.4 comes out, 2.7 is created, 2.6test
> will be feature frozen.
> Development time would be shorter, and
> the nuisance with "this important feature has tz slip
> in" would be finished.
It requires too much people overhead. I have proposed another idea which is at
about 10 months in or when seems appropriate we say 'ok which bits can we
fairly reliably backport to 2.4 and call 2.6' then go on to make 2.5->2.7 and
stabilise the big changes as 2.8
That would mean driver features and the like get a yearly cycle but deep magic
gets what seems to be needed as a 2 year cycle
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:12 EST