I think Glance reviewer brandwidth is pretty low and the feedback time can be quite high. For specs, I had requested a section describing the core reviewer who will be vouching for your spec to be added to the spec itself. I think in general we have not seen anyone doing that strongly.
If a spec isn't proposed as a priority at the beginning of a summit and if it's a big change and is not decided to an extent, it becomes quite tricky to get in the project in that cycle. As a general feedback I have always recommend bringing feature proposals at summit sessions, mid-cycle, meetings etc etc. If a feature has missed it other proposal have gotten priority. Also, there were priorities that were set the beginning of the cycle and if a proposal isn't on the list there, it becomes tricky to make a call for a new spec to get merged in one cycle. <that's some additional feedback> Happy to help on the process, review speed, activities 'context' more if you want input. On 10/6/15 11:52 AM, Julien Danjou wrote: > On Tue, Oct 06 2015, Flavio Percoco wrote: > > I send patches to Glance from time to time, and they usually got 0 > review for *weeks* (sometimes months, because, well there are no > reviewers active in Glance, so: > >> 1) Lets do this on patches that haven't had any activity in the last 2 >> months. This adds one more month to Erno's proposal. The reason being >> that during the lat cycle, there were some ups and downs in the review >> flow that caused some patches to get stuck. > This is going to expire my patches that nobody cares about and that are > improving the code or fixing stuff people didn't encounter (yet). > >> 3) The patch will be first marked as a WIP and then abandoned if the >> patch is not updated in 1 week. This will put this patches at the >> begining of the queue but using the Glance review dashboard should >> help keeing focus. > Why WIP? If a patch is complete and waiting for reviewers I'm not sure > it helps. > > The problem is that nobody is reviewing Glance patches (except you > recently it seems). That's not going to solve that. That's just going to > hide the issues under the carpet by lowering the total of patches that > needs review… > > My 2c, > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Nikhil
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev