Re: Capturing GEPs better

[Cédric Champeau]

This is typically what should live at groovy.apache.org :)

Le jeu. 11 oct. 2018 à 16:54, Guillaume Laforge  a
écrit :

> +1
> I like the idea of having GEPs on the wiki side of the site.
>
> Le jeu. 11 oct. 2018 à 15:35, Paul King  a écrit :
>
>> This is an example of what I had in mind:
>> http://groovy-lang.org/wiki/GEP-1.html
>>
>> On Thu, Oct 11, 2018 at 6:21 PM Paul King  wrote:
>>
>>> One of the things which I don't believe we ever brought across from the
>>> codehaus move was the GEP part of the codehaus wiki:
>>>
>>>
>>> https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal
>>>
>>> We certainly have merged the outcomes from the GEPs into the language as
>>> needed and parts of the doco and some tests capture bits of the GEP design
>>> and outcomes as does some of the issues in Jira but not the original GEPs.
>>>
>>> I was going to try to bring those across and convert to asciidoc on the
>>> way - for historical purposes but also to be in a better position to cater
>>> for new ones. We have made do with using Jira but I'm not sure that is the
>>> best way to capture this kind of information.
>>>
>>> I was thinking under groovy-website rather than the core repo. Thoughts?
>>>
>>> Cheers, Paul.
>>>
>>>

Re: Capturing GEPs better

[Guillaume Laforge]

Or perhaps only the work in progress GEPs vs the final ones?

Le jeu. 11 oct. 2018 à 15:57, Cédric Champeau  a
écrit :

> This is typically what should live at groovy.apache.org :)
>
> Le jeu. 11 oct. 2018 à 16:54, Guillaume Laforge  a
> écrit :
>
>> +1
>> I like the idea of having GEPs on the wiki side of the site.
>>
>> Le jeu. 11 oct. 2018 à 15:35, Paul King  a écrit :
>>
>>> This is an example of what I had in mind:
>>> http://groovy-lang.org/wiki/GEP-1.html
>>>
>>> On Thu, Oct 11, 2018 at 6:21 PM Paul King  wrote:
>>>
 One of the things which I don't believe we ever brought across from the
 codehaus move was the GEP part of the codehaus wiki:


 https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal

 We certainly have merged the outcomes from the GEPs into the language
 as needed and parts of the doco and some tests capture bits of the GEP
 design and outcomes as does some of the issues in Jira but not the original
 GEPs.

 I was going to try to bring those across and convert to asciidoc on the
 way - for historical purposes but also to be in a better position to cater
 for new ones. We have made do with using Jira but I'm not sure that is the
 best way to capture this kind of information.

 I was thinking under groovy-website rather than the core repo. Thoughts?

 Cheers, Paul.

Re: Capturing GEPs better

[Jochen Theodorou]

+1 or the idea and +1 for groovy.apache.org

On 11.10.2018 16:56, Cédric Champeau wrote:
This is typically what should live at groovy.apache.org 
 :)


Le jeu. 11 oct. 2018 à 16:54, Guillaume Laforge > a écrit :


+1
I like the idea of having GEPs on the wiki side of the site.

Le jeu. 11 oct. 2018 à 15:35, Paul King mailto:pa...@asert.com.au>> a écrit :

This is an example of what I had in mind:
http://groovy-lang.org/wiki/GEP-1.html

On Thu, Oct 11, 2018 at 6:21 PM Paul King mailto:pa...@asert.com.au>> wrote:

One of the things which I don't believe we ever brought
across from the codehaus move was the GEP part of the
codehaus wiki:


https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal

We certainly have merged the outcomes from the GEPs into the
language as needed and parts of the doco and some tests
capture bits of the GEP design and outcomes as does some of
the issues in Jira but not the original GEPs.

I was going to try to bring those across and convert to
asciidoc on the way - for historical purposes but also to be
in a better position to cater for new ones. We have made do
with using Jira but I'm not sure that is the best way to
capture this kind of information.

