Open Stack

Updating this based on everything that's happened in the last day or two.

At this point, every blueprint that *isn't* targeted to Stein has been
ported to an RFE bug report [0]. Each one should contain links to any
relevant information that lived in the blueprint. Only stein-specific
blueprints are left [1], which will be completed at the end of this
release. There is a patch up to the contributor guide that describes the
process for requesting new features [2]. Please have a look and let me
know if anything is missing. The etherpad should be completely
up-to-date [3] with pointers to all blueprints we touched, in case you
want to see why we classified a particular blueprint a certain way.

Most of the RFE bugs still require some investigation, but we can use
our usual process for validating or invalidating them, with
justification in comments. Don't hesitate to ask if you have questions
about this work.

[0] https://bugs.launchpad.net/keystone/+bugs?field.tag=rfe
[1] https://blueprints.launchpad.net/keystone
[2] https://review.openstack.org/#/c/637311/
[3] https://etherpad.openstack.org/p/keystone-blueprint-cleanup

On 2/14/19 10:24 AM, Lance Bragstad wrote:
> Sounds good to me. We should probably find a home for this information.
> Somewhere in our contributor guide, perhaps?
>
> On 2/14/19 10:00 AM, Colleen Murphy wrote:
>> On Thu, Feb 14, 2019, at 4:50 PM, Morgan Fainberg wrote:
>>> I think a `git blame` or history of the deprecated release note is nice, it
>>> centralizes out tracking of removed/deprecated items to the git log itself
>>> rather than some external tracker that may or may not be available forever.
>>> This way as long as the git repo is maintained, our tracking for a given
>>> release is also tracked.
>>>
>>> Specs and bugs are nice, but the deprecated bug # for a given release is
>>> fairly opaque. Other bugs might have more context in the bug, but if it's
>>> just a list of commits, I don't see a huge win.
>> I'm also +1 on just keeping it in the release notes.
>>
>>> On Thu, Feb 14, 2019, 10:28 Lance Bragstad <lbragstad at gmail.com wrote:
>>>
>>>>> On Thu, Feb 14, 2019, 06:07 Colleen Murphy <colleen at gazlene.net wrote:
>>>>>> 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?
>>>>>>
>>>> I agree. The solution that is jumping out at me is to track one bug for
>>>> deprecated things and one for removed things per release, so similar to
>>>> what we do now with blueprints. We would have to make sure we tag commits
>>>> properly, so they are all tracked in the bug report. Creating a bug for
>>>> everything that is deprecated or removed would be nice for capturing
>>>> specific details, but it also feels like it will introduce more churn to
>>>> the process.
>>>>
>>>> I guess I'm assuming there are users that like to read every commit that
>>>> has deprecated something or removed something in a release. If we don't
>>>> need to operate under that assumption, then a release note would do just
>>>> fine and I'm all for simplifying the process.
>>>>
>> I think the reason we have release notes is so people *don't* have to read every commit.
>>
>> Colleen
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190215/88aa6f8e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190215/88aa6f8e/attachment-0001.sig>