Re: Release 1.20 and release notes

2019-06-27 Thread Michael Mior
That was one of the reasons I was unsure where to put the script.
src/main/scripts is fine although it isn't obvious from that location
that it's unrelated to the use of Calcite. I'm not strongly opposed to
just pasting it in the documentation.
--
Michael Mior
mm...@apache.org

Le jeu. 27 juin 2019 à 14:40, Julian Hyde  a écrit :
>
> src/main/scripts would be an OK location.
>
> As this particular script is for a very limited audience - not developers, 
> but only for release managers - we could consider just putting the text into 
> the howto. I hate finding lots of scripts in projects when it is not clear 
> what is the audience or purpose of these scripts. We should definitely keep 
> development/release scripts clearly separate from scripts needed at runtime.
>
> Julian
>
>
> > On Jun 26, 2019, at 8:15 AM, Kevin Risden  wrote:
> >
> > Top level has src/ which has a bunch of config files for
> > checkstyle/forbidden-apis/etc. Might be a decent spot.
> >
> > Kevin Risden
> >
> >
> > On Wed, Jun 26, 2019 at 11:07 AM Michael Mior  wrote:
> >
> >> A Gradle task is great if we migrate to Gradle, but I don't think it's
> >> a compelling reason in itself. I would personally prefer to just have
> >> a copy of the script somewhere in the repo because the only purpose of
> >> putting it in the HOWTO would be so someone could copy and paste and
> >> run it. That said, I'm not sure where a good spot for such scripts to
> >> live would be in the folder hierarchy.
> >> --
> >> Michael Mior
> >> mm...@apache.org
> >>
> >> Le mar. 25 juin 2019 à 16:23, Julian Hyde  a écrit :
> >>>
> >>> Or just paste the script into HOWTO.
> >>>
> >>> It works fine on macOS, Linux and Windows/Cygwin, which I think covers
> >> it.
> >>>
> >>> Julian
> >>>
> >>>
>  On Jun 25, 2019, at 1:19 PM, Vladimir Sitnikov <
> >> sitnikov.vladi...@gmail.com> wrote:
> 
>  Michael>If we're going to use it, I think we
>  Michael>might as well have a copy in the Calcite repo.
> 
>  I have a plan here:
>  1) We migrate to Gradle
>  2) The script can be written as a Gradle task so it is easily
> >> available,
>  and it works in all OSes
> 
>  Vladimir
> >>>
> >>
>


Re: Release 1.20 and release notes

2019-06-27 Thread Julian Hyde
src/main/scripts would be an OK location.

As this particular script is for a very limited audience - not developers, but 
only for release managers - we could consider just putting the text into the 
howto. I hate finding lots of scripts in projects when it is not clear what is 
the audience or purpose of these scripts. We should definitely keep 
development/release scripts clearly separate from scripts needed at runtime.

Julian


> On Jun 26, 2019, at 8:15 AM, Kevin Risden  wrote:
> 
> Top level has src/ which has a bunch of config files for
> checkstyle/forbidden-apis/etc. Might be a decent spot.
> 
> Kevin Risden
> 
> 
> On Wed, Jun 26, 2019 at 11:07 AM Michael Mior  wrote:
> 
>> A Gradle task is great if we migrate to Gradle, but I don't think it's
>> a compelling reason in itself. I would personally prefer to just have
>> a copy of the script somewhere in the repo because the only purpose of
>> putting it in the HOWTO would be so someone could copy and paste and
>> run it. That said, I'm not sure where a good spot for such scripts to
>> live would be in the folder hierarchy.
>> --
>> Michael Mior
>> mm...@apache.org
>> 
>> Le mar. 25 juin 2019 à 16:23, Julian Hyde  a écrit :
>>> 
>>> Or just paste the script into HOWTO.
>>> 
>>> It works fine on macOS, Linux and Windows/Cygwin, which I think covers
>> it.
>>> 
>>> Julian
>>> 
>>> 
 On Jun 25, 2019, at 1:19 PM, Vladimir Sitnikov <
