Am 29.11.2010 18:42, schrieb Anthony Liguori: > 0.13 was a mess of a release (largely due to my lack of time) and I'd > like to get us back onto a predictable schedule.
Telling people six days in advance when the fork will be is hardly predictable. :-) For example, in the block area there are currently a lot of interesting patches on the list (AHCI, SCSI, block-queue, QED, Ceph) and there's no way to integrate them in time if we don't want to blindly apply patches and then see what breaks. What to do with them? The options I see are: 1. Move them all to 0.15 (when will it be?) 2. Apply everything now, have a broken rc0 and hope to fix everything in the short time until rc2 3. Fork 0.14 shortly before Christmas and move the release to January The usual approach for dealing with feature freeze deadlines seems to be option 2, though I don't really like that one... For 0.15 I suggest that the fork date should be announced at least a month in advance and that we have a longer RC phase. After all, 0.13 was a bit of a mess because nobody knew when it would be released, but in the end I don't think the additional time to stabilize in stable-0.13 hasn't hurt. I admit that three months was really a bit long, but I think if we planned for more than 10 days from the fork to the release (maybe a month?), we would have much less trouble with predictability. > I think we should also try to implement an Ack process for stable. For > instance, I think it would make sense for Justin to send out stable > patch candidates regularly and require 3 community Acked-by's for the > patch to go into stable. I'm not sure if this is too much process but > by the same token, as long as we full the above rule, this should be a > trivial step for folks to follow. I think three Acks might be a bit too much, but requiring one or two Acks probably makes sense. Though I think we need to consider that there are areas where it would be easy to get five Acks, and other areas where it's going to be hard enough to get at least one. Kevin
