Open Stack

I would go for one tracking bug per cycle or we could also just lean on the
release notes instead of having a direct bug.

On Thu, Feb 14, 2019, 06:07 Colleen Murphy <colleen at gazlene.net wrote:

> On Wed, Feb 13, 2019, at 8:56 PM, Lance Bragstad wrote:
> > Over the last couple of years, our launchpad blueprints have grown
> > unruly [0] (~77 blueprints a few days ago). The majority of them were in
> > "New" status, unmaintained, and several years old (some dating back to
> > 2013). Even though we've been using specifications [1] for several
> > years, people still get confused when they see conflicting or inaccurate
> > blueprints. After another person tripped over a duplicate blueprint this
> > week, cmurphy, vishakha, and I decided to devote some attention to it.
> > We tracked the work in an etherpad [2] - so we can still find links to
> > things.
> >
> > First, if you are the owner of a blueprint that was marked as
> > "Obsolete", you should see a comment on the whiteboard that includes a
> > reason or justification. If you'd like to continue the discussion about
> > your feature request, please open a specification against the
> > openstack/keystone-specs repository instead. For historical context,
> > when we converted to specifications, we were only supposed to create
> > blueprints for tracking the work after the specification was merged.
> > Unfortunately, I don't think this process was ever written down, which
> > I'm sure attributed to blueprint bloat over the years.
> >
> > Second, if you track work regularly using blueprints or plan on
> > delivering something for Stein, please make sure your blueprint in
> > Launchpad is approved and tracked to the appropriate release (this
> > should already be done, but feel free to double check). The team doesn't
> > plan on switching processes for feature tracking mid-release. Instead,
> > we're going to continue tracking feature work with launchpad blueprints
> > for the remainder of Stein. Currently, the team is leaning heavily
> > towards using RFE bug reports for new feature work, which we can easily
> > switch to in Train. The main reason for this switch is that bug comments
> > are immutable with better timestamps while blueprint whiteboards are
> > editable to anyone and not timestamped very well. We already have
> > tooling in place to update bug reports based on commit messages and that
> > will continue to work for RFE bug reports.
> >
> > Third, any existing blueprints that aren't targeted for Stein but are
> > good ideas, should be converted to RFE bug reports. All context from the
> > blueprint will need to be ported to the bug report. After a sufficient
> > RFE bug report is opened, the blueprint should be marked as "Superseded"
> > or "Obsolete" *with* a link to the newly opened bug. While this is
> > tedious, there aren't nearly as many blueprints open now as there were a
> > couple of days ago. If you're interested in assisting with this effort,
> > let me know.
> >
> > Fourth, after moving non-Stein blueprints to RFE bugs, only Stein
> > related blueprints should be open in launchpad. Once Stein is released,
> > we'll go ahead disable keystone blueprints.
> >
> > Finally, we need to overhaul a portion of our contributor guide to
> > include information around this process. The goal should be to make that
> > documentation clear enough that we don't have this issue again. I plan
> > on getting something up for review soon, but I don't have anything
> > currently, so if someone is interested in taking a shot at writing this
> > document, please feel free to do so. Morgan has a patch up to replace
> > blueprint usage with RFE bugs in the specification template [3].
> >
> > We can air out any comments, questions, or concerns here in the thread.
>
> What should we do about tracking "deprecated-as-of-*" and
> "removed-as-of-*" work? I never liked how this was done with blueprints but
> I'm not sure how we would do it with bugs. One tracking bug for all
> deprecated things in a cycle? One bug for each? A Trello/Storyboard board
> or etherpad? Do we even need to track it with an external tool - perhaps we
> can just keep a running list in a release note that we add to over the
> cycle?
>
> Thanks for tackling this cleanup work.
>
> >
> > Thanks,
> >
> > Lance
> >
> > [0] https://blueprints.launchpad.net/keystone
> > [1] http://specs.openstack.org/openstack/keystone-specs/
> > [2] https://etherpad.openstack.org/p/keystone-blueprint-cleanup
> > [3] https://review.openstack.org/#/c/625282/
> > Email had 1 attachment:
> > + signature.asc
> >   1k (application/pgp-signature)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190214/5b607993/attachment-0001.html>