>> sitnikov.vladi...@gmail.com> wrote:
 
 Michael>If we're going to use it, I think we
 Michael>might as well have a copy in the Calcite repo.
 
 I have a plan here:
 1) We migrate to Gradle
 2) The script can be written as a Gradle task so it is easily
>> available,
 and it works in all OSes
 
 Vladimir
>>> 
>> 



Re: Release 1.20 and release notes

2019-06-26 Thread Kevin Risden
Top level has src/ which has a bunch of config files for
checkstyle/forbidden-apis/etc. Might be a decent spot.

Kevin Risden


On Wed, Jun 26, 2019 at 11:07 AM Michael Mior  wrote:

> A Gradle task is great if we migrate to Gradle, but I don't think it's
> a compelling reason in itself. I would personally prefer to just have
> a copy of the script somewhere in the repo because the only purpose of
> putting it in the HOWTO would be so someone could copy and paste and
> run it. That said, I'm not sure where a good spot for such scripts to
> live would be in the folder hierarchy.
> --
> Michael Mior
> mm...@apache.org
>
> Le mar. 25 juin 2019 à 16:23, Julian Hyde  a écrit :
> >
> > Or just paste the script into HOWTO.
> >
> > It works fine on macOS, Linux and Windows/Cygwin, which I think covers
> it.
> >
> > Julian
> >
> >
> > > On Jun 25, 2019, at 1:19 PM, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
> > >
> > > Michael>If we're going to use it, I think we
> > > Michael>might as well have a copy in the Calcite repo.
> > >
> > > I have a plan here:
> > > 1) We migrate to Gradle
> > > 2) The script can be written as a Gradle task so it is easily
> available,
> > > and it works in all OSes
> > >
> > > Vladimir
> >
>


Re: Release 1.20 and release notes

2019-06-26 Thread Michael Mior
A Gradle task is great if we migrate to Gradle, but I don't think it's
a compelling reason in itself. I would personally prefer to just have
a copy of the script somewhere in the repo because the only purpose of
putting it in the HOWTO would be so someone could copy and paste and
run it. That said, I'm not sure where a good spot for such scripts to
live would be in the folder hierarchy.
--
Michael Mior
mm...@apache.org

Le mar. 25 juin 2019 à 16:23, Julian Hyde  a écrit :
>
> Or just paste the script into HOWTO.
>
> It works fine on macOS, Linux and Windows/Cygwin, which I think covers it.
>
> Julian
>
>
> > On Jun 25, 2019, at 1:19 PM, Vladimir Sitnikov 
> >  wrote:
> >
> > Michael>If we're going to use it, I think we
> > Michael>might as well have a copy in the Calcite repo.
> >
> > I have a plan here:
> > 1) We migrate to Gradle
> > 2) The script can be written as a Gradle task so it is easily available,
> > and it works in all OSes
> >
> > Vladimir
>


Re: Release 1.20 and release notes

2019-06-25 Thread Julian Hyde
Or just paste the script into HOWTO.

It works fine on macOS, Linux and Windows/Cygwin, which I think covers it.

Julian


> On Jun 25, 2019, at 1:19 PM, Vladimir Sitnikov  
> wrote:
> 
> Michael>If we're going to use it, I think we
> Michael>might as well have a copy in the Calcite repo.
> 
> I have a plan here:
> 1) We migrate to Gradle
> 2) The script can be written as a Gradle task so it is easily available,
> and it works in all OSes
> 
> Vladimir



Re: Release 1.20 and release notes

2019-06-25 Thread Vladimir Sitnikov
Michael>If we're going to use it, I think we
Michael>might as well have a copy in the Calcite repo.

I have a plan here:
1) We migrate to Gradle
2) The script can be written as a Gradle task so it is easily available,
and it works in all OSes

Vladimir


Re: Release 1.20 and release notes

