Excerpts from Thierry Carrez's message of 2015-08-27 11:20:05 +0200:
> Doug Hellmann wrote:
> > Excerpts from Robert Collins's message of 2015-08-19 11:04:37 +1200:
> >> Proposed data structure:
> >> - create a top level directory in each repo called release-notes
> >> - within that create a subdir
Doug Hellmann wrote:
> Excerpts from Robert Collins's message of 2015-08-19 11:04:37 +1200:
>> Proposed data structure:
>> - create a top level directory in each repo called release-notes
>> - within that create a subdirectory called changes.
>> - within the release-notes dir we place yaml files co
Excerpts from Robert Collins's message of 2015-08-19 11:04:37 +1200:
> On 18 August 2015 at 01:46, Thierry Carrez wrote:
>
> Following on from the IRC discussion about release notes.
>
> < ttx> * we want consumers of the stable branch (from random commit
> and from tagged versions) to get a vali
On 2015-08-25 10:54:38 +0100 (+0100), Dave Walker wrote:
> On 25 August 2015 at 10:28, Alexis Lee wrote:
[...]
> > Without offering an opinion either way, I'm just wondering how
> > tag-every-commit is superior to never tagging? The git SHAs already
> > uniquely identify every commit; if you want
On 25 August 2015 at 10:28, Alexis Lee wrote:
> Thierry Carrez said on Fri, Aug 21, 2015 at 04:56:37PM +0200:
>> Tag-every-commit:
>> (+) Conveys clearly that every commit is consumable
>> (-) Current tooling doesn't support this, we need to write something
>> (-) Zillions of tags will make tags r
Thierry Carrez said on Fri, Aug 21, 2015 at 04:56:37PM +0200:
> Tag-every-commit:
> (+) Conveys clearly that every commit is consumable
> (-) Current tooling doesn't support this, we need to write something
> (-) Zillions of tags will make tags ref space a bit unusable by humans
>
> Time to time t
Dave Walker wrote:
> On 21 August 2015 at 11:38, Thierry Carrez wrote:
>
>> Since then, replying to another concern about common downstream
>> reference points, we moved to "tagging everything", then replying to
>> Clark's pollution remark, to "tag from time to time". That doesn't
>> remove the n
> -Original Message-
> From: Dave Walker [mailto:em...@daviey.com]
> Sent: 21 August 2015 12:43
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] [infra] How to auto-generate stable
> release notes
>
> On
On 21 August 2015 at 11:38, Thierry Carrez wrote:
> Since then, replying to another concern about common downstream
> reference points, we moved to "tagging everything", then replying to
> Clark's pollution remark, to "tag from time to time". That doesn't
> remove the need to *conveniently* ship
Kuvaja, Erno wrote:
> [...]
> We try to have python-glanceclient and glance_store including release notes
> upon the release time. We use in tree doc/source/index.rst for ease of
> access. This provides our release notes through:
> docs.openstack.org/developer/python-glanceclient/ and you can ea
Robert Collins wrote:
> On 19 August 2015 at 21:19, Thierry Carrez wrote:
>>> Processing:
>>> 1) determine the revisions we need to generate release notes for. By
>>> default generate notes for the current minor release. (E.g. if the
>>> tree version is 1.2.3.dev4 we would generate release notes f
> -Original Message-
> From: Robert Collins [mailto:robe...@robertcollins.net]
> Sent: Wednesday, August 19, 2015 11:38 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] [infra] How to auto-generate stable
> rel
On 19 August 2015 at 21:19, Thierry Carrez wrote:
> Robert Collins wrote:
>> [...]
>> Proposed data structure:
>> - create a top level directory in each repo called release-notes
>> - within that create a subdirectory called changes.
>> - within the release-notes dir we place yaml files containing
Robert Collins wrote:
> [...]
> Proposed data structure:
> - create a top level directory in each repo called release-notes
> - within that create a subdirectory called changes.
> - within the release-notes dir we place yaml files containing the
> release note inputs.
> - within the 'changes' subdi
On 18 August 2015 at 01:46, Thierry Carrez wrote:
Following on from the IRC discussion about release notes.
< ttx> * we want consumers of the stable branch (from random commit
and from tagged versions) to get a valid release notes document
< ttx> * Some things in that document (like OSSA numbers
Excerpts from Thierry Carrez's message of 2015-08-18 10:34:35 +0200:
> Dave Walker wrote:
> > On 17 August 2015 at 15:59, Jeremy Stanley wrote:
> >> On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
> >> [...]
> >>> OSSA:
> >>> For commits that correspond to vulnerability fixes.
> >> [.
On 2015-08-18 10:34:35 +0200 (+0200), Thierry Carrez wrote:
> Dave Walker wrote:
[...]
> > Maybe this is a perfect use-case for git-notes? This means the commit
> > itself isn't touched and the non-scale git-tag space isn't wasted?
>
> It definitely seems to be the perfect match: adding notes to
Dave Walker wrote:
> On 17 August 2015 at 15:59, Jeremy Stanley wrote:
>> On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
>> [...]
>>> OSSA:
>>> For commits that correspond to vulnerability fixes.
>> [...]
>>
>> I don't think that's going to be feasible. Consider the sequence
>> with
On 17 August 2015 at 15:59, Jeremy Stanley wrote:
> On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> OSSA:
>> For commits that correspond to vulnerability fixes.
> [...]
>
> I don't think that's going to be feasible. Consider the sequence
> with a public security vulnerabili
On 2015-08-17 15:46:24 +0200 (+0200), Thierry Carrez wrote:
[...]
> OSSA:
> For commits that correspond to vulnerability fixes.
[...]
I don't think that's going to be feasible. Consider the sequence
with a public security vulnerability... often the OSSA number isn't
assigned until after one or mo
Thierry Carrez wrote:
> Doug Hellmann wrote:
>> How detailed do we want release notes to be? For example, do we need to
>> worry about supporting multiple paragraphs or ASCII art or anything like
>> that?
>
> Looking at our current release notes, they are a set of bullet points of
> a pre-determin
Doug Hellmann wrote:
> Excerpts from Robert Collins's message of 2015-08-04 06:43:48 +1200:
>> On 4 August 2015 at 02:46, Alexis Lee wrote:
>>> Whichever solution we pick - should we also adopt it on master? Naively
>>> it sounds useful to be able to generate release notes for master too.
>>> And
Perhaps the following can be used?
https://github.com/vaab/gitchangelog#gitchangelog
That does impose a commit message format, but then any kind of release
notes generated from a commit log will require some sort of standard to
be maintained (otherwise it's going to be tough to auto-generate
Excerpts from Robert Collins's message of 2015-08-04 06:43:48 +1200:
> On 4 August 2015 at 02:46, Alexis Lee wrote:
> > Thierry Carrez said on Mon, Aug 03, 2015 at 02:57:39PM +0200:
> >> 1. we can maintain a Changelog document directly in the source code.
> >> Rather than being straightly backport
On 4 August 2015 at 02:46, Alexis Lee wrote:
> Thierry Carrez said on Mon, Aug 03, 2015 at 02:57:39PM +0200:
>> 1. we can maintain a Changelog document directly in the source code.
>> Rather than being straightly backported from master, commits with
>> significant changes would be amended to addit
Thierry Carrez said on Mon, Aug 03, 2015 at 02:57:39PM +0200:
> 1. we can maintain a Changelog document directly in the source code.
> Rather than being straightly backported from master, commits with
> significant changes would be amended to additionally modify that document.
Wouldn't this cause
Hi everyone,
A month ago the stable branch team decided to move away from
synchronized stable point releases and enable continuous stable branch
delivery instead.
A side-effect of this decision is that we need to move away from a model
where we curate release notes for each stable point release,
27 matches
Mail list logo