I was thinking under groovy-website rather than the core
repo. Thoughts?

Cheers, Paul.

Re: Capturing GEPs better

[Jochen Theodorou]

On 11.10.2018 16:59, Guillaume Laforge wrote:

Or perhaps only the work in progress GEPs vs the final ones?


if we can without too much effort I would bring over all of them, so 
people can have more examples.. and sometimes they are interesting for 
historic reasons


bye Jochen

Re: Capturing GEPs better

[Paul King]

Being on groovy.apache.org is the plan. Just haven't completed the work to
make that site automatically be produced as of yet.

On Fri, Oct 12, 2018 at 2:56 AM Jochen Theodorou  wrote:

> +1 or the idea and +1 for groovy.apache.org
>
> On 11.10.2018 16:56, Cédric Champeau wrote:
> > This is typically what should live at groovy.apache.org
> >  :)
> >
> > Le jeu. 11 oct. 2018 à 16:54, Guillaume Laforge  > > a écrit :
> >
> > +1
> > I like the idea of having GEPs on the wiki side of the site.
> >
> > Le jeu. 11 oct. 2018 à 15:35, Paul King  > > a écrit :
> >
> > This is an example of what I had in mind:
> > http://groovy-lang.org/wiki/GEP-1.html
> >
> > On Thu, Oct 11, 2018 at 6:21 PM Paul King  > > wrote:
> >
> > One of the things which I don't believe we ever brought
> > across from the codehaus move was the GEP part of the
> > codehaus wiki:
> >
> >
> https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal
> >
> > We certainly have merged the outcomes from the GEPs into the
> > language as needed and parts of the doco and some tests
> > capture bits of the GEP design and outcomes as does some of
> > the issues in Jira but not the original GEPs.
> >
> > I was going to try to bring those across and convert to
> > asciidoc on the way - for historical purposes but also to be
> > in a better position to cater for new ones. We have made do
> > with using Jira but I'm not sure that is the best way to
> > capture this kind of information.
> >
> > I was thinking under groovy-website rather than the core
> > repo. Thoughts?
> >
> > Cheers, Paul.
> >
>
>

Re: Capturing GEPs better

[MG]

+1 on this, definitely a good idea, will greatly help with the same 
topic being be raised and discussed on the ML, Stackoverflow, in blogs, 
etc time and time again, with most of the discussion (and hopefully at 
least some conclusion) being lost in time in the end.
Just must make an effort that newcomers to Groovy are aware that this 
exists...



On 11.10.2018 10:21, Paul King wrote:
One of the things which I don't believe we ever brought across from 
the codehaus move was the GEP part of the codehaus wiki:


https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal

We certainly have merged the outcomes from the GEPs into the language 
as needed and parts of the doco and some tests capture bits of the GEP 
design and outcomes as does some of the issues in Jira but not the 
original GEPs.


I was going to try to bring those across and convert to asciidoc on 
the way - for historical purposes but also to be in a better position 
to cater for new ones. We have made do with using Jira but I'm not 
sure that is the best way to capture this kind of information.


I was thinking under groovy-website rather than the core repo. Thoughts?

Cheers, Paul.

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

[John Wagenleitner]

+1 (binding)

On Wed, Oct 10, 2018 at 10:55 PM Paul King  wrote:

> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.3 release!
>
> This release includes 52 bug fixes/improvements as outlined in the
> changelog:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343876
>
> Tag:
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_3
> Tag commit id: 676d5a7d66f540a831779c208878df39d08938b5
>
> The artifacts to be voted on are located as follows (r30001).
> Source release:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/sources
> Convenience binaries:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/distribution
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.3.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.3
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.3 because...
>
> Here is my vote:
>
> +1 (binding)
>
>

Re: [VOTE] Release Apache Groovy 2.5.3 (take 2)

[Guillaume Laforge]

+1 (binding)

No problem with my usual smoke tests.

Guillaume


On Thu, Oct 11, 2018 at 6:55 AM Paul King  wrote:

> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.3 release!
>
> This release includes 52 bug fixes/improvements as outlined in the
> changelog:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12343876
>
> Tag:
> https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=refs/tags/GROOVY_2_5_3
> Tag commit id: 676d5a7d66f540a831779c208878df39d08938b5
>
> The artifacts to be voted on are located as follows (r30001).
> Source release:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/sources
> Convenience binaries:
> https://dist.apache.org/repos/dist/dev/groovy/2.5.3/distribution
>
> Release artifacts are signed with a key from the following file:
> https://dist.apache.org/repos/dist/dev/groovy/KEYS
>
> Please vote on releasing this package as Apache Groovy 2.5.3.
>
> Reminder on ASF release approval requirements for PMC members:
> http://www.apache.org/legal/release-policy.html#release-approval
> Hints on validating checksums/signatures (but replace md5sum with
> sha256sum):
> https://www.apache.org/info/verification.html
>
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 PMC votes are cast.
>
> [ ] +1 Release Apache Groovy 2.5.3
> [ ]  0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not release Apache Groovy 2.5.3 because...
>
> Here is my vote:
>
> +1 (binding)
>
>

-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Twitter: @glaforge 

Capturing GEPs better

[Paul King]

One of the things which I don't believe we ever brought across from the
codehaus move was the GEP part of the codehaus wiki:

https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal

We certainly have merged the outcomes from the GEPs into the language as
needed and parts of the doco and some tests capture bits of the GEP design
and outcomes as does some of the issues in Jira but not the original GEPs.

I was going to try to bring those across and convert to asciidoc on the way
- for historical purposes but also to be in a better position to cater for
new ones. We have made do with using Jira but I'm not sure that is the best
way to capture this kind of information.

I was thinking under groovy-website rather than the core repo. Thoughts?

Cheers, Paul.

Re: Capturing GEPs better

[Paul King]

This is an example of what I had in mind:
http://groovy-lang.org/wiki/GEP-1.html

On Thu, Oct 11, 2018 at 6:21 PM Paul King  wrote:

> One of the things which I don't believe we ever brought across from the
> codehaus move was the GEP part of the codehaus wiki:
>
>
> https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal
>
> We certainly have merged the outcomes from the GEPs into the language as
> needed and parts of the doco and some tests capture bits of the GEP design
> and outcomes as does some of the issues in Jira but not the original GEPs.
>
> I was going to try to bring those across and convert to asciidoc on the
> way - for historical purposes but also to be in a better position to cater
> for new ones. We have made do with using Jira but I'm not sure that is the
> best way to capture this kind of information.
>
> I was thinking under groovy-website rather than the core repo. Thoughts?
>
> Cheers, Paul.
>
>

Re: Capturing GEPs better

[Guillaume Laforge]

+1
I like the idea of having GEPs on the wiki side of the site.

Le jeu. 11 oct. 2018 à 15:35, Paul King  a écrit :

> This is an example of what I had in mind:
> http://groovy-lang.org/wiki/GEP-1.html
>
> On Thu, Oct 11, 2018 at 6:21 PM Paul King  wrote:
>
>> One of the things which I don't believe we ever brought across from the
>> codehaus move was the GEP part of the codehaus wiki:
>>
>>
>> https://web.archive.org/web/20150504145954/http://docs.codehaus.org/display/GroovyJSR/Groovy+Enhancement+Proposal
>>
>> We certainly have merged the outcomes from the GEPs into the language as
>> needed and parts of the doco and some tests capture bits of the GEP design
>> and outcomes as does some of the issues in Jira but not the original GEPs.
>>
>> I was going to try to bring those across and convert to asciidoc on the
>> way - for historical purposes but also to be in a better position to cater
>> for new ones. We have made do with using Jira but I'm not sure that is the
>> best way to capture this kind of information.
>>
>> I was thinking under groovy-website rather than the core repo. Thoughts?
>>
>> Cheers, Paul.
>>
>>