Hi Sheng, We had a similar discussion recently in Apache Airflow, and I think there are ways you can still follow the Apache Way spirit, follow the voting process and keep the community involved. And I personally think involving your community in the release process is the true embodiment of the "community-over-code".
In Airflow we used to have one release every few months, but as of Airflow 2.0 we split it into 60+ independent packages (Core Airflow + 60+ providers - independent add-ons for Airflow). We also recently started to release a "Python API client" and very soon we will release Helm Chart. Those are all independent releases. Our release process is now that Core Airflow is released every ~ 2 months and the 60+ providers are released with monthly cadence. Roughly every month there are significant "non-doc" changes in 20-30 packages or so so this means that every month we have 20-30 packages to vote on. And yeah, having 30+ voting threads a month would be impossible to handle. So we figured something else. We had a rather heated discussion on how to do it and experimented a bit with it but the very important topic that was raised was the "manual testing" part. We have a very comprehensive, automated testing process - that not only run the tests, but also builds the packages, installs them on top of released Airflow versions, checks if all the modules are importing cleanly and even verify if the automated discovery of those add-ons provides expected results after they are installed. However some of the members of the community (rightfully) thought it is not enough. There needs to be a human factor involved, and it's rather difficult to have one or even few people testing 20-30 different packages every month. And involving the community is the solution. This is what we do now (we are already doing it for the 4th time): 1) we release all the 20-30 packages with a single voting thread. We accept the situation that if someone raises an issue with a specific package, it can be dropped from the release without invalidating the whole voting (this is at the discretion of the release manager who has the ultimate power there - and it's perfectly ok IMHO with ASF rules). 2) the release manager not only announces the release but also prepares an Issue in GitHub where contributors who contributed the fixes are `@mentioned` and asked to test the package being released - for every provider "package" there is a list of people who 'contributed' to it (this is not yet fully automated but can be). Also in some cases the release manager decides that change is very simple and needs no testing other than installing the new package. 3) we ask those contributors for help and verify of their fixes/new feature in the RC of the provider they contributed to and keep track via comments / updating github issue 4) the PMCs nor release manager does not have to test all those providers - if the contributors confirm that the new RC works, we trust it. 5) PMC member's main role is to verify if the packages are signed/checksummed properly, if the sources have all the licences (all that is mostly semi-automated) and to be aware of the testing status. 6) The release manager is mostly responsible for the "mechanics" of the release, reminders etc. but with single issue/voting thread it is manageable even if you release 20-30 packages This worked already 3 times, and we have just started to run another Voting thread for the "May" release wave: The voting thread: https://lists.apache.org/thread.html/rb3fb597796a5b1bf83f97879e6783049dc8f2496b594bc5f3641eee3%40%3Cdev.airflow.apache.org%3E , the GitHub Issue: https://github.com/apache/airflow/issues/15623 The previous GH issues for releases are: https://github.com/apache/airflow/issues/15241, https://github.com/apache/airflow/issues/14670, https://github.com/apache/airflow/issues/14511 Most of the 20-30+ package preparation process is semi-automated. It takes little time for the release manager to prepare and follow up the voting. This is not much (I was acting as one so far and it is rather easy and takes very little time). This approach involves the community and makes people who made the fixes/added features become also stakeholders of the release. They are involved, responsive and usually happy to help and test their changes (knowing that we are just about to release them). And I always thank them for their help. J. On Sun, May 2, 2021 at 2:55 AM Sheng Wu <wu.sheng.841...@gmail.com> wrote: > Hi Julian > > I think a higher frequency release is not an issue. > You just need to have enough PMC members to vote. > Compiling, LICENSE, sign checks are the key, instead, the feature tests and > whether you are releasing a stable release, that is PMC's call. > The minimal time requirement is only 3 days to make global people having a > chance to check the release. > This should not stop the community to do a weekly release. > > SkyWalking doesn't do a weekly release every month, but due to 10+ > subprojects, it is common we do 1-2 releases weekly. > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > > Julian Hyde <jh...@apache.org> 于2021年5月2日周日 上午3:15写道： > > > Does anyone have any resources/suggestions for making the Apache > > release process work smoothly for a community whose culture expects > > very frequent releases? > > > > Some background. I am an ASF member and PMC member of Arrow. I am not > > very active in development, but am doing my best to oversee the > > project to steer its various sub-communities towards the Apache Way. > > > > Arrow is a thriving project, by any measure. It has implementations in > > several languages, and many contributors will tend to contribute in > > just one language, and tend to follow the norms of that language. In > > particular, Rust developers expect regular releases (a cadence of one > > per week is not uncommon). They also build directly from GitHub (they > > don't use a source distribution, or rely on pre-compiled artifacts in > > a package repository). > > > > The Arrow-Rust developers are currently discussing how they might > > bring some of that Rust process into Arrow [1]. > > > > So, two problems arise: > > * My understanding is that an Apache release is a source release. It > > requires a release manager to build and sign a source distribution, > > and at least three people need to download and verify that source > > distribution. That is an onerous process to perform every week. > > * Suppose we were to make source releases less frequently (say once a > > month) but more frequently (say weekly) bless minor versions by > > tagging them in GitHub. We would effectively be encouraging downstream > > projects to rely on unreleased code, and my understanding is that that > > is contrary to Apache release policy. > > > > My questions: > > 1. Are there any languages other than Rust that have a similar process > > of building directly from GitHub? > > 2. Are there any projects (in Rust or other languages) that have > > successfully solved the problem of frequent releases? > > > > Julian > > > > [1] > > > https://docs.google.com/document/d/1QTGah5dkRG0Z6Gny_QCHmqMg7L2HmcbEpRISsfNEhSA/edit > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > > For additional commands, e-mail: dev-h...@community.apache.org > > > > > -- +48 660 796 129
