Thank you, Kou and Wes, for your responses. As per discussions in the last sync call[11-Nov], there were talks about releasing more frequently and help is needed with the build process. There was also a discussion on creating specific tickets on which help is needed from the community. Just wanted to confirm if those tickets were created, if not, who is the best person to create those tickets?
Regards, Keerat On Tue, Nov 10, 2020 at 7:53 PM Wes McKinney <wesmck...@gmail.com> wrote: > +1 to everything that Kou said. > > On Tue, Nov 10, 2020 at 8:53 PM Sutou Kouhei <k...@clear-code.com> wrote: > > > Hi, > > > > I agree with Wes. We can automate more release related > > tasks. I hope that we produce and verify release artifacts > > nightly. > > > > See also: > > [DISCUSS] Release cadence and release vote conventions > > > > > https://lists.apache.org/thread.html/5e93b0d79a5d3a31cee6f2100c94221de72cb4d5acb1d92b8681e9a6%40%3Cdev.arrow.apache.org%3E > > > > I think that the main blocker is the Java's build system > > mentioned by Wes in this thread too. For example, it > > requires tagging in release process. It's not suitable for > > building nightly release artifacts. > > (See the above thread for details. I described this more.) > > > > > > Keeping all nightly builds green is also very helpful. > > We're receiving "[NIGHTLY]" report everyday from dev@. > > See also: > > > https://lists.apache.org/list.html?dev@arrow.apache.org:lte=1M:%5BNIGHTLY%5D > > > > There are some failures everyday. > > If we have any failures, we can't produce release artifacts. > > In recent releases, we fix these failures when we release a > > new version. If we keep all nightly builds green, we will be > > able to release a new version soon when we want to release. > > > > > > Thanks, > > -- > > kou > > > > In <CAJPUwMDEaVxZ6hPbyF1rM8djYJDfq5w-s=tvM9OYSAx5Nd=d...@mail.gmail.com> > > "Re: [Discuss] Arrow Release Schedule" on Tue, 10 Nov 2020 18:23:16 > > -0600, > > Wes McKinney <wesmck...@gmail.com> wrote: > > > > > We do need a PMC member to sign the release artifacts. Aside from > > > that, IMHO there is a lot that can be done to improve the automation > > > around producing the release artifacts and preparing the release > > > branch. > > > > > > As Krisztian can attest, producing a release currently requires a > > > _lot_ of human time (and time is money). Now that we've gone through > > > this process to produce 28 major and patch releases, I think it is > > > time (and probably well overdue) to improve the release artifact > > > "stamping" process to be more fully automated so that all that's > > > required of a PMC member is to obtain the staged artifacts from a > > > secure location, sign them, and then push them to ASF dist. > > > > > > On Tue, Nov 10, 2020 at 3:47 PM Keerat Singh <keer...@bitquilltech.com > > > > wrote: > > >> > > >> Hi Wes, > > >> > > >> Is it only the PMC members that can volunteer to drive this or can > > someone from the community volunteer and drive as well if they desire to > > have a release sooner? > > >> > > >> I see that the release process has a fairly comprehensive checklist of > > tasks here( > > > https://cwiki.apache.org/confluence/display/ARROW/Release+Management+Guide > ), > > but there are certain requirements, which not all community members will > be > > able to satisfy, for e.g: > > >> > > >> Being a committer to be able to push to dist and maven repository > > >> A GPG key in the Apache Web of Trust (cross-signed by other Apache > > committers/PMC members) to sign the artifacts > > >> > > >> What parts of the release could a community volunteer help with, given > > they are not able to satisfy certain release requirements? > > >> > > >> Regards, > > >> Keerat > > >> > > >> On Tue, Nov 3, 2020 at 5:27 AM Wes McKinney <wesmck...@gmail.com> > > wrote: > > >>> > > >>> I think to release more often, a few things are necessary: > > >>> > > >>> - Other organizations / PMC members must volunteer more time to drive > > >>> releases and the process around them. My team (and Krisztian in > > particular) > > >>> together with Kou and Uwe have done the majority of this work the > last > > >>> couple of years. > > >>> > > >>> - Some investments in improving the release tooling to be more > > automated > > >>> and less error prone must be made. We’ve talked for example about > > tearing > > >>> out the Maven release machinery for Java, that would be a significant > > >>> benefit. > > >>> > > >>> On Tue, Nov 3, 2020 at 12:45 AM Micah Kornfield < > emkornfi...@gmail.com > > > > > >>> wrote: > > >>> > > >>> > > > > >>> > > Are there any plans for a more frequent release cadence? > > >>> > > > >>> > Not to my knowledge. The release process is still relatively heavy > > weight. > > >>> > > > >>> > Do we have a guide for what goes into major releases vs. minor > > releases > > >>> > > vs. patch releases? > > >>> > > > >>> > In the current regime [1] we don't expect minor release. So major > > releases > > >>> > should contain any new features. Patch release should only contain > > >>> > regression fixes. > > >>> > > > >>> > [1] https://arrow.apache.org/docs/format/Versioning.html > > >>> > > > >>> > On Mon, Nov 2, 2020 at 8:16 PM James Duong < > jam...@bitquilltech.com> > > >>> > wrote: > > >>> > > > >>> > > Hello, > > >>> > > > > >>> > > My understanding is that Arrow releases are 3 months apart. Are > > there any > > >>> > > plans for a more frequent release cadence? Do we have a guide for > > what > > >>> > goes > > >>> > > into major releases vs. minor releases vs. patch releases? > > >>> > > > > >>> > > Thanks, > > >>> > > > > >>> > > -- > > >>> > > > > >>> > > *James Duong* > > >>> > > Lead Software Developer > > >>> > > Bit Quill Technologies Inc. > > >>> > > Direct: +1.604.562.6082 | jam...@bitquilltech.com > > >>> > > https://www.bitquilltech.com > > >>> > > > > >>> > > This email message is for the sole use of the intended > > recipient(s) and > > >>> > may > > >>> > > contain confidential and privileged information. Any > unauthorized > > >>> > review, > > >>> > > use, disclosure, or distribution is prohibited. If you are not > the > > >>> > > intended recipient, please contact the sender by reply email and > > destroy > > >>> > > all copies of the original message. Thank you. > > >>> > > > > >>> > > >