2019-06-25 Thread Michael Mior
Now that you mention it, I know you had mentioned it before, but I
don't see a link in the howto. If we're going to use it, I think we
might as well have a copy in the Calcite repo.
--
Michael Mior
mm...@apache.org

Le mar. 25 juin 2019 à 15:11, Julian Hyde  a écrit :
>
> Here’s the script I use:
>
> https://github.com/julianhyde/share/blob/master/tools/relNotes 
> <https://github.com/julianhyde/share/blob/master/tools/relNotes>
>
> I thought I’d linked to it from howto.
>
> Julian
>
>
>
>
> > On Jun 24, 2019, at 5:43 PM, Michael Mior  wrote:
> >
> > FWIW, the following one-liner did most of the work for me
> >
> > git log --format='format:%s' branch-1.19..branch-1.20 | sed
> > "s_\(CALCITE-[0-9]\+\)_ > href='https://issues.apache.org/jira/browse/\1'>\1_"
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le lun. 24 juin 2019 à 20:34, Francis Chuang
> >  a écrit :
> >>
> >> +1 to using a script to auto-generate a draft of the release notes. I
> >> was just thinking about this a few days ago, considering that there were
> >> more than 100 changes in this release.
> >>
> >> A script to generate each log item (with the correct link to the JIRA
> >> issue) would allow the RM to focus on categorizing each change into the
> >> appropriate change type and focus on the release itself.
> >>
> >> On 25/06/2019 10:31 am, Michael Mior wrote:
> >>> I've added back the names and I'm redeploying the site now. I think
> >>> I've said this before, but I don't really see the point of adding
> >>> contributor names into commit messages when they are already recorded
> >>> as the author of the commit. If the commit needs to be edited or
> >>> rebased, the author can be preserved.
> >>>
> >>> If we want to keep names in release notes, we could script things to
> >>> pull the commit author to generate a first draft of the release notes.
> >>> Really, I think such a script should exist anyway since putting
> >>> together the release notes can be rather tedious.
> >>>
> >>> --
> >>> Michael Mior
> >>> mm...@apache.org
> >>>
> >>> Le lun. 24 juin 2019 à 20:13, Julian Hyde  a écrit :
> >>>>
> >>>> In my opinion, we should add back the names to 1.20’s release notes.
> >>>>
> >>>> For further releases (and future commits), I’m happy to have a 
> >>>> discussion about our policy of adding names of non-committer 
> >>>> contributors to commit messages and release notes. It is, after all, 
> >>>> somewhat unusual and rather onerous. I can see both sides of the issue, 
> >>>> so I would not object if we kept the current policy or if we changed it.
> >>>>
> >>>> Julian
> >>>>
> >>>>
> >>>>> On Jun 24, 2019, at 1:28 PM, Michael Mior  wrote:
> >>>>>
> >>>>> I think the rotation is working out alright except that it's a
> >>>>> challenging sticking to a time-based schedule.
> >>>>>
> >>>>> As far as the release notes, you're correct that I generated these
> >>>>> from the commit log. I actually intentionally stripped out the names
> >>>>> since at the time they felt like noise. I'll acknowledge now that I
> >>>>> think that was a poor decision. It wasn't done with the desire for
> >>>>> people not be recognized as Calcite certainly wouldn't be where it is
> >>>>> without these contributions.
> >>>>>
> >>>>> I'll happily retroactively update these to add back the names in the
> >>>>> next day or two. A big thank you to all who contributed to the release
> >>>>> especially those who are not currently committers and do not have much
> >>>>> acknowledgement right now :)
> >>>>>
> >>>>> --
> >>>>> Michael Mior
> >>>>> mm...@apache.org <mailto:mm...@apache.org>
> >>>>>
> >>>>> Le lun. 24 juin 2019 à 14:10, Julian Hyde  >>>>> <mailto:jh...@apache.org>> a écrit :
> >>>>>>
> >>>>>> Just back for vacation... and it’s great to see a shiny new release. 
> >>>>>> Thank you, Michael, for getting it out of the door.
> >>>>>>
> >>>>>> 

Re: Release 1.20 and release notes

2019-06-25 Thread Julian Hyde
Here’s the script I use:

https://github.com/julianhyde/share/blob/master/tools/relNotes 
<https://github.com/julianhyde/share/blob/master/tools/relNotes>

I thought I’d linked to it from howto.

Julian




> On Jun 24, 2019, at 5:43 PM, Michael Mior  wrote:
> 
> FWIW, the following one-liner did most of the work for me
> 
> git log --format='format:%s' branch-1.19..branch-1.20 | sed
> "s_\(CALCITE-[0-9]\+\)_ href='https://issues.apache.org/jira/browse/\1'>\1_"
> 
> --
> Michael Mior
> mm...@apache.org
> 
> Le lun. 24 juin 2019 à 20:34, Francis Chuang
>  a écrit :
>> 
>> +1 to using a script to auto-generate a draft of the release notes. I
>> was just thinking about this a few days ago, considering that there were
>> more than 100 changes in this release.
>> 
>> A script to generate each log item (with the correct link to the JIRA
>> issue) would allow the RM to focus on categorizing each change into the
>> appropriate change type and focus on the release itself.
>> 
>> On 25/06/2019 10:31 am, Michael Mior wrote:
>>> I've added back the names and I'm redeploying the site now. I think
>>> I've said this before, but I don't really see the point of adding
>>> contributor names into commit messages when they are already recorded
>>> as the author of the commit. If the commit needs to be edited or
>>> rebased, the author can be preserved.
>>> 
>>> If we want to keep names in release notes, we could script things to
>>> pull the commit author to generate a first draft of the release notes.
>>> Really, I think such a script should exist anyway since putting
>>> together the release notes can be rather tedious.
>>> 
>>> --
>>> Michael Mior
>>> mm...@apache.org
>>> 
>>> Le lun. 24 juin 2019 à 20:13, Julian Hyde  a écrit :
>>>> 
>>>> In my opinion, we should add back the names to 1.20’s release notes.
>>>> 
>>>> For further releases (and future commits), I’m happy to have a discussion 
>>>> about our policy of adding names of non-committer contributors to commit 
>>>> messages and release notes. It is, after all, somewhat unusual and rather 
>>>> onerous. I can see both sides of the issue, so I would not object if we 
>>>> kept the current policy or if we changed it.
>>>> 
>>>> Julian
>>>> 
>>>> 
>>>>> On Jun 24, 2019, at 1:28 PM, Michael Mior  wrote:
>>>>> 
>>>>> I think the rotation is working out alright except that it's a
>>>>> challenging sticking to a time-based schedule.
>>>>> 
>>>>> As far as the release notes, you're correct that I generated these
>>>>> from the commit log. I actually intentionally stripped out the names
>>>>> since at the time they felt like noise. I'll acknowledge now that I
>>>>> think that was a poor decision. It wasn't done with the desire for
>>>>> people not be recognized as Calcite certainly wouldn't be where it is
>>>>> without these contributions.
>>>>> 
>>>>> I'll happily retroactively update these to add back the names in the
>>>>> next day or two. A big thank you to all who contributed to the release
>>>>> especially those who are not currently committers and do not have much
>>>>> acknowledgement right now :)
>>>>> 
>>>>> --
>>>>> Michael Mior
>>>>> mm...@apache.org <mailto:mm...@apache.org>
>>>>> 
>>>>> Le lun. 24 juin 2019 à 14:10, Julian Hyde >>>> <mailto:jh...@apache.org>> a écrit :
>>>>>> 
>>>>>> Just back for vacation... and it’s great to see a shiny new release. 
>>>>>> Thank you, Michael, for getting it out of the door.
>>>>>> 
>>>>>> Release management is a huge task these days. A few months ago [1] we 
>>>>>> agreed a rotation of release managers for a few releases ahead. I think 
>>>>>> this is working well; it makes sure that the work is spread among 
>>>>>> several people, and it also provides an incentive to get each release 
>>>>>> out early. (If, as release manager, you procrastinate, then the task 
>>>>>> gets larger.)
>>>>>> 
>>>>>> How do people feel the rotating release manager schedule is working out?
>>>>>> 
>>>>>> Someone else rem

Re: Release 1.20 and release notes

2019-06-24 Thread Michael Mior
FWIW, the following one-liner did most of the work for me

git log --format='format:%s' branch-1.19..branch-1.20 | sed
"s_\(CALCITE-[0-9]\+\)_\1_"

--
Michael Mior
mm...@apache.org

Le lun. 24 juin 2019 à 20:34, Francis Chuang
 a écrit :
>
> +1 to using a script to auto-generate a draft of the release notes. I
> was just thinking about this a few days ago, considering that there were
> more than 100 changes in this release.
>
> A script to generate each log item (with the correct link to the JIRA
> issue) would allow the RM to focus on categorizing each change into the
> appropriate change type and focus on the release itself.
>
> On 25/06/2019 10:31 am, Michael Mior wrote:
> > I've added back the names and I'm redeploying the site now. I think
> > I've said this before, but I don't really see the point of adding
> > contributor names into commit messages when they are already recorded
> > as the author of the commit. If the commit needs to be edited or
> > rebased, the author can be preserved.
> >
> > If we want to keep names in release notes, we could script things to
> > pull the commit author to generate a first draft of the release notes.
> > Really, I think such a script should exist anyway since putting
> > together the release notes can be rather tedious.
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le lun. 24 juin 2019 à 20:13, Julian Hyde  a écrit :
> >>
> >> In my opinion, we should add back the names to 1.20’s release notes.
> >>
> >> For further releases (and future commits), I’m happy to have a discussion 
> >> about our policy of adding names of non-committer contributors to commit 
> >> messages and release notes. It is, after all, somewhat unusual and rather 
> >> onerous. I can see both sides of the issue, so I would not object if we 
> >> kept the current policy or if we changed it.
> >>
> >> Julian
> >>
> >>
> >>> On Jun 24, 2019, at 1:28 PM, Michael Mior  wrote:
> >>>
> >>> I think the rotation is working out alright except that it's a
> >>> challenging sticking to a time-based schedule.
> >>>
> >>> As far as the release notes, you're correct that I generated these
> >>> from the commit log. I actually intentionally stripped out the names
> >>> since at the time they felt like noise. I'll acknowledge now that I
> >>> think that was a poor decision. It wasn't done with the desire for
> >>> people not be recognized as Calcite certainly wouldn't be where it is
> >>> without these contributions.
> >>>
> >>> I'll happily retroactively update these to add back the names in the
> >>> next day or two. A big thank you to all who contributed to the release
> >>> especially those who are not currently committers and do not have much
> >>> acknowledgement right now :)
> >>>
> >>> --
> >>> Michael Mior
> >>> mm...@apache.org <mailto:mm...@apache.org>
> >>>
> >>> Le lun. 24 juin 2019 à 14:10, Julian Hyde  >>> <mailto:jh...@apache.org>> a écrit :
> >>>>
> >>>> Just back for vacation... and it’s great to see a shiny new release. 
> >>>> Thank you, Michael, for getting it out of the door.
> >>>>
> >>>> Release management is a huge task these days. A few months ago [1] we 
> >>>> agreed a rotation of release managers for a few releases ahead. I think 
> >>>> this is working well; it makes sure that the work is spread among 
> >>>> several people, and it also provides an incentive to get each release 
> >>>> out early. (If, as release manager, you procrastinate, then the task 
> >>>> gets larger.)
> >>>>
> >>>> How do people feel the rotating release manager schedule is working out?
> >>>>
> >>>> Someone else remarked that the release notes are missing the names of 
> >>>> non-committer contributors. I think we should edit the release notes 
> >>>> retrospectively to include these names. Calling out new contributors 
> >>>> makes them want to stick around, do more, and eventually earn committer 
> >>>> status.
> >>>>
> >>>> Michael, How did you generate the release notes? It looks as if you 
> >>>> generated them from the commit log, not the JIRA cases  - which is the 
> >>>> right thing - but somehow those names got stripped.
> >>>>
> >>>> Julian
> >>>>
> >>>> [1] 
> >>>> https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
> >>>>  
> >>>> <https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E><https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
> >>>>  
> >>>> <https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E>>
> >>


