Open Stack

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 --------------
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/20190214/0ffecb21/attachment.sig>