There have been some great discussions on the document. I would say the major unresolved questions are
1. What branching strategy would best balance frequent releases, maintainers' time, and contributors' time. 2. (related) How do we handle breaking API changes between major releases that aren't compatible with Rust SemVer expectations? Feature flags? Restricted PR merge windows? Separated maintenance branches? I'll wait a few more days to see how we are doing consensus wise. Thank you to everyone who has contributed already, Andrew On Sun, May 2, 2021 at 8:44 AM Adam Lippai <a...@rigo.sk> wrote: > Hi, > > my two cents: at my previous workplace (Tresorit) we created releases every > week and that process was even heavier including cross > platform verification and approval, a 8-12 hours long dedicated manual QA > process, discussions with the marketing and support teams. > Open source is certainly different as we had 2-8 full time devs per > platform and 2 dedicated QA engineers to ensure this pace (including the > actual development), however when we had struggles it was because: > > 1. People were on vacation and the flow was disrupted > 2. We had big, cross platform changes (timespan over 2 weeks) which we > didn't merge back in time, it hurt us in 50%+ of the cases when we > tried to > "do it in separate feature branch", which might or might not be a lot > > The overhead wasn't big, it was almost only the communication with the > manual QA and creating human readable release notes. It was never about > doing a lot of work, doing only a little, doing bugfix, features or > refactoring. It didn't really matter for the overhead or failure rate. > A few years later Google devops started promoting DORA: > > https://cloud.google.com/blog/products/devops-sre/another-way-to-gauge-your-devops-performance-according-to-dora > and their experience is the same, more than one release per month is needed > to make it stable with lower failure rate and being able to act within a > day if anything goes wrong. > My team was web and javascript focused (but we provided APIs) and we > automated most of the deployment process (well, not the approval and manual > QA of course), however I saw this working pretty well for years, if > anything increasing the pace made the process more deterministic. > > Strictness of the language and the compiler might render this approach > impractical (eg. TypeScript and TS based libs struggle more than JS), but I > think management and QA-wise this proposal improves the process eventually > and we'll get a better product *while not working more.* > > I hope this little anecdotal story reassures some of you that this is not > an over-ambitious change and it enables everyone to continue creating great > things. > > Best regards, > Adam Lippa > > On Sun, May 2, 2021 at 1:00 PM Andrew Lamb <al...@influxdata.com> wrote: > > > Micah and Julian, thank you both for your thoughts. > > > > I largely agree with Micah; While the Apache process may be heavy > weight > > in certain aspects, I think we can achieve Rust releases every 2 week > > within that framework. > > > > As I doubt very much we'll get it perfect on the first try, I was > > envisioning that we start with 2 week releases, see how it goes for a > > while, and then adjust as needed. > > > > Andrew > > > > > > On Sat, May 1, 2021 at 11:20 PM Micah Kornfield <emkornfi...@gmail.com> > > wrote: > > > > > > > > > > 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 > > > > > > > > > > > > > > > >
