Open Stack

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
>>
>> 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 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.
> 
> Personally I've been trying to point out some of these in the
> #openstack-stable IRC channel when I see them so that we don't wait so
> long on these that they fall into a stable support phase where we don't
> think they are appropriate for merging anymore, but if we had acted
> sooner they'd be in.
> 
> But I'm also the new guy on the team so I've got belly fire, feel free
> to tell me to shut up. :)
> 

I generally agree with the points you just made.  From our perspective
(Gentoo) the point releases are nice if only because they require more
focus and testing to be done to be sure they are valid.

That said, I do try to tell our users to use the git based ebuilds (they
point to the stable branches) if at all possible.

-- 
-- Matthew Thode (prometheanfire)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150529/3ba5dc5d/attachment.pgp>