Open Stack

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.

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.

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.  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.

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.  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.

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.

--
Kind Regards,
Dave Walker