What is the text that should be included in the commit messages to make
sure that it is picked up for release notes?
I'm not sure anyone tracks commit messages to create release notes.
Let's use existing DocImpact tag, I'll add check for this in the
release scripts.
But I prefer if you could
On 12/02/2014 02:31 AM, Alan Pevec wrote:
What is the text that should be included in the commit messages to make sure
that it is picked up for release notes?
I'm not sure anyone tracks commit messages to create release notes.
Let's use existing DocImpact tag, I'll add check for this in the
- Original Message -
From: Alan Pevec ape...@gmail.com
To: Jay Bryant jsbry...@electronicjungle.net, OpenStack Development
Mailing List (not for usage questions)
What is the text that should be included in the commit messages to make
sure that it is picked up for release notes?
Will the bugs created by this end up in the openstack-manuals project (which
I don't think is the right place for them in this case) or has it been set up
to create them somewhere else (or not at all) when the commits are against
the stable branches?
Docs team, how do you handle DocImpact
On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec ape...@gmail.com wrote:
Will the bugs created by this end up in the openstack-manuals project
(which I don't think is the right place for them in this case) or has it
been set up to create them somewhere else (or not at all) when the commits
are
- Original Message -
From: Anne Gentle a...@openstack.org
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
On Tue, Dec 2, 2014 at 2:59 PM, Alan Pevec ape...@gmail.com wrote:
Will the bugs created by this end up in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 16/11/14 20:17, Jay S. Bryant wrote:
All,
This is a question I have been struggling with for Cinder recently.
Where do we draw the line on backports. How do we handle config changes?
One thing for Cinder I am also considering, in
Hi,
Looking at a stable/juno cinder proposed change[0], I came across one
that introduces a new config option.
The default is a noop change for the behaviour, so no bad surprises on upgrade.
These sort of changes feel like they are outside the 'no config
changes' rule, but we have not really
On Tue, Nov 11, 2014 at 10:24:41AM +, Dave Walker wrote:
Hi,
Looking at a stable/juno cinder proposed change[0], I came across one
that introduces a new config option.
The default is a noop change for the behaviour, so no bad surprises on
upgrade.
These sort of changes feel like
Daniel P. Berrange wrote:
On Tue, Nov 11, 2014 at 10:24:41AM +, Dave Walker wrote:
Hi,
Looking at a stable/juno cinder proposed change[0], I came across one
that introduces a new config option.
The default is a noop change for the behaviour, so no bad surprises on
upgrade.
These
New config options may not change behavior (if default value preserves
behavior), they still make documentation more incomplete (doc, books,
and/or blogposts about Juno won't mention that option).
That's why we definitely need such changes described clearly in stable
release notes.
I also lean
11 matches
Mail list logo
