> > Apache releases are quite heavyweight, so > work best at a frequency of 2 - 3 months, whereas (IIUC) Rust > developers expect a more lightweight release on a weekly cadence.
Thanks, I think clarifications on requirements are helpful. IIUC is is actually a 2 week cadence which is still fast but seems doable with dedicated community members (and some investment in tooling). What makes the releases heavy weight? It seems like the process is slightly more tedious than necessarily onerous. Generating a signed tarball, seems like it should take ~5 minutes or less with the proper tooling? Verification is more heavy weight but again with the proper tooling and a good system for testing out more changes, it does not seem like it should take too much developer time if no issues arise. There are 3 active contributors to Rust on the PMC, so if they are willing to sign up for doing the work of verification and voting on this cadence, what would the other requirements around the process be? Best, Micah On Sat, May 1, 2021 at 3:05 PM Julian Hyde <jh...@apache.org> wrote: > The main tension is not in the proposal but the requirements. It's a > classic impedance mismatch. Apache releases are quite heavyweight, so > work best at a frequency of 2 - 3 months, whereas (IIUC) Rust > developers expect a more lightweight release on a weekly cadence. I > was trying to find other projects that had had the same problem, and > solved it somehow. And also raise awareness within Apache that the > release process is problematic for some communities in 2021. > > To correct a couple of misconceptions: > * In Apache, the signed source artifacts (tarball) are literally the > release. Not a git hash, not a set of binary artifacts. That is what > people need to vote on. > * The release vote does not have to last 72 hours. It can be a shorter > period, if the community agrees. > > Julian > > > On Sat, May 1, 2021 at 1:31 PM Micah Kornfield <emkornfi...@gmail.com> > wrote: > > > > Hi Julian, > > I didn't read this proposal as being in tension with apache releases. It > > sounds like the intention is to hold a vote every two weeks to verify a > > release artifacts? But maybe I misread or missed something. Were do you > > think the tension lies? Is it also producing the signed source artifact? > > > > Since votes last for at least 72 hours this does seem like a lot of > > overhead every two weeks, but it seems that is something for Rust > > maintainers to decide and adjust. > > > > -Micah > > > > On Saturday, May 1, 2021, Julian Hyde <jh...@apache.org> wrote: > > > > > (Removing user@ from cc. I think this is mainly a dev@ issue.) > > > > > > I believe there are some tensions between this process and the Apache > > > process. In particular, Apache releases tend to be a signed source > > > distribution (tarball) that at least three PMC members download and > > > verify. I totally understand why, as Rust developers, you might find > > > that an onerous process and might want to operate in a different way. > > > It makes sense, and I believe we can solve it. Perhaps by using a word > > > other than "release" for high-frequency snapshots. > > > > > > It is likely that other projects have already run into this problem > > > and have solved it. Therefore I have sent an email to comdev asking > > > for advice [1]. Feel free to join the thread. > > > > > > Julian > > > > > > [1] > https://lists.apache.org/thread.html/rf12538ef0f60f7257e63391e5d496 > > > 2a6156564020c99d3dfb193f4d7%40%3Cdev.community.apache.org%3E > > > > > > On Sat, May 1, 2021 at 4:01 AM Andrew Lamb <al...@influxdata.com> > wrote: > > > > > > > > I propose regularly releasing, every 2 weeks, minor and patch > releases > > > of > > > > the arrow-rs crate, following the semver versioning scheme used by > the > > > rest > > > > of the Rust ecosystem. I have written a proposal[1] describing how > this > > > > might work. > > > > > > > > Feedback and comments most welcome. > > > > > > > > Andrew > > > > > > > > [1] > > > > https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_ > > > QCHmqMg7L2HmcbEpRISsfNEhSA/edit > > > >
