On Tue, Nov 01, 2016 at 05:46:48PM -0400, Zane Bitter wrote: > On 01/11/16 15:13, James Slagle wrote: > > On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi <emil...@redhat.com> wrote: > > > Hi, > > > > > > TripleO (like some other projects in OpenStack) have not always done > > > good job in merging specs on time during a cycle. > > > I would like to make progress on this topic and for that, I propose we > > > set a deadline to get a spec approved for Ocata release. > > > This deadline would be Ocata-1 which is week of November 14th. > > > > > > So if you have a specs under review, please make sure it's well > > > communicated to our team (IRC, mailing-list, etc); comments are > > > addressed. > > > > > > Also, I would ask our team to spend some time to review them when they > > > have time. Here is the link: > > > https://review.openstack.org/#/q/project:openstack/tripleo-specs+status:open > > > > Given that we don't always require specs, should we make the same > > deadline for blueprints to get approved for Ocata as well? > > > > In fact, we haven't even always required blueprints for all features. > > In order to avoid any surprise FFE's towards the end of the cycle, I > > think it might be wise to start doing so. The overhead of creating a > > blueprint is very small, and it actually works to the implementer's > > advantage as it helps to focus review attention at the various > > milestones. > > > > So, we could say: > > - All features require a blueprint > > - They may require a spec if we need to reach concensus about the feature > > first > > - All Blueprints and Specs for Ocata not approved by November 14th > > will be deferred to Pike. > > > > Given we reviewed all the blueprints at the summit, and discussed all > > the features we plan to implement for Ocata, I think it would be > > reasonable to go with the above. However, 'm interested in any > > feedback or if anyone feels that requiring a blueprint for features is > > undesirable. > > The blueprint interface in Launchpad is kind of horrible for our purposes > (too many irrelevant fields to fill out). For features that aren't > big/controversial enough to require a spec, some projects have adopted a > 'spec-lite' process. Basically you raise a *bug* in Launchpad, give it > 'Wishlist' priority and tag it with 'spec-lite'.
I think either approach is fine and IIRC we did previously discuss the spec-lite process and agree it was acceptable for tracking smaller features for TripleO. The point is we absolutely need some way to track stuff that isn't yet landed - and I think folks probably don't care much re (Bug|Blueprint) provided it's correctly targetted. We had a very rough time at the end of Newton because $many folks showed up late with features we didn't know about and/or weren't correctly tracked, so I think a feature proposal freeze is reasonable. Given the number of BPs targetted at Ocata is already prety high I think Nov 14th probably justifiable but it is on the more conservative side relative to other projects[2]. Regarding the specs process - tbh I feel like that hasn't been working well for a while (for all the same reasons John referenced in [1]). So I've been leaning towards not requiring (or writing) specs in the majority of cases, instead often we've just linked an etherpad with notes or had a ML discussion to gain consensus on direction. (This seems pretty similar to the wiki based approach adopted by the swift team). Thanks, Steve [1] http://lists.openstack.org/pipermail/openstack-dev/2016-May/094026.html [2] https://releases.openstack.org/ocata/schedule.html __________________________________________________________________________ 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