Re: Release 1.20 and release notes

2019-06-24 Thread Francis Chuang
+1 to using a script to auto-generate a draft of the release notes. I 
was just thinking about this a few days ago, considering that there were 
more than 100 changes in this release.


A script to generate each log item (with the correct link to the JIRA 
issue) would allow the RM to focus on categorizing each change into the 
appropriate change type and focus on the release itself.


On 25/06/2019 10:31 am, Michael Mior wrote:

I've added back the names and I'm redeploying the site now. I think
I've said this before, but I don't really see the point of adding
contributor names into commit messages when they are already recorded
as the author of the commit. If the commit needs to be edited or
rebased, the author can be preserved.

If we want to keep names in release notes, we could script things to
pull the commit author to generate a first draft of the release notes.
Really, I think such a script should exist anyway since putting
together the release notes can be rather tedious.

--
Michael Mior
mm...@apache.org

Le lun. 24 juin 2019 à 20:13, Julian Hyde  a écrit :


In my opinion, we should add back the names to 1.20’s release notes.

For further releases (and future commits), I’m happy to have a discussion about 
our policy of adding names of non-committer contributors to commit messages and 
release notes. It is, after all, somewhat unusual and rather onerous. I can see 
both sides of the issue, so I would not object if we kept the current policy or 
if we changed it.

Julian



On Jun 24, 2019, at 1:28 PM, Michael Mior  wrote:

I think the rotation is working out alright except that it's a
challenging sticking to a time-based schedule.

As far as the release notes, you're correct that I generated these
from the commit log. I actually intentionally stripped out the names
since at the time they felt like noise. I'll acknowledge now that I
think that was a poor decision. It wasn't done with the desire for
people not be recognized as Calcite certainly wouldn't be where it is
without these contributions.

I'll happily retroactively update these to add back the names in the
next day or two. A big thank you to all who contributed to the release
especially those who are not currently committers and do not have much
acknowledgement right now :)

--
Michael Mior
mm...@apache.org <mailto:mm...@apache.org>

Le lun. 24 juin 2019 à 14:10, Julian Hyde mailto:jh...@apache.org>> a écrit :


Just back for vacation... and it’s great to see a shiny new release. Thank you, 
Michael, for getting it out of the door.

Release management is a huge task these days. A few months ago [1] we agreed a 
rotation of release managers for a few releases ahead. I think this is working 
well; it makes sure that the work is spread among several people, and it also 
provides an incentive to get each release out early. (If, as release manager, 
you procrastinate, then the task gets larger.)

How do people feel the rotating release manager schedule is working out?

Someone else remarked that the release notes are missing the names of 
non-committer contributors. I think we should edit the release notes 
retrospectively to include these names. Calling out new contributors makes them 
want to stick around, do more, and eventually earn committer status.

Michael, How did you generate the release notes? It looks as if you generated 
them from the commit log, not the JIRA cases  - which is the right thing - but 
somehow those names got stripped.

Julian

[1] 
https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
 
<https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E><https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
 
<https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E>>




Re: Release 1.20 and release notes

2019-06-24 Thread Michael Mior
I've added back the names and I'm redeploying the site now. I think
I've said this before, but I don't really see the point of adding
contributor names into commit messages when they are already recorded
as the author of the commit. If the commit needs to be edited or
rebased, the author can be preserved.

