You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Stamatis Zampetakis <za...@gmail.com> on 2019/12/02 18:48:10 UTC
Re: Release managers
Many thanks Haisheng and Danny for stepping up! I added you to the list.
There are two spots left, if nobody else comes up I will take one of them!
Release Target date Release manager
======= =========== ===============
1.19 2019-03 Kevin
1.20 2019-06 Michael
1.21 2019-09 Stamatis
======= =========== ===============
1.22 2019-12 Andrei
1.23 2020-02 Haisheng
1.24 2020-04
1.25 2020-06 Danny
1.26 2020-08
On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com> wrote:
> BTW,
> I can volunteer to be the release manager for v1.25 or v1.26.
>
> Best,
> Danny Chan
> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
> >
> > I can volunteer to be the release manager for v1.23 or v1.24.
>
Re: Release managers
Posted by Julian Hyde <jh...@apache.org>.
I was mistaken in saying that only a PMC can sign a release. Any
committer may be a release manager, and sign the release.
In http://www.apache.org/dev/release-publishing.html#release_manager:
"Any committer may serve as the manager of a release"
Julian
On Fri, Dec 6, 2019 at 9:41 AM Vladimir Sitnikov
<si...@gmail.com> wrote:
>
> Enrico>AFAIK in all of the apache projects I am contributing to as
> committer every
> Enrico>committer can sign the artifacts and be release manager
>
> There existed META effort (which was hosted at
> https://checker.apache.org/#META-files), however, it looks like
> checker.apache.org was dropped recently by infra, so the future is not
> clear.
> META files described who must sign what so the release to be considered to
> be an official one.
> For instance, JMeter still has a META file that specifies who must sign the
> releases: https://dist.apache.org/repos/dist/release/jmeter/META ,
> and there's a root file that specifies who signs per-project META files:
> https://dist.apache.org/repos/dist/release/META/ROOT
>
> The current META/ROOT contains
>
> # pmc calcite [chair] francischuang
> key bbe44e923a970ab7 signs calcite/META
>
> Vladimir
Re: Release managers
Posted by Vladimir Sitnikov <si...@gmail.com>.
Enrico>AFAIK in all of the apache projects I am contributing to as
committer every
Enrico>committer can sign the artifacts and be release manager
There existed META effort (which was hosted at
https://checker.apache.org/#META-files), however, it looks like
checker.apache.org was dropped recently by infra, so the future is not
clear.
META files described who must sign what so the release to be considered to
be an official one.
For instance, JMeter still has a META file that specifies who must sign the
releases: https://dist.apache.org/repos/dist/release/jmeter/META ,
and there's a root file that specifies who signs per-project META files:
https://dist.apache.org/repos/dist/release/META/ROOT
The current META/ROOT contains
# pmc calcite [chair] francischuang
key bbe44e923a970ab7 signs calcite/META
Vladimir
Re: Release managers
Posted by Enrico Olivelli <eo...@gmail.com>.
Hi,
AFAIK in all of the apache projects I am contributing to as committer every
committer can sign the artifacts and be release manager, the PMC has just
to VOTE or do some Apache reporter stuff or other bureaucratic stuff.
Is there any particular rule here in Calcite project?
If it is not the case I suggest to open the ability of signing artifacts to
any committer that has a GPG key valid and part of the Apache Web of Trust
Just my two sents
Enrico
Il mar 3 dic 2019, 02:11 Chunwei Lei <ch...@gmail.com> ha scritto:
> It's great to know that committers can be release manager.
> I volunteer to be the release manager if there is a chance.
>
> BTW, If Julian doesn't mind, I would like to take 1.24 ~~
>
>
> Best,
> Chunwei
>
>
> On Tue, Dec 3, 2019 at 5:43 AM Francis Chuang <fr...@apache.org>
> wrote:
>
> > Just a quick note regarding the move to Gradle as the build tool for
> > release. Thanks to Vladimir, the release process is almost entirely
> > automated and the rc can be built and automatically uploaded to ASF's
> > servers for voting using just one command: ./gradlew prepareVote -Prc=0
> > -Pasf This builds the artifacts, signs them and uploads them to
> > dist.apache.org.
> >
> > If the RM is a committer, then I think they should do a dry-run to test
> > the build, but not upload it. The asflike-release-environment[1] should
> > be used to try uploading the release to a test environment: ./gradlew
> > prepareVote -Prc=0.
> >
> > Once everything looks good, a PMC member should build and upload the
> > signed release using ./gradlew prepareVote -Prc=0 -Pasf and forward the
> > vote email to the RM.
> >
> > In the past, maven only built the artifacts and left the uploading of
> > the files as a manual exercise to the RM, so the process has changed
> > slightly this time.
> >
> > Francis
> >
> > [1] https://github.com/vlsi/asflike-release-environment
> >
> > On 3/12/2019 6:03 am, Julian Hyde wrote:
> > > I volunteer to do 1.24.
> > >
> > > There’s one part of the release process that only a PMC member can do -
> > namely, to sign the artifacts. But that’s only a small part of the
> process,
> > and you can easily get a PMC member to do it for you. A much larger part
> of
> > the process is the herding of cats (committers, bugs, pull requests,
> > release notes). So, yes, a committer can definitely be a release manager.
> > >
> > > How does the PMC decide which committers to promote to PMC members? We
> > are looking for people who help out around the project, going above and
> > beyond the basic needs of each task to make the project a better place.
> If
> > you are a committer, helping with the release process is a good way to
> earn
> > merit.
> > >
> > > Julian
> > >
> > >
> > >> On Dec 2, 2019, at 10:48 AM, Stamatis Zampetakis <za...@gmail.com>
> > wrote:
> > >>
> > >> Many thanks Haisheng and Danny for stepping up! I added you to the
> list.
> > >> There are two spots left, if nobody else comes up I will take one of
> > them!
> > >>
> > >> Release Target date Release manager
> > >> ======= =========== ===============
> > >> 1.19 2019-03 Kevin
> > >> 1.20 2019-06 Michael
> > >> 1.21 2019-09 Stamatis
> > >> ======= =========== ===============
> > >> 1.22 2019-12 Andrei
> > >> 1.23 2020-02 Haisheng
> > >> 1.24 2020-04 Julian
> > >> 1.25 2020-06 Danny
> > >> 1.26 2020-08
> > >>
> > >>
> > >>
> > >> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com>
> > wrote:
> > >>
> > >>> BTW,
> > >>> I can volunteer to be the release manager for v1.25 or v1.26.
> > >>>
> > >>> Best,
> > >>> Danny Chan
> > >>> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
> > >>>>
> > >>>> I can volunteer to be the release manager for v1.23 or v1.24.
> > >>>
> > >
> >
>
Re: Release managers
Posted by Chunwei Lei <ch...@gmail.com>.
Many thanks, Julian.
+1 for Avatica release-train.
Best,
Chunwei
On Thu, Dec 5, 2019 at 6:06 AM Julian Hyde <jh...@apache.org> wrote:
> Sure, take 1.24.
>
> By the way, if people are eager to be release managers, we might need some
> for Avatica release-train.
>
>
>
> > On Dec 2, 2019, at 5:11 PM, Chunwei Lei <ch...@gmail.com> wrote:
> >
> > It's great to know that committers can be release manager.
> > I volunteer to be the release manager if there is a chance.
> >
> > BTW, If Julian doesn't mind, I would like to take 1.24 ~~
> >
> >
> > Best,
> > Chunwei
> >
> >
> > On Tue, Dec 3, 2019 at 5:43 AM Francis Chuang <fr...@apache.org>
> > wrote:
> >
> >> Just a quick note regarding the move to Gradle as the build tool for
> >> release. Thanks to Vladimir, the release process is almost entirely
> >> automated and the rc can be built and automatically uploaded to ASF's
> >> servers for voting using just one command: ./gradlew prepareVote -Prc=0
> >> -Pasf This builds the artifacts, signs them and uploads them to
> >> dist.apache.org.
> >>
> >> If the RM is a committer, then I think they should do a dry-run to test
> >> the build, but not upload it. The asflike-release-environment[1] should
> >> be used to try uploading the release to a test environment: ./gradlew
> >> prepareVote -Prc=0.
> >>
> >> Once everything looks good, a PMC member should build and upload the
> >> signed release using ./gradlew prepareVote -Prc=0 -Pasf and forward the
> >> vote email to the RM.
> >>
> >> In the past, maven only built the artifacts and left the uploading of
> >> the files as a manual exercise to the RM, so the process has changed
> >> slightly this time.
> >>
> >> Francis
> >>
> >> [1] https://github.com/vlsi/asflike-release-environment
> >>
> >> On 3/12/2019 6:03 am, Julian Hyde wrote:
> >>> I volunteer to do 1.24.
> >>>
> >>> There’s one part of the release process that only a PMC member can do -
> >> namely, to sign the artifacts. But that’s only a small part of the
> process,
> >> and you can easily get a PMC member to do it for you. A much larger
> part of
> >> the process is the herding of cats (committers, bugs, pull requests,
> >> release notes). So, yes, a committer can definitely be a release
> manager.
> >>>
> >>> How does the PMC decide which committers to promote to PMC members? We
> >> are looking for people who help out around the project, going above and
> >> beyond the basic needs of each task to make the project a better
> place. If
> >> you are a committer, helping with the release process is a good way to
> earn
> >> merit.
> >>>
> >>> Julian
> >>>
> >>>
> >>>> On Dec 2, 2019, at 10:48 AM, Stamatis Zampetakis <za...@gmail.com>
> >> wrote:
> >>>>
> >>>> Many thanks Haisheng and Danny for stepping up! I added you to the
> list.
> >>>> There are two spots left, if nobody else comes up I will take one of
> >> them!
> >>>>
> >>>> Release Target date Release manager
> >>>> ======= =========== ===============
> >>>> 1.19 2019-03 Kevin
> >>>> 1.20 2019-06 Michael
> >>>> 1.21 2019-09 Stamatis
> >>>> ======= =========== ===============
> >>>> 1.22 2019-12 Andrei
> >>>> 1.23 2020-02 Haisheng
> >>>> 1.24 2020-04 Julian
> >>>> 1.25 2020-06 Danny
> >>>> 1.26 2020-08
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com>
> >> wrote:
> >>>>
> >>>>> BTW,
> >>>>> I can volunteer to be the release manager for v1.25 or v1.26.
> >>>>>
> >>>>> Best,
> >>>>> Danny Chan
> >>>>> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
> >>>>>>
> >>>>>> I can volunteer to be the release manager for v1.23 or v1.24.
> >>>>>
> >>>
> >>
>
>
Re: Release managers
Posted by Julian Hyde <jh...@apache.org>.
Sure, take 1.24.
By the way, if people are eager to be release managers, we might need some for Avatica release-train.
> On Dec 2, 2019, at 5:11 PM, Chunwei Lei <ch...@gmail.com> wrote:
>
> It's great to know that committers can be release manager.
> I volunteer to be the release manager if there is a chance.
>
> BTW, If Julian doesn't mind, I would like to take 1.24 ~~
>
>
> Best,
> Chunwei
>
>
> On Tue, Dec 3, 2019 at 5:43 AM Francis Chuang <fr...@apache.org>
> wrote:
>
>> Just a quick note regarding the move to Gradle as the build tool for
>> release. Thanks to Vladimir, the release process is almost entirely
>> automated and the rc can be built and automatically uploaded to ASF's
>> servers for voting using just one command: ./gradlew prepareVote -Prc=0
>> -Pasf This builds the artifacts, signs them and uploads them to
>> dist.apache.org.
>>
>> If the RM is a committer, then I think they should do a dry-run to test
>> the build, but not upload it. The asflike-release-environment[1] should
>> be used to try uploading the release to a test environment: ./gradlew
>> prepareVote -Prc=0.
>>
>> Once everything looks good, a PMC member should build and upload the
>> signed release using ./gradlew prepareVote -Prc=0 -Pasf and forward the
>> vote email to the RM.
>>
>> In the past, maven only built the artifacts and left the uploading of
>> the files as a manual exercise to the RM, so the process has changed
>> slightly this time.
>>
>> Francis
>>
>> [1] https://github.com/vlsi/asflike-release-environment
>>
>> On 3/12/2019 6:03 am, Julian Hyde wrote:
>>> I volunteer to do 1.24.
>>>
>>> There’s one part of the release process that only a PMC member can do -
>> namely, to sign the artifacts. But that’s only a small part of the process,
>> and you can easily get a PMC member to do it for you. A much larger part of
>> the process is the herding of cats (committers, bugs, pull requests,
>> release notes). So, yes, a committer can definitely be a release manager.
>>>
>>> How does the PMC decide which committers to promote to PMC members? We
>> are looking for people who help out around the project, going above and
>> beyond the basic needs of each task to make the project a better place. If
>> you are a committer, helping with the release process is a good way to earn
>> merit.
>>>
>>> Julian
>>>
>>>
>>>> On Dec 2, 2019, at 10:48 AM, Stamatis Zampetakis <za...@gmail.com>
>> wrote:
>>>>
>>>> Many thanks Haisheng and Danny for stepping up! I added you to the list.
>>>> There are two spots left, if nobody else comes up I will take one of
>> them!
>>>>
>>>> Release Target date Release manager
>>>> ======= =========== ===============
>>>> 1.19 2019-03 Kevin
>>>> 1.20 2019-06 Michael
>>>> 1.21 2019-09 Stamatis
>>>> ======= =========== ===============
>>>> 1.22 2019-12 Andrei
>>>> 1.23 2020-02 Haisheng
>>>> 1.24 2020-04 Julian
>>>> 1.25 2020-06 Danny
>>>> 1.26 2020-08
>>>>
>>>>
>>>>
>>>> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com>
>> wrote:
>>>>
>>>>> BTW,
>>>>> I can volunteer to be the release manager for v1.25 or v1.26.
>>>>>
>>>>> Best,
>>>>> Danny Chan
>>>>> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
>>>>>>
>>>>>> I can volunteer to be the release manager for v1.23 or v1.24.
>>>>>
>>>
>>
Re: Release managers
Posted by Chunwei Lei <ch...@gmail.com>.
It's great to know that committers can be release manager.
I volunteer to be the release manager if there is a chance.
BTW, If Julian doesn't mind, I would like to take 1.24 ~~
Best,
Chunwei
On Tue, Dec 3, 2019 at 5:43 AM Francis Chuang <fr...@apache.org>
wrote:
> Just a quick note regarding the move to Gradle as the build tool for
> release. Thanks to Vladimir, the release process is almost entirely
> automated and the rc can be built and automatically uploaded to ASF's
> servers for voting using just one command: ./gradlew prepareVote -Prc=0
> -Pasf This builds the artifacts, signs them and uploads them to
> dist.apache.org.
>
> If the RM is a committer, then I think they should do a dry-run to test
> the build, but not upload it. The asflike-release-environment[1] should
> be used to try uploading the release to a test environment: ./gradlew
> prepareVote -Prc=0.
>
> Once everything looks good, a PMC member should build and upload the
> signed release using ./gradlew prepareVote -Prc=0 -Pasf and forward the
> vote email to the RM.
>
> In the past, maven only built the artifacts and left the uploading of
> the files as a manual exercise to the RM, so the process has changed
> slightly this time.
>
> Francis
>
> [1] https://github.com/vlsi/asflike-release-environment
>
> On 3/12/2019 6:03 am, Julian Hyde wrote:
> > I volunteer to do 1.24.
> >
> > There’s one part of the release process that only a PMC member can do -
> namely, to sign the artifacts. But that’s only a small part of the process,
> and you can easily get a PMC member to do it for you. A much larger part of
> the process is the herding of cats (committers, bugs, pull requests,
> release notes). So, yes, a committer can definitely be a release manager.
> >
> > How does the PMC decide which committers to promote to PMC members? We
> are looking for people who help out around the project, going above and
> beyond the basic needs of each task to make the project a better place. If
> you are a committer, helping with the release process is a good way to earn
> merit.
> >
> > Julian
> >
> >
> >> On Dec 2, 2019, at 10:48 AM, Stamatis Zampetakis <za...@gmail.com>
> wrote:
> >>
> >> Many thanks Haisheng and Danny for stepping up! I added you to the list.
> >> There are two spots left, if nobody else comes up I will take one of
> them!
> >>
> >> Release Target date Release manager
> >> ======= =========== ===============
> >> 1.19 2019-03 Kevin
> >> 1.20 2019-06 Michael
> >> 1.21 2019-09 Stamatis
> >> ======= =========== ===============
> >> 1.22 2019-12 Andrei
> >> 1.23 2020-02 Haisheng
> >> 1.24 2020-04 Julian
> >> 1.25 2020-06 Danny
> >> 1.26 2020-08
> >>
> >>
> >>
> >> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com>
> wrote:
> >>
> >>> BTW,
> >>> I can volunteer to be the release manager for v1.25 or v1.26.
> >>>
> >>> Best,
> >>> Danny Chan
> >>> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
> >>>>
> >>>> I can volunteer to be the release manager for v1.23 or v1.24.
> >>>
> >
>
Re: Release managers
Posted by Francis Chuang <fr...@apache.org>.
Just a quick note regarding the move to Gradle as the build tool for
release. Thanks to Vladimir, the release process is almost entirely
automated and the rc can be built and automatically uploaded to ASF's
servers for voting using just one command: ./gradlew prepareVote -Prc=0
-Pasf This builds the artifacts, signs them and uploads them to
dist.apache.org.
If the RM is a committer, then I think they should do a dry-run to test
the build, but not upload it. The asflike-release-environment[1] should
be used to try uploading the release to a test environment: ./gradlew
prepareVote -Prc=0.
Once everything looks good, a PMC member should build and upload the
signed release using ./gradlew prepareVote -Prc=0 -Pasf and forward the
vote email to the RM.
In the past, maven only built the artifacts and left the uploading of
the files as a manual exercise to the RM, so the process has changed
slightly this time.
Francis
[1] https://github.com/vlsi/asflike-release-environment
On 3/12/2019 6:03 am, Julian Hyde wrote:
> I volunteer to do 1.24.
>
> There’s one part of the release process that only a PMC member can do - namely, to sign the artifacts. But that’s only a small part of the process, and you can easily get a PMC member to do it for you. A much larger part of the process is the herding of cats (committers, bugs, pull requests, release notes). So, yes, a committer can definitely be a release manager.
>
> How does the PMC decide which committers to promote to PMC members? We are looking for people who help out around the project, going above and beyond the basic needs of each task to make the project a better place. If you are a committer, helping with the release process is a good way to earn merit.
>
> Julian
>
>
>> On Dec 2, 2019, at 10:48 AM, Stamatis Zampetakis <za...@gmail.com> wrote:
>>
>> Many thanks Haisheng and Danny for stepping up! I added you to the list.
>> There are two spots left, if nobody else comes up I will take one of them!
>>
>> Release Target date Release manager
>> ======= =========== ===============
>> 1.19 2019-03 Kevin
>> 1.20 2019-06 Michael
>> 1.21 2019-09 Stamatis
>> ======= =========== ===============
>> 1.22 2019-12 Andrei
>> 1.23 2020-02 Haisheng
>> 1.24 2020-04 Julian
>> 1.25 2020-06 Danny
>> 1.26 2020-08
>>
>>
>>
>> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com> wrote:
>>
>>> BTW,
>>> I can volunteer to be the release manager for v1.25 or v1.26.
>>>
>>> Best,
>>> Danny Chan
>>> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
>>>>
>>>> I can volunteer to be the release manager for v1.23 or v1.24.
>>>
>
Re: Release managers
Posted by Julian Hyde <jh...@apache.org>.
I volunteer to do 1.24.
There’s one part of the release process that only a PMC member can do - namely, to sign the artifacts. But that’s only a small part of the process, and you can easily get a PMC member to do it for you. A much larger part of the process is the herding of cats (committers, bugs, pull requests, release notes). So, yes, a committer can definitely be a release manager.
How does the PMC decide which committers to promote to PMC members? We are looking for people who help out around the project, going above and beyond the basic needs of each task to make the project a better place. If you are a committer, helping with the release process is a good way to earn merit.
Julian
> On Dec 2, 2019, at 10:48 AM, Stamatis Zampetakis <za...@gmail.com> wrote:
>
> Many thanks Haisheng and Danny for stepping up! I added you to the list.
> There are two spots left, if nobody else comes up I will take one of them!
>
> Release Target date Release manager
> ======= =========== ===============
> 1.19 2019-03 Kevin
> 1.20 2019-06 Michael
> 1.21 2019-09 Stamatis
> ======= =========== ===============
> 1.22 2019-12 Andrei
> 1.23 2020-02 Haisheng
> 1.24 2020-04 Julian
> 1.25 2020-06 Danny
> 1.26 2020-08
>
>
>
> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com> wrote:
>
>> BTW,
>> I can volunteer to be the release manager for v1.25 or v1.26.
>>
>> Best,
>> Danny Chan
>> 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
>>>
>>> I can volunteer to be the release manager for v1.23 or v1.24.
>>
Re: Release managers
Posted by Michael Mior <mm...@apache.org>.
Actually, if Danny doesn't mind, I'll take 1.25 and he can take 1.26.
--
Michael Mior
mmior@apache.org
Le lun. 2 déc. 2019 à 13:48, Stamatis Zampetakis <za...@gmail.com> a écrit :
>
> Many thanks Haisheng and Danny for stepping up! I added you to the list.
> There are two spots left, if nobody else comes up I will take one of them!
>
> Release Target date Release manager
> ======= =========== ===============
> 1.19 2019-03 Kevin
> 1.20 2019-06 Michael
> 1.21 2019-09 Stamatis
> ======= =========== ===============
> 1.22 2019-12 Andrei
> 1.23 2020-02 Haisheng
> 1.24 2020-04
> 1.25 2020-06 Danny
> 1.26 2020-08
>
>
>
> On Sat, Nov 30, 2019 at 9:52 AM Danny Chan <yu...@gmail.com> wrote:
>
> > BTW,
> > I can volunteer to be the release manager for v1.25 or v1.26.
> >
> > Best,
> > Danny Chan
> > 在 2019年11月30日 +0800 PM2:13，dev@calcite.apache.org，写道：
> > >
> > > I can volunteer to be the release manager for v1.23 or v1.24.
> >