I wanted to thank everyone for their detailed & thoughtful replies in this thread. The Arrow-Rust community feel that they can streamline the release process to do a source release every two weeks or so, similar to the processes for SkyWalking and Airflow mentioned in the thread.
Julian On 2021/05/02 09:00:05, Sheng Wu <wu.sheng.841...@gmail.com> wrote: > Hi Jarek > > SkyWalking and Airflow communities always share some similar patterns due > to our modulization pattern for building systems. > I think your way should be good from the foundation perspective. > Meaningwhile in SkyWalking, we rely on auto e2e/unit tests a lot rather > than manual testing. > SkyWalking's backend/UI/javaagent with protocols release every 1-1.5 > months, and all PMC would be involved in. > But other agents and tools are on their own, and which of them have more > than 3 PMC members, so, after all, we could avoid overheating of voting by > this way. > > Arrow community friends, you could choose which ways you prefer and want to > do an experiment. > > After all, from my understanding, manual testing and over PMC testing are > not restricted rules for a release. > PMC approved with compilable and no(or minimal) LICENSE issues are > expected by the foundation. > Software always has bugs, the robustness of your release could be > determined with time, and this is on PMC's call. > > Sheng Wu 吴晟 > Twitter, wusheng1108 > > > Jarek Potiuk <ja...@potiuk.com> 于2021年5月2日周日 下午4:26写道： > > > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
