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
