Open Stack

2015-05-29 21:23 GMT+02:00 Ian Cordasco <ian.cordasco at rackspace.com>:
>
>
> On 5/29/15, 12:14, "Haïkel" <hguemar at fedoraproject.org> wrote:
>
>>2015-05-29 15:41 GMT+02:00 Thierry Carrez <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.
>
> Can you expound on why this is difficult? I believe you, but I want to
> understand it better.
>

It's impossible to ship a package for every commit, so that means we'll
end up to ship.
1. random commit => bad for tracking issues
2. time-based release (ie: rebuilding every 2 or 4 weeks)
3. cherry-picking commits from stable branches => leads to practical forks

>>I'm personally not fond of this as it will lead to more fragmentation.
>
> 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 freedom.
>

Freedom leads to fragmentation, it's not bad though I prefer collaborating
in stabilizing the same releases.
That's a personal preference, not an argument :)

>>It may encourage
>>bad behaviors like shipping downstream patches for bug fixes and CVE
>>instead
>>of collaborating upstream to differentiate themselves.
>
> Perhaps I'm wrong, but when a CVE is released, don't the downstream
> packagers usually patch whatever version they have and push that out?
> Isn't that the point of them being on an private list to receive embargoed
> notifications with the patches?
>

Yes, but everyone will have different strategies, when releasing a package as I
explained

>>For instance, if we had no point-based release, for issues tracking
>>purposes, we would
>>have to maintain our sets of tags somewhere.
>
> But, if I understand correct, downstream sometimes has patches they apply
> (or develop) to ensure the package is rock solid on their distribution.
> Those aren't always relevant upstream so you maintain them. How is this
> different?
>

Pure downstream patches are not a problem, though we aim to drop them
for our packages.
We'd need the aforementioned tags to track what we currently shipping in our
packages. Having a proper release version/changelog makes it easy to check
if you're shipping a fix or not either by release on release version
or git commit.

Usually, downstream patches are rebased against latest release.

>>There's also the release notes issue that has already been mentioned.
>>Still continuous release notes won't solve the problem, as you wouldn't
>>be able to map these to the actual packages. Will we require operators
>>to find from which git commit, the packages were built and then try to
>>figure
>>out which fixes are and are not included?
>
> I think this is wrong. If it's a continuously updated set of notes, then
> whatever SHA the head of stable/X is at will be the correct set of notes
> for that branch. If you decide to package a SHA earlier than that, then
> you would need to do this, but I'm not sure why you would want to package
> a SHA that isn't at the HEAD of that branch.
>

We were speaking about leveraging wiki, if we talking about Changelog shipped
in git, we agree then.
But that requires ensuring that changelogs are properly updated with
every commit,
then (which is not the case actually).

>>
>>> 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.
>>>
>>
>>And that's actually a pain point to track for these releases in which
>>OpenStack branch belong. And this is probably something that needs to
>>be resolved.
>
> Well there's been a lot of discussion around not integrating releases at
> all. That said, I'm not sure I disagree. Coordinating release numbers is
> fine. Coordinating release dates seems less so, especially since they
> prevent the project from delivering what it's promised so that it can
> manage to get something that's super stable by an arbitrary date.
>

Yes,  the problem to solve is make easier to match a swift/ironic/whatever
releases to OpenStack version (aka kilo, liberty).
Coordinating relase numbers is one solution, but not the only one (like having
projects keeping track of that in shared table)

>>
>>> (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.
>>>
>>
>>Agreed, but why not switching to a time-based release?
>>Regularly, we tag/generate/upload tarballs, this could even be automated.
>>As far as I'm concerned, I would be more happy to have more frequent
>>releases.
>
> A time based release would probably consist of just tagging whatever SHA
> is the HEAD of that branch, especially if it's automated. And if it is
> automated, the release notes will mostly just be the one-line log info
> between the last release and HEAD (kind of like the oslo release notes).
> That seems to me, to be something that y'all could do just as easily as we
> could.
>

Yes, but I prefer do it upstream rather than downstream :)

>>
>>> (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).
>>>
>>
>>Thanks, I was not able to join this discussion, and that was the kind
>>of proposal
>>that I was fearing to see happen.
>>
>>> 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.
>>>
>>
>>We provide both type of builds
>>* git continuous builds => for testing/CI and early feedback on potential
>>issues
>>* point-release based builds => for GA, and production
>>
>>Anyway, I won't force anyone to do something they don't want to do but I'm
>>willing to step in to keep point releases in one form or another.
>>
>>Regards,
>>H.
>>
>>> Thanks in advance for your feedback,
>>>
>>> [1] https://etherpad.openstack.org/p/YVR-relmgt-stable-branch
>>>
>>> --
>>> Thierry Carrez (ttx)
>>>
>>>
>>>_________________________________________________________________________
>>>_
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>__________________________________________________________________________
>>OpenStack Development Mailing List (not for usage questions)
>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev