From meejah at meejah.ca Tue Nov 2 18:51:54 2021 From: meejah at meejah.ca (meejah) Date: Tue, 02 Nov 2021 12:51:54 -0600 Subject: "release candidate" releases Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello Fellow LAFS-ians, Today in our governance meeting we discussed "release candidate" releases. We would like to get rid of them for a few reasons: - their meaning is ambiguous; - there's no clear amount of time/testing/attension required between an RC and "actual" release; - they take extra time; We don't believe this makes a huge practical difference: if a problem with a release is discovered we will work to quickly produce a follow-up. This is true if the problem is in "rc2" (and we produce "rc3") or if the problem is in 1.17.0 (and we produce 1.17.1). Do any of our downstream consumers have any issues with this plan? What use-cases do the existing "rcN" releases answer for you if so? As a reminder, we strive to maintain "master" as "always releasable" and would like to produce releases more rapidly than has happened traditionally; removing RC releases is one step on that path. Thanks, meejah (for the Tahoe-LAFS team) -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEnVor1WiOy4id680/wmAoAxKAaacFAmGBiJEACgkQwmAoAxKA aafbyAgA0q0ei5xObeN0afp5pa1/bZpq3yRCgKWrPEek19KxkSVz3vACHBCBYcas GpIWKxXqPqm5Pk5kUon9tMaWJzWw0fa9rvJKrBtFyI4XqTzg5dNuuG9o2HnWqruy A9DpKSFz+YOYXdAomXPrzGzkeJAOnccywHsIFKP2tnqxUvDNWAwTZPZxAdbI9i9C OUKCHdOSAxW7IgiqFFJvnyQYrE8xUK8Lk3ZDjH7yvagijgXPEwye/5j+5ccSiDfg 0nCBvuweGnmyTVIJMhyxm09DsGVOKyvpJoCh2MPFcbKKAgXZwQI/YezN0EIUmF3g jFgBlEfgDRe98DsUm4OHkXaqbu9QVA== =qSPu -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Tue Nov 2 19:52:08 2021 From: gdt at lexort.com (Greg Troxel) Date: Tue, 02 Nov 2021 15:52:08 -0400 Subject: "release candidate" releases In-Reply-To: (meejah@meejah.ca's message of "Tue, 02 Nov 2021 12:51:54 -0600") References: Message-ID: meejah writes: > Today in our governance meeting we discussed "release candidate" releases. > We would like to get rid of them for a few reasons: > > their meaning is ambiguous; > > there's no clear amount of time/testing/attension required between > an RC and "actual" release; > > they take extra time; I see them as serving the purpose of testing the full trip from a git branch to a packaging system. Whether they are called rc, alpha, or something else is not super important. My experience is that usually after changes to build system or dependencies, there are problems in the git->package path, and calls for testing an rc lead to those being found and fixed. > We don't believe this makes a huge practical difference: if a problem > with a release is discovered we will work to quickly produce a > follow-up. This is true if the problem is in "rc2" (and we produce > "rc3") or if the problem is in 1.17.0 (and we produce 1.17.1). Do you mean that even if a very minor problem is found, affecting only a minority platform, that you will still do this? I mean essentially, any problem that you would have been willing to a apply a post-rc pre-release fix for? > Do any of our downstream consumers have any issues with this plan? > What use-cases do the existing "rcN" releases answer for you if so? To test packaging, I need to take something that is structurally like a release tarball and that was created by the very same process, and then build a package from it. It doesn't have to have rc in the name. I don't want to do this every week. The rc label is how the dev team says to packagers and anybody else that uses release tarballs "right now is when I would like you to test, and we aren't going to be making other than bugfix and maybe doc changes until we release". As for timing, typically there's a week, maybe more, because many people who package things aren't paid and thus are squeeizing it in and in my case I probably look after 50 packages. > As a reminder, we strive to maintain "master" as "always releasable" > and would like to produce releases more rapidly than has happened > traditionally; removing RC releases is one step on that path. The real time issue is for people on other than the dev environment to test, after a change has been made that breaks something, even though of course you didn't intend to. If you can set up CI, so that on every commit, there is a 1.16.70.N pseudorelease made with a release tarball, and that's easy to grab, then this prretty much turns it into "every commit is an RC", and then you don't need to make one, but you still need to say "please actually test now" and refrain from non-bugfix changes. It would be ok if this had the ID 1.16.70 and unpacked to 1.16.70, and I would understand that I should not release a package like that. I do this myself with gpsd, after 'scons dist'. autoconf/automake make tihs very easy, and so of course any build system said to be better than autoconf should too :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From meejah at meejah.ca Wed Nov 3 01:09:37 2021 From: meejah at meejah.ca (meejah) Date: Tue, 02 Nov 2021 19:09:37 -0600 Subject: "release candidate" releases In-Reply-To: References: Message-ID: On Tue, 2 Nov 2021, at 13:52, Greg Troxel wrote: > > meejah writes: > Great, thanks for the followup! > > We don't believe this makes a huge practical difference: if a problem > > with a release is discovered we will work to quickly produce a > > follow-up. This is true if the problem is in "rc2" (and we produce > > "rc3") or if the problem is in 1.17.0 (and we produce 1.17.1). > > Do you mean that even if a very minor problem is found, affecting only a > minority platform, that you will still do this? I mean essentially, any > problem that you would have been willing to a apply a post-rc > pre-release fix for? Yes, any problems found for any supported platform would receive a prompt fix and followup release (e.g. 1.17.1) just the same as if a problem was found with "rc0" and a "rc1" followup was required. > I don't want to do this every week. The rc label is how the dev team > says to packagers and anybody else that uses release tarballs "right now > is when I would like you to test, and we aren't going to be making other > than bugfix and maybe doc changes until we release". This wouldn't be every week. We currently do "some" releases per year, and we'd like that to be a little more frequent (but almost certainly _not_ as frequent as "every week"). Currently, we basically say "here is 1.17.0-rc0, please report problems" and then some ill-defined amount of time later we "release" 1.17.0. The proposed change is to just say "here is 1.17.0, please report problems". I suppose in extreme circumstances it may be the case that a release would have to be pulled entirely (e.g. if there was some larger problem discovered that couldn't be fixed promptly). [...] > pseudorelease made with a release tarball, and that's easy to grab, then > this prretty much turns it into "every commit is an RC", and then you > don't need to make one, but you still need to say "please actually test > now" and refrain from non-bugfix changes. I do personally like this idea a lot -- that is, essentially, to replace "RC" releases with an "always available" latest release from master. I mean, we could even name them as such so that e.g. the first commit to master after 1.17.0 might produce a "1.18.0-rc0" or so (but maybe "1.18.0-alpha1" or so makes sense). The labelling isn't _that_ important, so long as downstream systems like PyPI or pip/poetry/etc aren't confused and believe there's a newer "actual" release out. This could also, in the immediate term, serve to test out further release automation -- especially if they aren't signed (or are signed by a "CI-only automated release key" that people can choose to trust less if appropriate). Thanks, meejah -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Wed Nov 3 01:32:37 2021 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 2 Nov 2021 21:32:37 -0400 Subject: "release candidate" releases In-Reply-To: References: Message-ID: On Tue, Nov 2, 2021 at 2:52 PM meejah wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hello Fellow LAFS-ians, > > Today in our governance meeting we discussed "release candidate" releases. > We would like to get rid of them for a few reasons: > ... > > We don't believe this makes a huge practical difference: if a problem > with a release is discovered we will work to quickly produce a > follow-up. This is true if the problem is in "rc2" (and we produce > "rc3") or if the problem is in 1.17.0 (and we produce 1.17.1). > > Do any of our downstream consumers have any issues with this plan? > What use-cases do the existing "rcN" releases answer for you if so? I think it's a good idea if that's the direction you want to go in. In a few of the projects I help maintain we stopped doing the RC thing. The biggest reasons were: * there is no practical difference between "please test master" and "please test this tarball" * we have to archive the RC tarballs for posterity since they are a release, too We also found it does not matter how much time you wait for testing of master or a tarball. Folks who help with testing are going to do it within a week or so. Everyone else is going to wait for the release and then upgrade. You will get a few bug reports after you release from the latent testers who simply upgrade. So we plan on a dot-release 30 days from the given release because we know we will get a few bug reports after the given release. Jeff From gdt at lexort.com Wed Nov 3 13:15:18 2021 From: gdt at lexort.com (Greg Troxel) Date: Wed, 03 Nov 2021 09:15:18 -0400 Subject: "release candidate" releases In-Reply-To: (meejah@meejah.ca's message of "Tue, 02 Nov 2021 19:09:37 -0600") References: Message-ID: meejah writes: > Yes, any problems found for any supported platform would receive a > prompt fix and followup release (e.g. 1.17.1) just the same as if a > problem was found with "rc0" and a "rc1" followup was required. Not sure I follow "supported". Generally in an rc phase problems found on any platform anybody is running it on would be addressed, and I would hope the idea is that tahoe runs on any system meeting POSIX where the dependencies work (and I think that's actually true). >> I don't want to do this every week. The rc label is how the dev team >> says to packagers and anybody else that uses release tarballs "right now >> is when I would like you to test, and we aren't going to be making other >> than bugfix and maybe doc changes until we release". > > This wouldn't be every week. We currently do "some" releases per year, > and we'd like that to be a little more frequent (but almost certainly > _not_ as frequent as "every week"). I realize that releases woudln't be every week. I meant that without a "here is rc; please test", it would not be reasonable for me to build a tarball from master and test it every week. > Currently, we basically say "here is 1.17.0-rc0, please report > problems" and then some ill-defined amount of time later we "release" > 1.17.0. The proposed change is to just say "here is 1.17.0, please > report problems". So by putting a rc0 label on you are declaring to the packaging/testing community -- which is outside the developer group -- that you think it's close and that now, their time spending testing is warranted. And, if there are issues -- which there are likely to be if there is any build system munging -- then they are "minor things fixed in rc", rather than "tahoe has poor quality control and released a broken release". I realize part of what's driving this is "some ill-defined amount of time later", but the usual approach is to pick a future date, 7 or 14 days after rc publication, and say that in the rc mail as a "not before", and then only delay if there is a reason. > I suppose in extreme circumstances it may be the case that a release > would have to be pulled entirely (e.g. if there was some larger > problem discovered that couldn't be fixed promptly). But that's hard, and it may be packaged. > I do personally like this idea a lot -- that is, essentially, to > replace "RC" releases with an "always available" latest release from > master. I mean, we could even name them as such so that e.g. the first > commit to master after 1.17.0 might produce a "1.18.0-rc0" or so (but > maybe "1.18.0-alpha1" or so makes sense). The labelling isn't _that_ > important, so long as downstream systems like PyPI or pip/poetry/etc > aren't confused and believe there's a newer "actual" release out. > > This could also, in the immediate term, serve to test out further > release automation -- especially if they aren't signed (or are signed > by a "CI-only automated release key" that people can choose to trust > less if appropriate). Release automation is great, because it removes human error in a not-super-frequent process. I just saw another (unrleated) program have a broken release tarball. I guess in the end I don't see shaving publishing an rc and waiting 7 days (if no problems) to publish as being a win compared to giving up that degree of testing before a release. Even if it saved an hour or two, it seems to be way off in the weeds compared to the real issues (e.g. the recent py3 migration). And if it saves more than 2 hours, then the right fix is probably release automaation. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: