On 03/06/2014 07:05 AM, John Garbutt wrote: >> That being said, importance isn't a FIFO. > > Agreed, but it seems most of them are quite useful, and a lot have > already been through a few review cycles.
I think this is a key point. Regardless of how long something has been in the queue, importance isn't a FIFO queue. This is mostly just about setting expectations. It's more of a ... priority based heap? I think what you're proposing is fine. I would state it as something like: - This primarily applies to blueprints that were close to merging. This means that the code already had some core review iterations and was getting close. - Have your code rebased and ready for review as soon as Juno dev opens. This gives reviewers the best chance to get back to it, and since it was close, it has a good chance for juno-1. Even for stuff that wasn't actually close to merging, this is still the best practice to give your patches the best chance. However, if there are things coming in than review bandwidth available (the current reality), you're competing for review attention. It has to be compelling enough to get priority on its technical merits. The other angle is to increase your general karma in the dev community so that reviewers are compelled to help the *developer*, even if they are ambivalent about the particular code. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
