Open Stack

On 06/10/2015 11:27 AM, Dave Walker wrote:
> On 10 June 2015 at 09:53, Thomas Goirand <zigo at 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 date-based tags across supported projects from time to time.
>>> (-) Encourages to continue using same version across the board
>>> (-) Almost as much work as making proper releases
>>>
>>> Plan C
>>> Let projects randomly tag point releases whenever
>>> (-) Still a bit costly in terms of herding cats
>>>
>>> Plan D
>>> Drop stable point releases, publish per-commit tarballs
>>> (-) Requires some infra changes, takes some storage space
>>>
>>> Plans B, C and D also require some release note / changelog generation
>>> from data maintained *within* the repository.
>>>
>>> Personally I think the objections raised against plan A are valid. I
>>> like plan D, since it's more like releasing every commit than "not
>>> releasing anymore". I think it's the most honest trade-off. I could go
>>> with plan C, but I think it's added work for no additional value to the
>>> user.
>>>
>>> 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 archive"?).
>>
>> What counts is having a schedule date, where all distros are releasing a
>> point release, so we have a common reference point. If that is a fully
>> automated process, then great, less work for everyone, and it wont
>> change anything from what we had in the past (we can even collectively
>> decide for point release dates...).
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
> 
> This is really one of the things I think we want to get away from...
> If *every* stable commit is treated with the seriousness of it
> creating a release, lets make every commit a release.
> 
> This means that Debian may be using a (micro)patch release newer or
> older than a different distro, but the key is that it empowers the
> vendors and/or users to select a release cadence that best fits them,
> rather than being tied to an arbitrary upstream community wide date.

What you don't get here is that downstream distributions *DO* want the
"arbitrary upstream community wide date", and don't want to just use any
commit.

> Yes, this might mean that your cadence might be more or less regular
> than an alternative vendor / distribution, but the key is that it
> empowers the vendor to meet the needs of their users/customers.

When did a distribution vendors express this as an issue? Having
community-wide release dates doesn't prevent any vendor to do a patch
release if he wants to.

> For example, you could select a cadence of rebasing to a release every
> 6 months - where as another consumer could choose to do one every 6
> weeks.

Which is what would be nice to avoid, so we have the same code base.
Otherwise we may be affected differently by a CVE.

> The difference is how much of a jump, at which intervals..
> Alternatively, a vendor might choose just to go with stock release +
> their own select cherry picked patches from stable/*, which is also a
> model that works.

This already happens, we don't need to remove point releases to do that.

> The issue around producing tarballs, is really about having forwards
> and backwards verification by means of sha/md5 sums, which is hard to
> do when generating your own orig tarball.

Opposite way. When generating my tarball, I do it with a GPG signed tag.
This is verifiable very easily. By the way, sha & md5 are in no way
tools to sign a release, for that, we have PGP (and cross-signing of keys).

> Debian, Ubuntu and I
> believe Arch have made varying use of 'pristine-tar' - which was an
> effort to re-producible tarballs using xdelta to make the sum match.
> However, Maintainers seem to be moving away from this now.

As much as I know, I'm the only one using "git archive ... | xz ..." to
generate my own tarballs, but maybe this will change some day.

> When I perform source NEW reviews for Ubuntu Archive, I always check
> that getting the source orig tarball can be done with either
> get-orig-source (inspecting the generation method) or uscan and then
> diff the tarballs with the one included on the upload and the one
> generated.  Timestamps (or even shasums) haven't been an important
> issue for me, but the actual content and verifiable source is what has
> mattered more.

Correct. Though for me, a signed git tag is a way better than any md5 in
the world.

Thomas Goirand (zigo)