If we want to keep names in release notes, we could script things to
pull the commit author to generate a first draft of the release notes.
Really, I think such a script should exist anyway since putting
together the release notes can be rather tedious.

--
Michael Mior
mm...@apache.org

Le lun. 24 juin 2019 à 20:13, Julian Hyde  a écrit :
>
> In my opinion, we should add back the names to 1.20’s release notes.
>
> For further releases (and future commits), I’m happy to have a discussion 
> about our policy of adding names of non-committer contributors to commit 
> messages and release notes. It is, after all, somewhat unusual and rather 
> onerous. I can see both sides of the issue, so I would not object if we kept 
> the current policy or if we changed it.
>
> Julian
>
>
> > On Jun 24, 2019, at 1:28 PM, Michael Mior  wrote:
> >
> > I think the rotation is working out alright except that it's a
> > challenging sticking to a time-based schedule.
> >
> > As far as the release notes, you're correct that I generated these
> > from the commit log. I actually intentionally stripped out the names
> > since at the time they felt like noise. I'll acknowledge now that I
> > think that was a poor decision. It wasn't done with the desire for
> > people not be recognized as Calcite certainly wouldn't be where it is
> > without these contributions.
> >
> > I'll happily retroactively update these to add back the names in the
> > next day or two. A big thank you to all who contributed to the release
> > especially those who are not currently committers and do not have much
> > acknowledgement right now :)
> >
> > --
> > Michael Mior
> > mm...@apache.org <mailto:mm...@apache.org>
> >
> > Le lun. 24 juin 2019 à 14:10, Julian Hyde  > <mailto:jh...@apache.org>> a écrit :
> >>
> >> Just back for vacation... and it’s great to see a shiny new release. Thank 
> >> you, Michael, for getting it out of the door.
> >>
> >> Release management is a huge task these days. A few months ago [1] we 
> >> agreed a rotation of release managers for a few releases ahead. I think 
> >> this is working well; it makes sure that the work is spread among several 
> >> people, and it also provides an incentive to get each release out early. 
> >> (If, as release manager, you procrastinate, then the task gets larger.)
> >>
> >> How do people feel the rotating release manager schedule is working out?
> >>
> >> Someone else remarked that the release notes are missing the names of 
> >> non-committer contributors. I think we should edit the release notes 
> >> retrospectively to include these names. Calling out new contributors makes 
> >> them want to stick around, do more, and eventually earn committer status.
> >>
> >> Michael, How did you generate the release notes? It looks as if you 
> >> generated them from the commit log, not the JIRA cases  - which is the 
> >> right thing - but somehow those names got stripped.
> >>
> >> Julian
> >>
> >> [1] 
> >> https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
> >>  
> >> <https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E><https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
> >>  
> >> <https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E>>
>


Re: Release 1.20 and release notes

2019-06-24 Thread Julian Hyde
In my opinion, we should add back the names to 1.20’s release notes.

For further releases (and future commits), I’m happy to have a discussion about 
our policy of adding names of non-committer contributors to commit messages and 
release notes. It is, after all, somewhat unusual and rather onerous. I can see 
both sides of the issue, so I would not object if we kept the current policy or 
if we changed it.

Julian


