meejah <mee...@meejah.ca> 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.
signature.asc
Description: PGP signature
_______________________________________________ tahoe-dev mailing list tahoe-dev@lists.tahoe-lafs.org https://lists.tahoe-lafs.org/mailman/listinfo/tahoe-dev
