On Jun 16, 2015, at 14:56, Thomas Goirand z...@debian.org wrote:
On 06/16/2015 12:06 PM, Thierry Carrez wrote:
It also removes the stupid encouragement to use all components from the
same date. With everything tagged at the same date, you kinda send the
message that those various things
Ihar Hrachyshka wrote:
On 06/17/2015 05:40 PM, Douglas Mendizábal wrote:
I tend to agree with Thomas that plan D is not ideal. For one, it
prevents changes to the stable branch that span multiple CRs, since
a two patch change would generate two tags and there would be no
clear indication
On 17 June 2015 at 17:19, Thierry Carrez thie...@openstack.org wrote:
Ihar Hrachyshka wrote:
On 06/17/2015 05:40 PM, Douglas Mendizábal wrote:
I tend to agree with Thomas that plan D is not ideal. For one, it
prevents changes to the stable branch that span multiple CRs, since
a two patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I tend to agree with Thomas that plan D is not ideal. For one, it
prevents changes to the stable branch that span multiple CRs, since a
two patch change would generate two tags and there would be no clear
indication that the first patch should not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/17/2015 05:40 PM, Douglas Mendizábal wrote:
I tend to agree with Thomas that plan D is not ideal. For one, it
prevents changes to the stable branch that span multiple CRs, since
a two patch change would generate two tags and there would
On 06/16/2015 12:06 PM, Thierry Carrez wrote:
It also removes the stupid encouragement to use all components from the
same date. With everything tagged at the same date, you kinda send the
message that those various things should be used together. With
everything tagged separately, you send te
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/15/2015 11:24 PM, Thomas Goirand wrote:
On 06/15/2015 05:19 PM, Ian Cordasco wrote:
On 6/15/15, 09:24, Thomas Goirand z...@debian.org wrote:
On 06/08/2015 01:55 PM, Kuvaja, Erno wrote:
One thing I like about plan D is that it would give
Thomas Goirand wrote:
On 06/10/2015 03:46 PM, Thierry Carrez wrote:
So we could do what you're asking (option B) for Kilo stable releases,
but I think it's not really a viable option for stable/liberty onward.
I fail to understand how version numbers are related to doing
synchronized point
On 06/08/2015 01:55 PM, Kuvaja, Erno wrote:
One thing I like about plan D
is that it would give also indicator how much the stable branch has moved in
each individual project.
The only indication you will get is how many patches it has. I fail to
see how this is valuable information. No info
On 06/10/2015 03:46 PM, Thierry Carrez wrote:
The main issue with B is that it doesn't work well once server component
versions start to diverge, which will be the case starting with Liberty.
Review that policy then.
We already couldn't (with Swift using separate versioning), but we worked
On 06/10/2015 11:27 AM, Dave Walker wrote:
On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
On 06/05/2015 02:46 PM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference
On 6/15/15, 09:24, Thomas Goirand z...@debian.org wrote:
On 06/08/2015 01:55 PM, Kuvaja, Erno wrote:
One thing I like about plan D
is that it would give also indicator how much the stable branch has
moved in
each individual project.
The only indication you will get is how many patches it has.
On 06/15/2015 05:19 PM, Ian Cordasco wrote:
On 6/15/15, 09:24, Thomas Goirand z...@debian.org wrote:
On 06/08/2015 01:55 PM, Kuvaja, Erno wrote:
One thing I like about plan D
is that it would give also indicator how much the stable branch has
moved in
each individual project.
The only
On 6/15/15, 16:24, Thomas Goirand z...@debian.org wrote:
On 06/15/2015 05:19 PM, Ian Cordasco wrote:
On 6/15/15, 09:24, Thomas Goirand z...@debian.org wrote:
On 06/08/2015 01:55 PM, Kuvaja, Erno wrote:
One thing I like about plan D
is that it would give also indicator how much the stable
The only issue is having a correct version number. Swift could well
iterate after 20151, for example doing 20151.1 then 20151.2, etc.
Swift never had coordinated YEAR.N versions,
https://wiki.openstack.org/wiki/Swift/version_map
and they never released a version from their stable/* branches.
On 06/09/2015 04:54 PM, Jeremy Stanley wrote:
On 2015-06-09 10:55:55 +0200 (+0200), Thomas Goirand wrote:
[...]
That's far from being in place. Also, while we are removing point
releases, and support for Icehouse, we still don't have a common private
Gerrit for security, which we've been told
On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
On 06/05/2015 02:46 PM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push
On 06/05/2015 02:46 PM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from time to time.
(-)
Dave Walker wrote:
On 10 June 2015 at 09:53, Thomas Goirand z...@debian.org wrote:
What would be your preferred option ?
I see no point of doing D. I already don't use tarballs, and those who
do could as well switch to generating them (how hard is it to run
python setup.py sdist or git
On 10 June 2015 at 17:06, Fox, Kevin M kevin@pnnl.gov wrote:
So... as an op, without release notes, how am I supposed to figure out the
proper upgrade procedure's when you often have to lockstep, in the right
order, nova+neutron upgrades (or other project combinations)?
Thanks,
Kevin
...@debian.org]
Sent: Wednesday, June 10, 2015 1:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [stable] No longer doing stable point
releases
On 06/05/2015 02:46 PM, Thierry Carrez wrote:
So.. summarizing the various options again
Hi Dave,
Ah, I did misunderstand. Thanks for clarifying.
Kevin
From: Dave Walker [em...@daviey.com]
Sent: Wednesday, June 10, 2015 9:32 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [stable
On 06/08/2015 12:46 AM, Alan Pevec wrote:
How do you check if project X in version n works with project Y in
version m, using this non-scheduled point release free for all model?
That was an illusion of point releases, as Thierry said there wasn't
significantly more testing and I don't
On 06/07/2015 06:13 PM, Ian Cordasco wrote:
If you consider *every* commit to be a release, then your life becomes
easier.
What does this mean? Am I supposed to upload a patched release to Debian
every day? I suppose I didn't understand you correctly here.
This discussion is about stable
On 06/01/2015 01:20 PM, Dimitri John Ledkov wrote:
On 29 May 2015 at 14:41, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates
On 06/08/2015 12:25 AM, Alan Pevec wrote:
and *Plan D* would be to start doing automatic per-project
micro-versions on each commit: e.g. 2015.1.N where N is increased on
each commit.
How do you gpg sign these tags? I hope the solution isn't to store a key
in infra without a passphrase.
On 06/07/2015 05:57 PM, Ian Cordasco wrote:
On 6/7/15, 03:41, Thomas Goirand z...@debian.org wrote:
On 05/29/2015 09:23 PM, Ian Cordasco wrote:
Could you explain this as well? Do you mean fragmentation between what
distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1
and
On 06/08/2015 05:42 PM, Jeremy Stanley wrote:
On 2015-06-07 10:55:29 +0200 (+0200), Thomas Goirand wrote:
How do you gpg sign these tags? I hope the solution isn't to store
a key in infra without a passphrase.
How does, e.g., Debian sign its Release file for
jessie-proposed-updates? I hope
On 06/08/2015 06:10 PM, Jeremy Stanley wrote:
On 2015-06-08 16:53:21 +0100 (+0100), Dave Walker wrote:
This breaks the desire of wanting to have a shared version scheme if
consumers add their own local patches via git. This works fine for
consumers that do not use git for handling their local
On 2015-06-09 10:55:55 +0200 (+0200), Thomas Goirand wrote:
[...]
That's far from being in place. Also, while we are removing point
releases, and support for Icehouse, we still don't have a common private
Gerrit for security, which we've been told about 2 years ago.
Removing collaboration
On 9 June 2015 at 03:48, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-06-08 10:54:32 +1200 (+1200), Robert Collins wrote:
On 8 June 2015 at 10:14, Alan Pevec ape...@gmail.com wrote:
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow
-Original Message-
From: Thierry Carrez [mailto:thie...@openstack.org]
Sent: Friday, June 05, 2015 1:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] [stable] No longer doing stable point
releases
So.. summarizing the various options again:
Plan
On 2015-06-07 10:55:29 +0200 (+0200), Thomas Goirand wrote:
How do you gpg sign these tags? I hope the solution isn't to store
a key in infra without a passphrase.
How does, e.g., Debian sign its Release file for
jessie-proposed-updates? I hope the solution isn't to store the
ftp-master
On 2015-06-08 00:25:47 +0200 (+0200), Alan Pevec wrote:
BTW there's an issue re. verification that
https://tarballs.openstack.org/ is using cert for
security.openstack.org but should be easily fixed by infra.
Uh, nope. Try again. You're redirected to security.openstack.org if
you accept that
On 2015-06-08 10:54:32 +1200 (+1200), Robert Collins wrote:
On 8 June 2015 at 10:14, Alan Pevec ape...@gmail.com wrote:
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
SemVer (http://semver.org/)
On 2015-06-08 16:53:21 +0100 (+0100), Dave Walker wrote:
This breaks the desire of wanting to have a shared version scheme if
consumers add their own local patches via git. This works fine for
consumers that do not use git for handling their local patches, but
does not support the model of
On 8 June 2015 at 16:48, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-06-08 10:54:32 +1200 (+1200), Robert Collins wrote:
On 8 June 2015 at 10:14, Alan Pevec ape...@gmail.com wrote:
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow
On 6/7/15, 03:41, Thomas Goirand z...@debian.org wrote:
On 05/29/2015 09:23 PM, Ian Cordasco wrote:
Could you explain this as well? Do you mean fragmentation between what
distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1
and
RHEL is at SHA2. I'm not entirely certain that's
On 6/7/15, 03:47, Thomas Goirand z...@debian.org wrote:
On 05/29/2015 09:36 PM, Dave Walker wrote:
Responses inline.
On 29 May 2015 6:15 pm, Haïkel hgue...@fedoraproject.org
mailto:hgue...@fedoraproject.org wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org
On 8 June 2015 at 10:14, Alan Pevec ape...@gmail.com wrote:
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
SemVer (http://semver.org/)
Right, so semver compatible versioning on stable/kilo would be
2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
SemVer (http://semver.org/)
Right, so semver compatible versioning on stable/kilo would be 2015.1.N
but PBR doesn't support that.
If we want to be pedantic
Robert Collins wrote:
On 6 June 2015 at 08:53, Joshua Harlowharlo...@outlook.com wrote:
Hopefully it's somewhat obvious to folks that altering the PBR version
schema (yet again), breaks *all the people* from using it in a reliable
manner, and if the goal of PBR is to bring reasonableness, well
and *Plan D* would be to start doing automatic per-project
micro-versions on each commit: e.g. 2015.1.N where N is increased on
each commit.
How do you gpg sign these tags? I hope the solution isn't to store a key
in infra without a passphrase.
Plan D doesn't include git tags, 2015.1.N
On 8 June 2015 at 10:45, Robert Collins robe...@robertcollins.net wrote:
You'll also note that according to PEP 440, (as Jeremy pointed out) .postN
is meant for non-code changes. If we want to be pedantic about the version
numbers generated by PBR (at the gate, in tox, etc.), it should be
On 05/29/2015 07:14 PM, Haïkel wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects
On 05/29/2015 09:23 PM, Ian Cordasco wrote:
Could you explain this as well? Do you mean fragmentation between what
distros are offering? In other words, Ubuntu is packaging Kilo @ SHA1 and
RHEL is at SHA2. I'm not entirely certain that's a bad thing. That seems
to give the packagers more
On 05/29/2015 09:36 PM, Dave Walker wrote:
Responses inline.
On 29 May 2015 6:15 pm, Haïkel hgue...@fedoraproject.org
mailto:hgue...@fedoraproject.org wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org
mailto:thie...@openstack.org:
Hi everyone,
TL;DR:
- We
On 06/01/2015 10:40 AM, Ihar Hrachyshka wrote:
No time synchronization between projects, no freeze dates, nothing, just
SemVer compatible version bumps e.g. once per two weeks or month.
Would it fix your problem?
How do you check if project X in version n works with project Y in
version m,
On 06/01/2015 05:32 PM, Alan Pevec wrote:
*Plan C* would be to just let projects tag stable point releases from
time to time. That would solve all the original stated problems. And
that would solve objections 2 and 3, which I think are the most valid ones.
and *Plan D* would be to start
On 6 June 2015 at 08:53, Joshua Harlow harlo...@outlook.com wrote:
Hopefully it's somewhat obvious to folks that altering the PBR version
schema (yet again), breaks *all the people* from using it in a reliable
manner, and if the goal of PBR is to bring reasonableness, well changing it
in a way
On 7 June 2015 at 05:08, Ian Cordasco ian.corda...@rackspace.com wrote:
On 6/6/15, 02:03, Alan Pevec ape...@gmail.com wrote:
2015-06-05 15:16 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote:
[...]
I was wondering if we could switch to
How do you check if project X in version n works with project Y in
version m, using this non-scheduled point release free for all model?
That was an illusion of point releases, as Thierry said there wasn't
significantly more testing and I don't remember any testing reports
during stable freeze
On 2015-06-06 09:03:13 +0200 (+0200), Alan Pevec wrote:
2015-06-05 15:16 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
[...]
I think the recommendation from the PyPI maintainers is to not use
.postN suffixes since they are intended to indicate non-code
changes.
So that's PBR bug then and
On 6/6/15, 02:03, Alan Pevec ape...@gmail.com wrote:
2015-06-05 15:16 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote:
[...]
I was wondering if we could switch to post-versioning on stable
branches, and basically generate:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from time to time.
(-) Encourages to continue using same version across the
Jeremy Stanley wrote:
On 2015-06-01 15:57:17 + (+), Jeremy Stanley wrote:
[...]
The biggest hurdle is that we'd need a separate upload job name
for those since the current version of Zuul lacks a way to run a
particular job for different branches in different pipelines (we'd
want to
On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from
On 2015-06-05 14:56:30 +0200 (+0200), Thierry Carrez wrote:
[...]
I was wondering if we could switch to post-versioning on stable
branches, and basically generate:
2015.1.0.post38
[...]
I think the recommendation from the PyPI maintainers is to not use
.postN suffixes since they are intended
Daniel P. Berrange wrote:
On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from time to time.
(-)
On 06/05/2015 07:46 AM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from time to time.
(-)
If the downsteam consumer has their own extra patches ontop of the
stable branch, then it seems D is even less useful than A.
It is not - downstream (speaking for RDO) I would keep Version:
2015.1.N where N is stable patch# so that we have a common reference
point with other distros.
Our
On 06/05/2015 05:46 AM, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across supported projects from time to time.
(-)
Excerpts from Thierry Carrez's message of 2015-06-05 05:46:07 -0700:
So.. summarizing the various options again:
Thanks for the excellent summary Thierry
Plan C
Let projects randomly tag point releases whenever
(-) Still a bit costly in terms of herding cats
I feel like plan C is the
Daniel P. Berrange wrote:
On Fri, Jun 05, 2015 at 02:46:07PM +0200, Thierry Carrez wrote:
So.. summarizing the various options again:
Plan A
Just drop stable point releases.
(-) No more release notes
(-) Lack of reference points to compare installations
Plan B
Push date-based tags across
On 06/05/2015 09:34 AM, Alan Pevec wrote:
If the downsteam consumer has their own extra patches ontop of the
stable branch, then it seems D is even less useful than A.
It is not - downstream (speaking for RDO) I would keep Version:
2015.1.N where N is stable patch# so that we have a common
On 06/01/15 03:20, Steve Gordon wrote:
- Original Message -
From: Maish Saidel-Keesing mais...@maishsk.com
To: openstack-dev@lists.openstack.org
On 05/29/15 18:25, Matthew Thode wrote:
On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
What about release notes? How can we now communicate
You will get different checksums with tar and/or gzip, you can check the
extracted files and they should be the same.
Yes, content is the same, it's just difference in timestamps of
folders and generated files (ChangeLog, egg-info etc).
I would like to see signed commits in the 'official'
On 29 May 2015 at 14:41, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
Ideally I would still
On 01/06/15 12:10, Flavio Percoco wrote:
Is this a real problem? What are *tarball timestamps* used for in the
packaging world?
I'm sure there's a way we can workaround this issue.
timestamps just give you a hint, how old the source actually is, not
when a packager downloaded the tarball
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/29/2015 06:24 PM, Jeremy Stanley wrote:
On 2015-05-29 17:50:01 +0200 (+0200), Ihar Hrachyshka wrote: [...]
if we attempt to fix a security issue that has a backwards
incompatible fix, then we are forced in introducing a new
configuration
On 1 Jun 2015 10:50 am, Alan Pevec ape...@gmail.com wrote:
2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
This is generally my opinion as-well, I always hoped that *every*
commit would be considered a release rather
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/01/2015 02:20 AM, Steve Gordon wrote:
- Original Message -
From: Maish Saidel-Keesing mais...@maishsk.com To:
openstack-dev@lists.openstack.org
On 05/29/15 18:25, Matthew Thode wrote:
On 05/29/2015 10:18 AM, Ihar Hrachyshka
One issue is how would we provide source tarballs, statically hosting
tarballs for each and every micro version is not realistic, also those
wouldn't be signed.
Sorry, but why isn't it realistic, and why wouldn't they be signed?
I thought storage requirements to generate tarball for each
On 01/06/15 10:29, Flavio Percoco wrote:
AFAIK, these tarballs are generated on the flight in GH. Couldn't we
do the same ?
The issue with on-the-fly generation is: timestamps are actually new,
and not the same as when the release was tagged.
And: you probably want some hashes to verify,
On 01/06/15 11:27 +0200, Matthias Runge wrote:
On 01/06/15 10:29, Flavio Percoco wrote:
AFAIK, these tarballs are generated on the flight in GH. Couldn't we
do the same ?
s/flight/fly+(facepalm)/ LOL, on the *flight* would be really hard.
The issue with on-the-fly generation is: timestamps
On 01/06/15 10:07 +0200, Alan Pevec wrote:
One issue is how would we provide source tarballs, statically hosting
tarballs for each and every micro version is not realistic, also those
wouldn't be signed.
Sorry, but why isn't it realistic, and why wouldn't they be signed?
I thought storage
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/29/2015 11:46 PM, Haïkel wrote:
A release version makes it easy to know what fixes are shipped in a
package. If you rebase on stable branches, then you can just put
the git sha1sum (though, it's not very friendly) in the version,
and
Thierry Carrez wrote:
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
Thanks everyone for the constructive discussion on this. Lots of good
stuff. Let me
On 29/05/15 09:44 -0500, Matt Riedemann wrote:
On 5/29/2015 8:41 AM, Thierry Carrez wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
Long
On 1 Jun 2015 8:07 pm, Alan Pevec ape...@gmail.com wrote:
One issue is how would we provide source tarballs, statically hosting
tarballs for each and every micro version is not realistic, also those
wouldn't be signed.
Sorry, but why isn't it realistic, and why wouldn't they be signed?
Thierry Carrez wrote:
Thanks everyone for the constructive discussion on this. Lots of good
stuff. Let me summarize the objections so far:
1. we'd lose the focus rhythm
Point releases triggered some attention to stable branches: the
necessity to fix the CI there when it's broken, and a
On 2015-06-01 12:04:34 +0200 (+0200), Thierry Carrez wrote:
Thierry Carrez wrote:
[...]
2. it would be difficult to get proper release notes
If we don't have point releases anymore, we don't have release notes
anymore. Release notes contain various types of information: the list of
On 2015-06-01 17:32:03 +0200 (+0200), Alan Pevec wrote:
[...]
and *Plan D* would be to start doing automatic per-project
micro-versions on each commit: e.g. 2015.1.N where N is increased on
each commit. There's just TBD item how to provide source tarballs for
this.
[...]
That would happen
On 2015-06-01 12:20:22 +0100 (+0100), Dimitri John Ledkov wrote:
[...]
If the stable tarball snapshots had stable, ever increasing names, I
would switch to using those straight away. (Out of which $ git
describe --tags satisfies said requirement)
Current PBR releases already create
*Plan C* would be to just let projects tag stable point releases from
time to time. That would solve all the original stated problems. And
that would solve objections 2 and 3, which I think are the most valid ones.
and *Plan D* would be to start doing automatic per-project
micro-versions on
2015-06-01 17:32 GMT+02:00 Alan Pevec ape...@gmail.com:
*Plan C* would be to just let projects tag stable point releases from
time to time. That would solve all the original stated problems. And
that would solve objections 2 and 3, which I think are the most valid ones.
and *Plan D* would be
On 6/1/15, 06:20, Dimitri John Ledkov dimitri.j.led...@intel.com wrote:
On 29 May 2015 at 14:41, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted
On 2015-06-01 15:57:17 + (+), Jeremy Stanley wrote:
[...]
The biggest hurdle is that we'd need a separate upload job name
for those since the current version of Zuul lacks a way to run a
particular job for different branches in different pipelines (we'd
want to do versioned uploads for
2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
This is generally my opinion as-well, I always hoped that *every*
commit would be considered a release rather than an arbitrary
tagged date.
[...]
If we switch away from
On 05/31/2015 05:50 PM, Alan Pevec wrote:
2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
This is generally my opinion as-well, I always hoped that *every*
commit would be considered a release rather than an arbitrary
- Original Message -
From: Maish Saidel-Keesing mais...@maishsk.com
To: openstack-dev@lists.openstack.org
On 05/29/15 18:25, Matthew Thode wrote:
On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
What about release notes? How can we now communicate some changes that
require
On 05/29/15 18:25, Matthew Thode wrote:
On 05/29/2015 10:18 AM, Ihar Hrachyshka wrote:
What about release notes? How can we now communicate some changes that
require operator consideration or action?
Ihar
On 05/29/2015 03:41 PM, Thierry Carrez wrote:
Hi everyone,
TL;DR: - We propose to stop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
What about release notes? How can we now communicate some changes that
require operator consideration or action?
Ihar
On 05/29/2015 03:41 PM, Thierry Carrez wrote:
Hi everyone,
TL;DR: - We propose to stop tagging coordinated point releases
On 29 May 2015 at 14:41, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
Long version:
At the
On 5/29/2015 10:30 AM, Dave Walker wrote:
On 29 May 2015 at 14:41, Thierry Carrez thie...@openstack.org wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all
On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
This is generally my opinion as-well, I always hoped that *every*
commit would be considered a release rather than an arbitrary
tagged date.
[...]
If we switch away from lockstep major/minor release versioning
anyway (again separate
Neil Jerram wrote:
On 29/05/15 14:41, Thierry Carrez wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
[...]
I initially
On 05/29/2015 09:44 AM, Matt Riedemann wrote:
On 5/29/2015 8:41 AM, Thierry Carrez wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
On 2015-05-29 17:50:01 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
if we attempt to fix a security issue that has a backwards
incompatible fix, then we are forced in introducing a new
configuration option to opt-in the new secure world.
[...]
To my knowledge that's how we've handled these in
On 29/05/15 14:41, Thierry Carrez wrote:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a trusted source of stable
updates for all projects though
[...]
I initially misunderstood your email as saying
1 - 100 of 113 matches
Mail list logo
