Open Stack

Rethinking my last email... Go with just release notes, no need for a bug.

On Thu, Feb 14, 2019, 06:46 Morgan Fainberg <morgan.fainberg at gmail.com
wrote:

> 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/de71f145/attachment.html>