I also agree that time-based releases are the only reasonable thing to do going forward. It also creates a sense of urgency to complete work by a certain date, in the sense of "the ship is leaving the port on X, all aboard!"
The Blocker priority on JIRA can be used to communicate if some issue should prevent a release candidate from being cut, but contributors can also state whether there is some concerning issue here on the mailing list. With that being said, I think we should have the backlog closed and the project ready by June 24. A number of optional builds are still broken, and Flight is not set up in the Python packages, so those are the things that I would like to see sorted out by then, all the rest is nice-to-have. - Wes On Sun, Jun 16, 2019 at 3:38 AM Sutou Kouhei <k...@clear-code.com> wrote: > > Hi, > > > If we want to stick to project-wide releases where all languages and > > components are released once, then time-based releases are the only > > reasonable scheme IMHO. Of course, there may still be release-blocking > > issues, but those should only be important regressions, not "this is a > > feature we'd definitely like to see in this release". > > I think so too. > > I'll make blocker tasks "nice-to-have" if these tasks aren't > critical for release. For example, I'll mark them > "nice-to-have" as a release manager if they doesn't fix not > buildable issues. > > In pre-release, the followings are helpful: > > * JIRA tidying > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-JIRAtidying > > * Testing API document generation > How? Documented? > > * Testing package builds and generated packages > * For package builds: Crossbow is used. Where is the document? > * For package test: How? Documented? > > * Testing the master on many platforms > > In release process, the followings are helpful: > > * Resolving issues reported by release manager > > * Testing RC > > In post-release, the followings are helpful. Some of them > requires PMC member or committer role but others can be worked > by everyone: > > * Updating the Arrow website > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingtheArrowwebsite > * Require committer role > > * Announcing release > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Announcingrelease > * Require PMC member role? > > * Updating website with new API documentation > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingwebsitewithnewAPIdocumentation > * Require committer role > > * Updating C++ and Python packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingC++andPythonpackages > * Everyone can work on? > > * Updating Homebrew packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingHomebrewpackages > * Everyone can work on > > * Updating Ruby packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRubypackages > * Require PMC member role? > > * Updating JavaScript packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingJavaScriptpackages > * Require PMC member role? > > * Updating .NET NuGet packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-Updating.NETNuGetpackages > * Require PMC member role? > > * Updating Rust packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingRustpackages > * Require PMC member role? > > * Updating CRAN packages > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide#ReleaseManagementGuide-UpdatingCRANpackages > * Require PMC member role? > > > Thanks, > -- > kou > > In <20190615114806.1a23be13@fsol> > "Re: [DISCUSS] Timing of release and making a 1.0.0 release marking Arrow > protocol stability" on Sat, 15 Jun 2019 11:48:06 +0200, > Antoine Pitrou <solip...@pitrou.net> wrote: > > > On Fri, 14 Jun 2019 16:41:47 -0700 > > Neal Richardson <neal.p.richard...@gmail.com> wrote: > >> > >> I gather that this has all been done informally in the past, but would some > >> folks be interested in taking up this release-prep role for the various > >> languages and formalizing that responsibility a bit? By "formalize" I just > >> mean write down on the wiki ( > >> https://cwiki.apache.org/confluence/display/ARROW/Arrow+0.14.0+Release) who > >> is overseeing the release for each language and what the current status is. > >> That way, Kou and anyone else can see at a glance which subprojects are > >> ready for release and who to talk to about wrangling the others. For my > >> part, I've been curating the R backlog and 0.14 release scope and working > >> with Romain and others to get the essentials done, and I'd be happy to > >> record that I'm doing this and publicize when the key issues have been > >> addressed and we're ready to release. If different people were to do that > >> for the other 10 languages, we could eliminate some ambiguity as to what > >> the status is and who is taking responsibility for ensuring that the > >> necessary work gets done. > > > > The risk if we have that kind of process for 11 languages is that > > releases never get ready because there's always something left to > > improve, fix or clean up. > > > > If we want to stick to project-wide releases where all languages and > > components are released once, then time-based releases are the only > > reasonable scheme IMHO. Of course, there may still be release-blocking > > issues, but those should only be important regressions, not "this is a > > feature we'd definitely like to see in this release". > > > > Regards > > > > Antoine. > > > >
