[dev][keystone] Launchpad blueprint reckoning
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. 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/
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)
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@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)
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@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@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)
On 2/14/19 5:47 AM, Morgan Fainberg wrote:
Rethinking my last email... Go with just release notes, no need for a bug.
The only thing we lose with this would be a place to see every commit that deprecated or removed something in a release (short of doing a git blame on the release note). We could still do this with bugs and we could drive the tracking with Partial-Bug in each commit message. We need to make sure to formally close the bug however at the end of the release if we don't close it with a commit using Closes-Bug. In my experience, we rarely stage all these commits at once. They're usually proposed haphazardly throughout the release as people have cycles.
On Thu, Feb 14, 2019, 06:46 Morgan Fainberg <morgan.fainberg@gmail.com <mailto:morgan.fainberg@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@gazlene.net <mailto:colleen@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?
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.
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)
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. On Thu, Feb 14, 2019, 10:28 Lance Bragstad <lbragstad@gmail.com wrote:
On 2/14/19 5:47 AM, Morgan Fainberg wrote:
Rethinking my last email... Go with just release notes, no need for a bug.
The only thing we lose with this would be a place to see every commit that deprecated or removed something in a release (short of doing a git blame on the release note). We could still do this with bugs and we could drive the tracking with Partial-Bug in each commit message. We need to make sure to formally close the bug however at the end of the release if we don't close it with a commit using Closes-Bug. In my experience, we rarely stage all these commits at once. They're usually proposed haphazardly throughout the release as people have cycles.
On Thu, Feb 14, 2019, 06:46 Morgan Fainberg <morgan.fainberg@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@gazlene.net 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
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
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
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
On Wed, Feb 13, 2019, at 8:56 PM, Lance Bragstad wrote: this that the 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?
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.
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)
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@gmail.com wrote:
On Thu, Feb 14, 2019, 06:07 Colleen Murphy <colleen@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
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@gmail.com wrote:
On Thu, Feb 14, 2019, 06:07 Colleen Murphy <colleen@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
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@gmail.com wrote:
On Thu, Feb 14, 2019, 06:07 Colleen Murphy <colleen@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
participants (3)
-
Colleen Murphy
-
Lance Bragstad
-
Morgan Fainberg