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 <[email protected]> wrote:
> On Fri, 14 Jun 2019 16:41:47 -0700
> Neal Richardson <[email protected]> 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.
>
>
