Open Stack

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