Open Stack

On 6/7/15, 03:47, "Thomas Goirand" <zigo at debian.org> wrote:

>On 05/29/2015 09:36 PM, Dave Walker wrote:
>> Responses inline.
>> 
>> On 29 May 2015 6:15 pm, "Haïkel" <hguemar at fedoraproject.org
>> <mailto:hguemar at fedoraproject.org>> wrote:
>>>
>>> 2015-05-29 15:41 GMT+02:00 Thierry Carrez <thierry at openstack.org
>> <mailto:thierry at 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 though
>>> >
>>>
>>> Hi,
>>>
>>> I'm one of the main maintainer of the packages for Fedora/RHEL/CentOS.
>>> We try to stick as much as possible to upstream (almost zero
>>> downstream patches),
>>> and without intermediate releases, it will get difficult.
>> 
>> 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 branches. Maybe early in a stable branch's
life there are lots of commits, but as it grows older, the number of
commits made to a stable branch certainly isn't 1 per day.

>If we were to do this in downstream distros, we wouldn't have an
>upstream number matching each commit. This would be a problem because we
>would loose track of what version we're at between distros.

It seems from other discussions that there is little coordination between
distros in the first place, and that is only beginning to improve now, but
only between close relatives (Ubuntu & Debian, RHEL & CentOS & Fedora,
etc.). If that's the case, the work to improve coordination, including
sharing repositories, etc. would seem to alleviate this concern regardless
of coordinated release tagging.

>>> I'm personally not fond of this as it will lead to more fragmentation.
>>> It may encourage
>>> bad behaviors like shipping downstream patches for bug fixes and CVE
>> instead
>>> of collaborating upstream to differentiate themselves.
>>> For instance, if we had no point-based release, for issues tracking
>>> purposes, we would
>>> have to maintain our sets of tags somewhere.
>> 
>> I disagree, each distro already does security patching and whilst I
>> expect this to still happens, it actually *encourages* upstream first
>> workflow as you can select a release on your own cadence that includes
>> commits you need, for your users.
>
>We are discussing point releases. This is only far related to security
>fixes. Point releases are including bug fixes which, most of the time,
>aren't security fixes which are by the way always backported to the
>previous point release, and uploaded as hotfixes to distributions.

Not every bug fix gets backported during the life of a stable branch. At
least in Glance, the majority of backports are security fixes and the rest
are rather serious bugs that significantly break the service or prevent
the use of the service. Last I checked, bug fixes needed to meet a certain
set of criteria before a backport was created. I'm fairly certain this
hasn't changed, but I admit that I haven't checked for changes in the last
several months.

That said, I know you've said in the past that you do most of your
packaging in your free-time because it's not part of your job
responsibilities. I know the same is true for a bunch of OpenStack's
packagers (including the Gentoo packager). This is what makes me torn on
whether or not we should totally drop stable point releases. As someone
who spends the majority of their free time supporting other software
beyond OpenStack, I understand how insulting it is to be told you have to
do more work in the time that you're volunteering.

This makes me more in favor of letting projects cut their own point
releases for stable branches. That said, I don't think it will alleviate
your concerns of guaranteeing that 2015.2.1 of X works with 2015.2.1 of Y,
but if these truly are only bug fixes, then I think the guarantee is
implicit in the branch. I've only been around for a little less than a
year though, so I have no memory of a backport in one service breaking
another.