To be effective at improving the life of release managers, the nightly release process really should use as close as possible to the same scripts that the RM uses to produce the release. Otherwise we could have a situation where the nightlies succeed but there is some problem that either fails an RC or is unable to be produced at all.
On Sat, Jul 13, 2019 at 9:12 AM Andy Grove <andygrov...@gmail.com> wrote: > > I would like to volunteer to help with Java and Rust release process work, > especially nightly releases. > > Although I'm not that familiar with the Java implementation of Arrow, I > have been using Java and Maven for a very long time. > > Do we envisage a single nightly release process that releases all languages > simultaneously? or do we want separate process per language, with different > maintainers? > > > > On Wed, Jul 10, 2019 at 8:18 AM Wes McKinney <wesmck...@gmail.com> wrote: > > > On Sun, Jul 7, 2019 at 7:40 PM Sutou Kouhei <k...@clear-code.com> wrote: > > > > > > Hi, > > > > > > > in future releases we should > > > > institute a minimum 24-hour "quiet period" after any community > > > > feedback on a release candidate to allow issues to be examined > > > > further. > > > > > > I agree with this. I'll do so when I do a release manager in > > > the future. > > > > > > > To be able to release more often, two things have to happen: > > > > > > > > * More PMC members must engage with the release management role, > > > > process, and tools > > > > * Continued improvements to release tooling to make the process less > > > > painful for the release manager. For example, it seems we may want to > > > > find a different place than Bintray to host binary artifacts > > > > temporarily during release votes > > > > > > My opinion that we need to build nightly release system. > > > > > > It uses dev/release/NN-*.sh to build .tar.gz and binary > > > artifacts from the .tar.gz. > > > It also uses dev/release/verify-release-candidate.* to > > > verify build .tar.gz and binary artifacts. > > > It also uses dev/release/post-NN-*.sh to do post release > > > tasks. (Some tasks such as uploading a package to packaging > > > system will be dry-run.) > > > > > > > I agree that having a turn-key release system that's capable of > > producing nightly packages is the way to do. That way any problems > > that would block a release will come up as they happen rather than > > piling up until the very end like they are now. > > > > > I needed 10 or more changes for dev/release/ to create > > > 0.14.0 RC0. (Some of them are still in my local stashes. I > > > don't have time to create pull requests for them > > > yet. Because I postponed some tasks of my main > > > business. I'll create pull requests after I finished the > > > postponed tasks of my main business.) > > > > > > > Thanks. I'll follow up on the 0.14.1/0.15.0 thread -- since we need to > > release again soon because of problems with 0.14.0 please let us know > > what patches will be needed to make another release. > > > > > If we fix problems related to dev/release/ in our normal > > > development process, release process will be less painful. > > > > > > The biggest problem for 0.14.0 RC0 is java/pom.xml related: > > > https://github.com/apache/arrow/pull/4717 > > > > > > It was difficult for me because I don't have Java > > > knowledge. Release manager needs help from many developers > > > because release manager may not have knowledge of all > > > supported languages. Apache Arrow supports 10 over > > > languages. > > > > > > > > > For Bintray API limit problem, we'll be able to resolve it. > > > I was added to https://bintray.com/apache/ members: > > > > > > https://issues.apache.org/jira/browse/INFRA-18698 > > > > > > I'll be able to use Bintray API without limitation in the > > > future. Release managers should also request the same thing. > > > > > > > This is good, I will add myself. Other PMC members should also add > > themselves. > > > > > > > > Thanks, > > > -- > > > kou > > > > > > In <CAJPUwMBRzYQ=hbVwFuPYAB-O=lsowxqxidjapc_cofguksj...@mail.gmail.com> > > > "[DISCUSS] Release cadence and release vote conventions" on Sat, 6 Jul > > 2019 16:28:50 -0500, > > > Wes McKinney <wesmck...@gmail.com> wrote: > > > > > > > hi folks, > > > > > > > > As a reminder, particularly since we have many new community members > > > > (some of whom have never been involved with an ASF project before), > > > > releases are approved exclusively by the PMC and in general releases > > > > cannot be vetoed. In spite of that, we strive to make releases that > > > > have unanimous (either by explicit +1 or lazy consent) support of the > > > > PMC. So it is better to have unanimous 5 +1 votes than 6 +1 votes with > > > > a -1 dissenting vote. > > > > > > > > On the 0.14.0 vote, as with previous release votes, some issues with > > > > the release were raised by members of the community, whether build or > > > > test-related problems or other failures. Technically speaking, such > > > > issues have no _direct_ bearing on whether a release vote passes, only > > > > on whether PMC members vote +1, 0, or -1. A PMC member is allowed to > > > > change their vote based on new information -- for example, if I voted > > > > +1 on a release and then someone reported a serious licensing issue, > > > > then I would revise my vote to -1. > > > > > > > > On the RC0 vote thread, Jacques wrote [1] > > > > > > > > "A release vote should last until we arrive at consensus. When an > > > > issue is potentially identified, those that have voted should be given > > > > ample time to change their vote and others that may have been lazy > > > > consenters should be given time to chime in. There is no maximum > > > > amount of time a vote can be open. Allowing at least 24 hours after an > > > > objection is raised is a pretty minimum expectation unless the > > > > objector removes their objection. > > > > > > > > Note that Apache is more focused on consensus than timing (as opposed > > to > > > > virtually other other organizations in the world)." > > > > > > > > I agree with this and my opinion is that in future releases we should > > > > institute a minimum 24-hour "quiet period" after any community > > > > feedback on a release candidate to allow issues to be examined > > > > further. If someone finds a potential problem, and no negative votes > > > > are cast or changed, then the vote can close. > > > > > > > > As a related matter, it seems clear to me that Apache Arrow should > > > > have more frequent releases. I think this would decrease pressure on > > > > developers and users alike. While we've made strides to improve the > > > > tooling for release management (big thanks to Kou, Yosuke, Krisztian, > > > > and others), there is still quite some labor involved and potential > > > > for issues (e.g. API rate limiting for binary artifacts on Bintray). > > > > > > > > To be able to release more often, two things have to happen: > > > > > > > > * More PMC members must engage with the release management role, > > > > process, and tools > > > > * Continued improvements to release tooling to make the process less > > > > painful for the release manager. For example, it seems we may want to > > > > find a different place than Bintray to host binary artifacts > > > > temporarily during release votes > > > > > > > > Any other ideas for things we can do to improve the process and > > > > cadence of releases? > > > > > > > > Thanks, > > > > Wes > > > > > > > > [1]: > > https://lists.apache.org/thread.html/be6210e97b838494a5516dad6408f479efe4c98aff805000597c0196@%3Cdev.arrow.apache.org%3E > >
