[openstack-dev] [TripleO] spec-lite process for tripleo
Hi All, We briefly discussed feature tracking in this weeks tripleo meeting. I would like to provide a way for downstream consumers (and ourselves) to track new features as they get implemented. The main things that came out of the discussion is that people liked the spec-lite process that the glance team are using. I'm proposing we would start to use the same process, essentially small features that don't warrant a blueprint would instead have a wishlist bug opened against them and get marked with the spec-lite tag. This bug could then be referenced in the commit messages. For larger features blueprints can still be used. I think the process documented by glance[1] is a good model to follow so go read that and see what you think The general feeling at the meeting was +1 to doing this[2] so I hope we can soon start enforcing it, assuming people are still happy to proceed? thanks, Derek. [1] http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite [2] http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On Wed, 2016-01-27 at 16:21 +, Derek Higgins wrote: > Hi All, > > We briefly discussed feature tracking in this weeks tripleo meeting. > I > would like to provide a way for downstream consumers (and ourselves) > to > track new features as they get implemented. The main things that > came > out of the discussion is that people liked the spec-lite process > that > the glance team are using. > > I'm proposing we would start to use the same process, essentially > small > features that don't warrant a blueprint would instead have a > wishlist > bug opened against them and get marked with the spec-lite tag. This > bug > could then be referenced in the commit messages. For larger features > blueprints can still be used. I think the process documented by > glance[1] is a good model to follow so go read that and see what you > think > > The general feeling at the meeting was +1 to doing this[2] so I hope > we > can soon start enforcing it, assuming people are still happy to > proceed? +1 from me > > thanks, > Derek. > > [1] > http://docs.openstack.org/developer/glance/contributing/blueprints.ht > ml#glance-spec-lite > [2] > http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01- > 26-14.02.log.html > > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On 01/27/2016 09:21 AM, Derek Higgins wrote: > Hi All, > > We briefly discussed feature tracking in this weeks tripleo meeting. I > would like to provide a way for downstream consumers (and ourselves) to > track new features as they get implemented. The main things that came > out of the discussion is that people liked the spec-lite process that > the glance team are using. > > I'm proposing we would start to use the same process, essentially small > features that don't warrant a blueprint would instead have a wishlist > bug opened against them and get marked with the spec-lite tag. This bug > could then be referenced in the commit messages. For larger features > blueprints can still be used. I think the process documented by > glance[1] is a good model to follow so go read that and see what you think > > The general feeling at the meeting was +1 to doing this[2] so I hope we > can soon start enforcing it, assuming people are still happy to proceed? > > thanks, > Derek. > > [1] > http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite > > [2] > http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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 I guess my only thought would be to make the bug/rfe fairly descriptive so we don't have to go tracking down whoever reported it for more details. Maybe just some light rules about age and responsiveness so we can quickly retire those bugs/rfes that people aren't really paying attention to. -J -- Jason E. Rist Senior Software Engineer OpenStack Infrastructure Integration Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/twitter: knowncitizen __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On Wed, Jan 27, 2016 at 08:01:31PM -0700, Jason Rist wrote: > On 01/27/2016 09:21 AM, Derek Higgins wrote: > > Hi All, > > > > We briefly discussed feature tracking in this weeks tripleo meeting. I > > would like to provide a way for downstream consumers (and ourselves) to > > track new features as they get implemented. The main things that came > > out of the discussion is that people liked the spec-lite process that > > the glance team are using. > > > > I'm proposing we would start to use the same process, essentially small > > features that don't warrant a blueprint would instead have a wishlist > > bug opened against them and get marked with the spec-lite tag. This bug > > could then be referenced in the commit messages. For larger features > > blueprints can still be used. I think the process documented by > > glance[1] is a good model to follow so go read that and see what you think > > > > The general feeling at the meeting was +1 to doing this[2] so I hope we > > can soon start enforcing it, assuming people are still happy to proceed? > > > > thanks, > > Derek. > > > > [1] > > http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite > > > > [2] > > http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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 > > I guess my only thought would be to make the bug/rfe fairly descriptive > so we don't have to go tracking down whoever reported it for more > details. Maybe just some light rules about age and responsiveness so we > can quickly retire those bugs/rfes that people aren't really paying > attention to. Agreed, I'd expect those cores triaging the spec-lite bugs to mark them incomplete if there's insufficient detail (although this isn't explicitly mentioned in the glance process[1], it seems well aligned with the existing bug workflow, so perhaps it's implicit). I'm not sure on the workflow for retiring RFE bugs - in general I'd expect RFE bugs to *not* be routinely retired just because they're not implemented , but they could be marked incomplete or invalid if they look obsolete or otherwise no longer relevant and allowed to expire that way. [1] http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On 27 January 2016 at 16:21, Derek Higgins wrote: > Hi All, > > We briefly discussed feature tracking in this weeks tripleo meeting. I > would like to provide a way for downstream consumers (and ourselves) to > track new features as they get implemented. The main things that came out > of the discussion is that people liked the spec-lite process that the > glance team are using. > > I'm proposing we would start to use the same process, essentially small > features that don't warrant a blueprint would instead have a wishlist bug > opened against them and get marked with the spec-lite tag. This bug could > then be referenced in the commit messages. For larger features blueprints > can still be used. I think the process documented by glance[1] is a good > model to follow so go read that and see what you think > > The general feeling at the meeting was +1 to doing this[2] so I hope we > can soon start enforcing it, assuming people are still happy to proceed? > +1 sounds good. > > thanks, > Derek. > > [1] > http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite > [2] > http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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 > __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
Bringing an old topic on the table. We might have noticed: 1. Some tripleo-specs take huge amount of time before getting merged (or even reviewed). We have been asking folks to review them every week but unfortunately they don't get much attraction (# of core reviewers versus # of folks actually reviewing specs). 2. Some folks spend a lot of time writing TripleO specs and wait for feedback before starting some implementation (like proof of concept). Because TripleO like innovation and also moving fast, I think it's time to bring the tripleo-specs topic on the table: 1. If you have an idea, don't feel obliged to write a specs. Create a blueprint on launchpad, announce it on the ML and start writing code (can be real implementation or just a simple PoC). Feedback will be given in the classic code review. 2. If you still want to write a spec, please make it readable and communicate about it. If your spec is 900 lines long and not announced anywhere, there is an high change that it will never been reviewed. 3. If you still want to write a spec, please don't stop your work after the specs. Please engage some PoC and prototypes to get feedback directly on the implementation. I think these proposals are realistic with the regard of how TripleO project works now. Please bring any feedback or question. Thanks, On Fri, Jan 29, 2016 at 3:26 AM, Dougal Matthews wrote: > > > On 27 January 2016 at 16:21, Derek Higgins wrote: >> >> Hi All, >> >> We briefly discussed feature tracking in this weeks tripleo meeting. I >> would like to provide a way for downstream consumers (and ourselves) to >> track new features as they get implemented. The main things that came out of >> the discussion is that people liked the spec-lite process that the glance >> team are using. >> >> I'm proposing we would start to use the same process, essentially small >> features that don't warrant a blueprint would instead have a wishlist bug >> opened against them and get marked with the spec-lite tag. This bug could >> then be referenced in the commit messages. For larger features blueprints >> can still be used. I think the process documented by glance[1] is a good >> model to follow so go read that and see what you think >> >> The general feeling at the meeting was +1 to doing this[2] so I hope we >> can soon start enforcing it, assuming people are still happy to proceed? > > > +1 sounds good. > >> >> >> thanks, >> Derek. >> >> [1] >> http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite >> [2] >> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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 > > > > __ > 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 > -- Emilien Macchi __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On Tue, Mar 28, 2017 at 12:09:43PM -0400, Emilien Macchi wrote: > Bringing an old topic on the table. > > We might have noticed: > > 1. Some tripleo-specs take huge amount of time before getting merged > (or even reviewed). We have been asking folks to review them every > week but unfortunately they don't get much attraction (# of core > reviewers versus # of folks actually reviewing specs). > 2. Some folks spend a lot of time writing TripleO specs and wait for > feedback before starting some implementation (like proof of concept). > > Because TripleO like innovation and also moving fast, I think it's > time to bring the tripleo-specs topic on the table: > > 1. If you have an idea, don't feel obliged to write a specs. Create a > blueprint on launchpad, announce it on the ML and start writing code > (can be real implementation or just a simple PoC). Feedback will be > given in the classic code review. +1 I for one have been burnt more than once spending significant time on a spec only to find our collective understanding changes after actual code exists. For things related to interfaces a spec can be helpful, but I think it's often faster to raise a blueprint with relatively few details and work on a prototype that clarifies the direction, particularly if such code patches can be generated fairly quickly. > 2. If you still want to write a spec, please make it readable and > communicate about it. If your spec is 900 lines long and not announced > anywhere, there is an high change that it will never been reviewed. I agree - I think a common mistake is to get bogged down in implementation detail when writing (and reviewing) a spec, so I definitely favor a clearly expressed summary of the problem, an overview of the proposed direction (including any major interface changes), and clarification of any user/dev visible impact. None of this requires much focus at all on the details of the implementation IMO. Thanks for raising this Emilien, hopefully this will help us move a little faster in future! Steve __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On Wed, Mar 29, 2017 at 10:42 PM, Steven Hardy wrote: > On Tue, Mar 28, 2017 at 12:09:43PM -0400, Emilien Macchi wrote: > > Bringing an old topic on the table. > > > > We might have noticed: > > > > 1. Some tripleo-specs take huge amount of time before getting merged > > (or even reviewed). We have been asking folks to review them every > > week but unfortunately they don't get much attraction (# of core > > reviewers versus # of folks actually reviewing specs). > > 2. Some folks spend a lot of time writing TripleO specs and wait for > > feedback before starting some implementation (like proof of concept). > > > > Because TripleO like innovation and also moving fast, I think it's > > time to bring the tripleo-specs topic on the table: > > > > 1. If you have an idea, don't feel obliged to write a specs. Create a > > blueprint on launchpad, announce it on the ML and start writing code > > (can be real implementation or just a simple PoC). Feedback will be > > given in the classic code review. > > +1 I for one have been burnt more than once spending significant time > on a spec only to find our collective understanding changes after actual > code exists. > > For things related to interfaces a spec can be helpful, but I think it's > often faster to raise a blueprint with relatively few details and work on a > prototype that clarifies the direction, particularly if such code patches > can be generated fairly quickly. > > > 2. If you still want to write a spec, please make it readable and > > communicate about it. If your spec is 900 lines long and not announced > > anywhere, there is an high change that it will never been reviewed. > > I agree - I think a common mistake is to get bogged down in implementation > detail when writing (and reviewing) a spec, so I definitely favor a > clearly expressed summary of the problem, an overview of the proposed > direction (including any major interface changes), and clarification of any > user/dev visible impact. None of this requires much focus at all on the > details of the implementation IMO. > > Thanks for raising this Emilien, hopefully this will help us move a little > faster in future! > > Steve Having wrote a few specs this cycle, its good to read both your views, as I was becoming concerned about spending a fair amount of time on answering comments, correcting grammar nits, clarifying misunderstands etc, instead of getting code I already had staged up for review. __ 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
Re: [openstack-dev] [TripleO] spec-lite process for tripleo
On 03/28/2017 11:09 AM, Emilien Macchi wrote: Bringing an old topic on the table. We might have noticed: 1. Some tripleo-specs take huge amount of time before getting merged (or even reviewed). We have been asking folks to review them every week but unfortunately they don't get much attraction (# of core reviewers versus # of folks actually reviewing specs). To me, this is an indication that cores are overloaded already (or apathetic about software design, but I'm going to be optimistic here). Adding more features for them to review isn't going to help that. :-/ 2. Some folks spend a lot of time writing TripleO specs and wait for feedback before starting some implementation (like proof of concept). Because TripleO like innovation and also moving fast, I think it's time to bring the tripleo-specs topic on the table: 1. If you have an idea, don't feel obliged to write a specs. Create a blueprint on launchpad, announce it on the ML and start writing code (can be real implementation or just a simple PoC). Feedback will be given in the classic code review. I hate that we've come to this (and yes, hate is a strong word. That's not an accident). For minor features that only require a single or couple of patches, sure. But one of the advantages of specs is that they provide an explicit list of things that the submitter needs to think about (user interaction, documentation, testing, security, etc.). This is all stuff that needs to be considered whether we use full specs or not, unless the feature is so small that none of them apply, which is a good indication that a spec is not required anyway. That said, I do recognize the problems we've had with specs. I wonder if, regardless of whether we do a spec-lite thing, we need to revisit https://specs.openstack.org/openstack/tripleo-specs/specs/policy/spec-review.html and streamline it a lot. Stronger emphasis on not nit-picking spelling and grammar, maybe better guidelines about the expected level of detail of a spec and how deeply (or not) they should be reviewed. Also worth noting is that a few of us have been contacted privately asking for tips on writing specs. It might be worth writing something up from the other side to help committers write good, reviewable specs. It wouldn't have to be elaborate, but some guidelines might make everyone's lives easier. 2. If you still want to write a spec, please make it readable and communicate about it. If your spec is 900 lines long and not announced anywhere, there is an high change that it will never been reviewed. +1. It seems like a lot of the problems with specs stem from the fact that they get too deep into the implementation details and it just takes too long to review. Also, as Steve mentioned, it's hard to know all the implementation details up front. The spec should just be setting the direction and allowing people to raise concerns with same. 3. If you still want to write a spec, please don't stop your work after the specs. Please engage some PoC and prototypes to get feedback directly on the implementation. Having a PoC to look at while reviewing a spec can be super helpful. I would caution about getting too invested in a specific direction in case the review feedback requires major changes, but I'm +1 overall on this. I think these proposals are realistic with the regard of how TripleO project works now. Please bring any feedback or question. Thanks, On Fri, Jan 29, 2016 at 3:26 AM, Dougal Matthews wrote: On 27 January 2016 at 16:21, Derek Higgins wrote: Hi All, We briefly discussed feature tracking in this weeks tripleo meeting. I would like to provide a way for downstream consumers (and ourselves) to track new features as they get implemented. The main things that came out of the discussion is that people liked the spec-lite process that the glance team are using. I'm proposing we would start to use the same process, essentially small features that don't warrant a blueprint would instead have a wishlist bug opened against them and get marked with the spec-lite tag. This bug could then be referenced in the commit messages. For larger features blueprints can still be used. I think the process documented by glance[1] is a good model to follow so go read that and see what you think The general feeling at the meeting was +1 to doing this[2] so I hope we can soon start enforcing it, assuming people are still happy to proceed? +1 sounds good. thanks, Derek. [1] http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite [2] http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.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 ___
