Open Stack

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 version:
>>
>>At the "stable branch" session in Vancouver we discussed recent
>>evolutions in the stable team processes and how to further adapt the
>>work of the team in a "big tent" world.
>>
>>One of the key questions there was whether we should continue doing
>>stable point releases. Those were basically tags with the same version
>>number ("2015.1.1") that we would periodically push to the stable
>>branches for all projects.
>>
>>Those create three problems.
>>
>>(1) Projects do not all follow the same versioning, so some projects
>>(like Swift) were not part of the "stable point releases". More and more
>>projects are considering issuing intermediary releases (like Swift
>>does), like Ironic. That would result in a variety of version numbers,
>>and ultimately less and less projects being able to have a common
>>"2015.1.1"-like version.
>>
>>(2) Producing those costs a non-trivial amount of effort on a very small
>>team of volunteers, especially with projects caring about stable
>>branches in various amounts. We were constantly missing the
>>pre-announced dates on those ones. Looks like that effort could be
>>better spent improving the stable branches themselves and keeping them
>>working.
>>
>>(3) The resulting "stable point releases" are mostly useless. Stable
>>branches are supposed to be always usable, and the "released" version
>>did not undergo significantly more testing. Issuing them actually
>>discourages people from taking whatever point in stable branches makes
>>the most sense for them, testing and deploying that.
>>
>>The suggestion we made during that session (and which was approved by
>>the session participants) is therefore to just get rid of the "stable
>>point release" concept altogether for non-libraries. That said:
>>
>>- we'd still do individual point releases for libraries (for critical
>>bugs and security issues), so that you can still depend on a specific
>>version there
>>
>>- we'd still very much maintain stable branches (and actually focus our
>>efforts on that work) to ensure they are a continuous source of safe
>>upgrades for users of a given series
>>
>>Now we realize that the cross-section of our community which was present
>>in that session might not fully represent the consumers of those
>>artifacts, which is why we expand the discussion on this mailing-list
>>(and soon on the operators ML).
>>
>>If you were a consumer of those and will miss them, please explain why.
>>In particular, please let us know how consuming that version (which was
>>only made available every n months) is significantly better than picking
>>your preferred time and get all the current stable branch HEADs at that
>>time.
>>
>>Thanks in advance for your feedback,
>>
>>[1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch
>>
>
>To reiterate what I said in the session, for my team personally (IBM), 
>we don't align with the point release schedules on stable anyway, we 
>release our own stable release fix packs as needed on our own 
>schedules, so in that regard I don't see a point in the stable point 
>releases - especially since most of the time I don't know when those 
>are going to be anyway so we can't plan for them accurately.
>
>Having said that, what I mentioned in IRC the other day is the one 
>upside I see to the point releases is it is a milestone that requires 
>focus from the stable maintainers, which means if stable has been 
>broken for a few weeks and no one has really noticed, converging on a 
>stable point release at least forces attention there.
>
>I don't think that is a very good argument for keeping stable point 
>releases though, since as you said we don't do any additional testing 
>above and beyond what normally happens in the Jenkins runs.  Some of 
>the distributions might have extra regression testing scenarios, I'm 
>not sure, but no one really spoke to that in the session from the 
>distros that were present - I assume they do, but they can do that on 
>their own schedule anyway IMO.

I agree it's not a good point in favor of point releases. If anything,
that's just showing some issues with the stable workflow that probably
require more attention than the milestone itself.
>
>I am a bit cynical about thinking that dropping point releases will 
>make people spend more time on caring about the health of the stable 
>branches (persistent gate failures) or stale changes out for review.  
>I combed through a lot of open stable/icehouse changes yesterday and 
>there were many that should have been abandoned 6 months ago but were 
>just sitting there, and others that were good fixes to have and should 
>have been merged by now.

More than making people focus more on the health of stable branches
the whole goal is to remove something that is(?) not necessary.
Basically, this proposal removes unnecessary(?) work from
stable/release ppl.

[snip]

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150601/0d64b181/attachment.pgp>