> On Jun 24, 2019, at 1:28 PM, Michael Mior  wrote:
> 
> I think the rotation is working out alright except that it's a
> challenging sticking to a time-based schedule.
> 
> As far as the release notes, you're correct that I generated these
> from the commit log. I actually intentionally stripped out the names
> since at the time they felt like noise. I'll acknowledge now that I
> think that was a poor decision. It wasn't done with the desire for
> people not be recognized as Calcite certainly wouldn't be where it is
> without these contributions.
> 
> I'll happily retroactively update these to add back the names in the
> next day or two. A big thank you to all who contributed to the release
> especially those who are not currently committers and do not have much
> acknowledgement right now :)
> 
> --
> Michael Mior
> mm...@apache.org <mailto:mm...@apache.org>
> 
> Le lun. 24 juin 2019 à 14:10, Julian Hyde  <mailto:jh...@apache.org>> a écrit :
>> 
>> Just back for vacation... and it’s great to see a shiny new release. Thank 
>> you, Michael, for getting it out of the door.
>> 
>> Release management is a huge task these days. A few months ago [1] we agreed 
>> a rotation of release managers for a few releases ahead. I think this is 
>> working well; it makes sure that the work is spread among several people, 
>> and it also provides an incentive to get each release out early. (If, as 
>> release manager, you procrastinate, then the task gets larger.)
>> 
>> How do people feel the rotating release manager schedule is working out?
>> 
>> Someone else remarked that the release notes are missing the names of 
>> non-committer contributors. I think we should edit the release notes 
>> retrospectively to include these names. Calling out new contributors makes 
>> them want to stick around, do more, and eventually earn committer status.
>> 
>> Michael, How did you generate the release notes? It looks as if you 
>> generated them from the commit log, not the JIRA cases  - which is the right 
>> thing - but somehow those names got stripped.
>> 
>> Julian
>> 
>> [1] 
>> https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E><https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E>>



Re: Release 1.20 and release notes

2019-06-24 Thread Michael Mior
 I think the rotation is working out alright except that it's a
challenging sticking to a time-based schedule.

As far as the release notes, you're correct that I generated these
from the commit log. I actually intentionally stripped out the names
since at the time they felt like noise. I'll acknowledge now that I
think that was a poor decision. It wasn't done with the desire for
people not be recognized as Calcite certainly wouldn't be where it is
without these contributions.

I'll happily retroactively update these to add back the names in the
next day or two. A big thank you to all who contributed to the release
especially those who are not currently committers and do not have much
acknowledgement right now :)

--
Michael Mior
mm...@apache.org

Le lun. 24 juin 2019 à 14:10, Julian Hyde  a écrit :
>
> Just back for vacation... and it’s great to see a shiny new release. Thank 
> you, Michael, for getting it out of the door.
>
> Release management is a huge task these days. A few months ago [1] we agreed 
> a rotation of release managers for a few releases ahead. I think this is 
> working well; it makes sure that the work is spread among several people, and 
> it also provides an incentive to get each release out early. (If, as release 
> manager, you procrastinate, then the task gets larger.)
>
> How do people feel the rotating release manager schedule is working out?
>
> Someone else remarked that the release notes are missing the names of 
> non-committer contributors. I think we should edit the release notes 
> retrospectively to include these names. Calling out new contributors makes 
> them want to stick around, do more, and eventually earn committer status.
>
> Michael, How did you generate the release notes? It looks as if you generated 
> them from the commit log, not the JIRA cases  - which is the right thing - 
> but somehow those names got stripped.
>
> Julian
>
> [1] 
> https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E
>  
> 


Release 1.20 and release notes

2019-06-24 Thread Julian Hyde
Just back for vacation... and it’s great to see a shiny new release. Thank you, 
Michael, for getting it out of the door.

Release management is a huge task these days. A few months ago [1] we agreed a 
rotation of release managers for a few releases ahead. I think this is working 
well; it makes sure that the work is spread among several people, and it also 
provides an incentive to get each release out early. (If, as release manager, 
you procrastinate, then the task gets larger.)

How do people feel the rotating release manager schedule is working out?

Someone else remarked that the release notes are missing the names of 
non-committer contributors. I think we should edit the release notes 
retrospectively to include these names. Calling out new contributors makes them 
want to stick around, do more, and eventually earn committer status.

Michael, How did you generate the release notes? It looks as if you generated 
them from the commit log, not the JIRA cases  - which is the right thing - but 
somehow those names got stripped.

Julian

[1] 
https://lists.apache.org/thread.html/c6fba3f6585139ba6919baf71835d32eeea8ca187621aa5c06a26f8c@%3Cdev.calcite.apache.org%3E