On 06/10/2015 11:27 AM, Dave Walker wrote: > On 10 June 2015 at 09:53, Thomas Goirand <z...@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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev