You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2015/10/15 11:09:34 UTC
[mentors] experimental graduation maturity assessment in view of
graduating Groovy
Hi mentors + community,
FYI I have started an assessment of Groovy's readiness for graduation,
based on the ASF project maturity model, here:
https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
If hope you don't mind me "polluting" the code repository with this, I
thought it's good to put this in a place where all committers can
contribute easily.
For now this is just an experiment of mine, meant to help the ASF (at
large: community, mentors, Incubator PMC, Board of Directors) evaluate
the readiness of podlings. If we like it we can include it as an
appendix in the Incubator PMC graduation vote.
As usual, feedback and contributions are welcome, I'm hoping to finish
my own initial assessment by tomorrow, for now this is just a
skeleton.
-Bertrand
Re: [mentors] experimental graduation maturity assessment in view
of graduating Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Fri, 2015-10-16 at 18:38 +0200, Jochen Theodorou wrote:
> […]
>
> I wonder if one point might be missing: checking the name of the
> project
> for trademarks.
>
> Which is imho also a point we have to still clear officially. how do
> we
> do that again?
As far as I am aware, but I am not a lawyer, in England and Wales, and
Scotland, you cannot trademark a word per se. So at least in this
jurisdiction I cannot imagine anyone has any form of trademark on
"Groovy"; it wouldn't be allowed.
On the other hand, the Groovy logo, whilst not formally registered
anywhere as far as I know, will have de facto trademark status for
having been used unchallenged for many years. To change the logo to
somehow incorporate Apache explicitly will be non-trivial.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Konstantin Boudnik <co...@apache.org>.
Hi Paul.
Yes, it is a requirement for graduation. In my view it is ready to be
resolved, as I haven't been able to find any evidences of "Apache Groove"
being used elsewhere. I probably will mark it as closed in a couple of days,
if I don't hear otherwise.
BTW, anyone can chime on the ticket, if you will.
Cos
On Thu, Oct 22, 2015 at 05:29PM, Paul King wrote:
> Thanks Cos, is there a typical timeframe these are resolved in? Is it
> a requirement for graduation or independent?
>
> Thanks, Paul.
>
> On Sat, Oct 17, 2015 at 3:03 AM, Konstantin Boudnik <co...@apache.org> wrote:
> > On Fri, Oct 16, 2015 at 06:38PM, Jochen Theodorou wrote:
> >> On 15.10.2015 11:09, Bertrand Delacretaz wrote:
> >> >Hi mentors + community,
> >> >
> >> >FYI I have started an assessment of Groovy's readiness for graduation,
> >> >based on the ASF project maturity model, here:
> >> >
> >> >https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
> >>
> >> I wonder if one point might be missing: checking the name of the
> >> project for trademarks.
> >
> > Good catch. I am looking PODLINGNAMESEARCH project and I don't see a ticket
> > for the name check. I have opened PODLINGNAMESEARCH-88 and checked a few
> > sources for the possible name clash. Feel free to add more.
> >
> > Cos
> >
> >> Which is imho also a point we have to still clear officially. how do
> >> we do that again?
> >>
> >> bye blackdrag
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
Thanks Cos, is there a typical timeframe these are resolved in? Is it
a requirement for graduation or independent?
Thanks, Paul.
On Sat, Oct 17, 2015 at 3:03 AM, Konstantin Boudnik <co...@apache.org> wrote:
> On Fri, Oct 16, 2015 at 06:38PM, Jochen Theodorou wrote:
>> On 15.10.2015 11:09, Bertrand Delacretaz wrote:
>> >Hi mentors + community,
>> >
>> >FYI I have started an assessment of Groovy's readiness for graduation,
>> >based on the ASF project maturity model, here:
>> >
>> >https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
>>
>> I wonder if one point might be missing: checking the name of the
>> project for trademarks.
>
> Good catch. I am looking PODLINGNAMESEARCH project and I don't see a ticket
> for the name check. I have opened PODLINGNAMESEARCH-88 and checked a few
> sources for the possible name clash. Feel free to add more.
>
> Cos
>
>> Which is imho also a point we have to still clear officially. how do
>> we do that again?
>>
>> bye blackdrag
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Konstantin Boudnik <co...@apache.org>.
On Fri, Oct 16, 2015 at 06:38PM, Jochen Theodorou wrote:
> On 15.10.2015 11:09, Bertrand Delacretaz wrote:
> >Hi mentors + community,
> >
> >FYI I have started an assessment of Groovy's readiness for graduation,
> >based on the ASF project maturity model, here:
> >
> >https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
>
> I wonder if one point might be missing: checking the name of the
> project for trademarks.
Good catch. I am looking PODLINGNAMESEARCH project and I don't see a ticket
for the name check. I have opened PODLINGNAMESEARCH-88 and checked a few
sources for the possible name clash. Feel free to add more.
Cos
> Which is imho also a point we have to still clear officially. how do
> we do that again?
>
> bye blackdrag
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Jochen Theodorou <bl...@gmx.org>.
On 15.10.2015 11:09, Bertrand Delacretaz wrote:
> Hi mentors + community,
>
> FYI I have started an assessment of Groovy's readiness for graduation,
> based on the ASF project maturity model, here:
>
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
I wonder if one point might be missing: checking the name of the project
for trademarks.
Which is imho also a point we have to still clear officially. how do we
do that again?
bye blackdrag
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Konstantin Boudnik <co...@apache.org>.
Then we can be certain that document is correct, after all ;)
On Thu, Oct 15, 2015 at 09:07PM, Cédric Champeau wrote:
> The only problem is that each change triggers a CI build ;)
> 2015-10-15 20:59 GMT+02:00 Konstantin Boudnik <co...@apache.org>:
>
> On Thu, Oct 15, 2015 at 01:52PM, Bertrand Delacretaz wrote:
> > On Thu, Oct 15, 2015 at 11:58 AM, CA(c)dric Champeau
> > <ce...@gmail.com> wrote:
> > > ...I like the idea of having concrete, non
> > > subjective criteria for graduating, even if it could mean in our
> case that
> > > graduating would be "stricter"....
> >
> > We're down to 4 TODOs already, and all of them look quite easy to fix.
>
> Looks like 3, actually, and the rest seems to be in order!A Last time
> we did
> it on the project website, but having this in the source code is even
> better,
> IMO!A Thanks a lot for taking a lead on this!
>
> Cos
Re: [mentors] experimental graduation maturity assessment in view
of graduating Groovy
Posted by Russel Winder <ru...@winder.org.uk>.
On Sat, 2015-10-17 at 00:15 +1000, Paul King wrote:
> Sorry, forgot to mention that one. As per licenses/jsr166y-BINZIP.txt
> (EG = Expert Group):
>
> ---
> JSR166y License (optionally used by the optional GPars dependency)
>
> This product bundles the jsr166y jar (containing works from
> the JSR-166 EG, Doug Lea, and Jason T. Greene) made available in
> the public domain. For details, see licenses/jsr166y-license.
> ---
>
> Also, I think the links on the Groovy site should be very close to
> what we want now.
Is it intended that the gpars artefact is part of the distribution? If
not then the jsr166y artefact need not be part of the distribution. If
gpars is in the distribution, then do we need to note that it contains
a vendor fork of extra166y for legal purity reasons?
We have never worried about these levels of detail before as most
things were ASL 2.0 and Doug's stuff is all public domain – well except
that you can't have public domain in some jurisdictions I understand.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
Yes, assemble.gradle generates the 11 different LICENSE files and 9
different NOTICE files that we need to cover our various (mostly jar
and binary convenience zip) artifacts with all the picky details.
The gradle license report plugin though (at least in it's current
form) is just a cross-check. It lists optional dependencies of
optional dependencies, e.g. Multiverse. Multiverse, again just as an
example, happens to be open source and ASLv2 but we don't require or
include that in any of our jars/convenience binaries anywhere so it
doesn't appear in our N&L files. (And of course we can help make that
plugin smarter over time in terms of what it understands and reports.)
On Sat, Oct 17, 2015 at 12:52 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> Yes, Emmanuel. And that's exactly what assemble.gradle enforces.
>
>
> 2015-10-16 16:51 GMT+02:00 Emmanuel Lécharny <el...@gmail.com>:
>>
>> Le 16/10/15 16:43, Paul King a écrit :
>> > On Sat, Oct 17, 2015 at 12:38 AM, Cédric Champeau
>> > <ce...@gmail.com> wrote:
>> >> Such a list was written for the proposal:
>> >> https://wiki.apache.org/incubator/GroovyProposal
>> >>
>> >> Since then we have made a great effort towards generating different
>> >> LICENSE
>> >> files depending on the artifacts we produce. Everything can be found in
>> >> the
>> >> license directory:
>> >> https://github.com/apache/incubator-groovy/tree/master/licenses
>> >>
>> >> And assembling the licenses depending on the artifacts is done here:
>> >>
>> >> https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
>> >>
>> >> I am kind of reluctant to write the list explicitly where we have tools
>> >> to
>> >> check everything (Rat plugin, license report): the list could become
>> >> obsolete very easily without us noticing.
>> > Agreed. Our source dependency license/notice info is already in the
>> > source release. Our runtime dependency license/notice info is already
>> > in the respective jars/zips. RAT does a check on our source files. And
>> > now the gradle license report plugin does a cross-check on what we
>> > already know from the license files. I believe we are well and truly
>> > covered.
>>
>> To be clear :
>> - the source packages must contain the N&L files listing all the
>> contained depeencies (and teh required N&L for those dependencies-
>> - the binary packages that are distributed must also contain the same
>> things
>> - the dependencies used to build Groovy are not part of what must be
>> listed (although it might be cool to do so), unless they generates some
>> code or documentation (typically what antlr does)
>>
>> The rational being that anyone who want to download, and embed groovy in
>> their own product must be aware of those dependencies. If some of them
>> are optional, then it should be clearly stated somewhere (and solhere
>> means N&L).
>>
>> Keep in mind that many companies are very picky about those things.
>>
>> Anyway, I think it's already correctly covered, as of today.
>>
>> Thanks!
>>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
Yes, Emmanuel. And that's exactly what assemble.gradle enforces.
2015-10-16 16:51 GMT+02:00 Emmanuel Lécharny <el...@gmail.com>:
> Le 16/10/15 16:43, Paul King a écrit :
> > On Sat, Oct 17, 2015 at 12:38 AM, Cédric Champeau
> > <ce...@gmail.com> wrote:
> >> Such a list was written for the proposal:
> >> https://wiki.apache.org/incubator/GroovyProposal
> >>
> >> Since then we have made a great effort towards generating different
> LICENSE
> >> files depending on the artifacts we produce. Everything can be found in
> the
> >> license directory:
> >> https://github.com/apache/incubator-groovy/tree/master/licenses
> >>
> >> And assembling the licenses depending on the artifacts is done here:
> >>
> https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
> >>
> >> I am kind of reluctant to write the list explicitly where we have tools
> to
> >> check everything (Rat plugin, license report): the list could become
> >> obsolete very easily without us noticing.
> > Agreed. Our source dependency license/notice info is already in the
> > source release. Our runtime dependency license/notice info is already
> > in the respective jars/zips. RAT does a check on our source files. And
> > now the gradle license report plugin does a cross-check on what we
> > already know from the license files. I believe we are well and truly
> > covered.
>
> To be clear :
> - the source packages must contain the N&L files listing all the
> contained depeencies (and teh required N&L for those dependencies-
> - the binary packages that are distributed must also contain the same
> things
> - the dependencies used to build Groovy are not part of what must be
> listed (although it might be cool to do so), unless they generates some
> code or documentation (typically what antlr does)
>
> The rational being that anyone who want to download, and embed groovy in
> their own product must be aware of those dependencies. If some of them
> are optional, then it should be clearly stated somewhere (and solhere
> means N&L).
>
> Keep in mind that many companies are very picky about those things.
>
> Anyway, I think it's already correctly covered, as of today.
>
> Thanks!
>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 16/10/15 16:43, Paul King a écrit :
> On Sat, Oct 17, 2015 at 12:38 AM, Cédric Champeau
> <ce...@gmail.com> wrote:
>> Such a list was written for the proposal:
>> https://wiki.apache.org/incubator/GroovyProposal
>>
>> Since then we have made a great effort towards generating different LICENSE
>> files depending on the artifacts we produce. Everything can be found in the
>> license directory:
>> https://github.com/apache/incubator-groovy/tree/master/licenses
>>
>> And assembling the licenses depending on the artifacts is done here:
>> https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
>>
>> I am kind of reluctant to write the list explicitly where we have tools to
>> check everything (Rat plugin, license report): the list could become
>> obsolete very easily without us noticing.
> Agreed. Our source dependency license/notice info is already in the
> source release. Our runtime dependency license/notice info is already
> in the respective jars/zips. RAT does a check on our source files. And
> now the gradle license report plugin does a cross-check on what we
> already know from the license files. I believe we are well and truly
> covered.
To be clear :
- the source packages must contain the N&L files listing all the
contained depeencies (and teh required N&L for those dependencies-
- the binary packages that are distributed must also contain the same things
- the dependencies used to build Groovy are not part of what must be
listed (although it might be cool to do so), unless they generates some
code or documentation (typically what antlr does)
The rational being that anyone who want to download, and embed groovy in
their own product must be aware of those dependencies. If some of them
are optional, then it should be clearly stated somewhere (and solhere
means N&L).
Keep in mind that many companies are very picky about those things.
Anyway, I think it's already correctly covered, as of today.
Thanks!
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
On Sat, Oct 17, 2015 at 12:38 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> Such a list was written for the proposal:
> https://wiki.apache.org/incubator/GroovyProposal
>
> Since then we have made a great effort towards generating different LICENSE
> files depending on the artifacts we produce. Everything can be found in the
> license directory:
> https://github.com/apache/incubator-groovy/tree/master/licenses
>
> And assembling the licenses depending on the artifacts is done here:
> https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
>
> I am kind of reluctant to write the list explicitly where we have tools to
> check everything (Rat plugin, license report): the list could become
> obsolete very easily without us noticing.
Agreed. Our source dependency license/notice info is already in the
source release. Our runtime dependency license/notice info is already
in the respective jars/zips. RAT does a check on our source files. And
now the gradle license report plugin does a cross-check on what we
already know from the license files. I believe we are well and truly
covered.
Cheers, Paul.
> 2015-10-16 16:23 GMT+02:00 Bertrand Delacretaz <bd...@apache.org>:
>>
>> On Fri, Oct 16, 2015 at 4:18 PM, Cédric Champeau
>> <ce...@gmail.com> wrote:
>> > Should we mention that most of the dependencies are optional, runtime
>> > dependencies and not source dependencies....
>>
>> A precise list of what's optional or required could be useful, but
>> saying "most dependencies" does not bring much IMO.
>>
>> -Bertrand
>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Oct 16, 2015 at 4:38 PM, Cédric Champeau
<ce...@gmail.com> wrote:
> Such a list was written for the proposal:
> https://wiki.apache.org/incubator/GroovyProposal
ok, that's a good basis.
I'll mention that and add the links to the licenses and assemble.gradle info.
> ...I am kind of reluctant to write the list explicitly where we have tools to
> check everything (Rat plugin, license report): the list could become
> obsolete very easily without us noticing...
Sure, my suggestion to have a list was just in reaction to say "most
licenses"...
I'll update the maturity document and resolve LC20 and LC30 with that.
-Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
Such a list was written for the proposal:
https://wiki.apache.org/incubator/GroovyProposal
Since then we have made a great effort towards generating different LICENSE
files depending on the artifacts we produce. Everything can be found in the
license directory:
https://github.com/apache/incubator-groovy/tree/master/licenses
And assembling the licenses depending on the artifacts is done here:
https://github.com/apache/incubator-groovy/blob/master/gradle/assemble.gradle
I am kind of reluctant to write the list explicitly where we have tools to
check everything (Rat plugin, license report): the list could become
obsolete very easily without us noticing.
2015-10-16 16:23 GMT+02:00 Bertrand Delacretaz <bd...@apache.org>:
> On Fri, Oct 16, 2015 at 4:18 PM, Cédric Champeau
> <ce...@gmail.com> wrote:
> > Should we mention that most of the dependencies are optional, runtime
> > dependencies and not source dependencies....
>
> A precise list of what's optional or required could be useful, but
> saying "most dependencies" does not bring much IMO.
>
> -Bertrand
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Oct 16, 2015 at 4:18 PM, Cédric Champeau
<ce...@gmail.com> wrote:
> Should we mention that most of the dependencies are optional, runtime
> dependencies and not source dependencies....
A precise list of what's optional or required could be useful, but
saying "most dependencies" does not bring much IMO.
-Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
Should we mention that most of the dependencies are optional, runtime
dependencies and not source dependencies. In that case GPars would only
appear in the convenience binary zip.
2015-10-16 16:15 GMT+02:00 Paul King <pa...@asert.com.au>:
> Sorry, forgot to mention that one. As per licenses/jsr166y-BINZIP.txt
> (EG = Expert Group):
>
> ---
> JSR166y License (optionally used by the optional GPars dependency)
>
> This product bundles the jsr166y jar (containing works from
> the JSR-166 EG, Doug Lea, and Jason T. Greene) made available in
> the public domain. For details, see licenses/jsr166y-license.
> ---
>
> Also, I think the links on the Groovy site should be very close to
> what we want now.
>
> Cheers, Paul.
>
>
> On Sat, Oct 17, 2015 at 12:10 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> > Hi Paul,
> >
> > On Fri, Oct 16, 2015 at 2:47 PM, Paul King <pa...@asert.com.au> wrote:
> >> ...To generate the report, run:
> >> $ gradlew generateLicenseReport
> > ...
> >
> > Great!
> >
> > I agree with your assessment of the results, except that jsr166y
> > doesn't have license information in my report, do you have more info
> > about that one?
> >
> > -Bertrand
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
Sorry, forgot to mention that one. As per licenses/jsr166y-BINZIP.txt
(EG = Expert Group):
---
JSR166y License (optionally used by the optional GPars dependency)
This product bundles the jsr166y jar (containing works from
the JSR-166 EG, Doug Lea, and Jason T. Greene) made available in
the public domain. For details, see licenses/jsr166y-license.
---
Also, I think the links on the Groovy site should be very close to
what we want now.
Cheers, Paul.
On Sat, Oct 17, 2015 at 12:10 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Paul,
>
> On Fri, Oct 16, 2015 at 2:47 PM, Paul King <pa...@asert.com.au> wrote:
>> ...To generate the report, run:
>> $ gradlew generateLicenseReport
> ...
>
> Great!
>
> I agree with your assessment of the results, except that jsr166y
> doesn't have license information in my report, do you have more info
> about that one?
>
> -Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Paul,
On Fri, Oct 16, 2015 at 2:47 PM, Paul King <pa...@asert.com.au> wrote:
> ...To generate the report, run:
> $ gradlew generateLicenseReport
...
Great!
I agree with your assessment of the results, except that jsr166y
doesn't have license information in my report, do you have more info
about that one?
-Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
I added the gradle license report plugin to our build. I suspect that
covers off LC20 and LC30.
To generate the report, run:
$ gradlew generateLicenseReport
The default is for the runtime configuration which is what LC20 and
LC30 are applicable to I believe. It isn't particularly pretty,
doesn't collapse duplicates (12 in our case) and doesn't currently
indicate which of our dependencies are optional but it does show that
all the mandatory and optional runtime dependencies are covered by
ASL2 or BSD.
Notes:
Ignoring the duplicates there are about a dozen dependencies (10 of
those are optional dependencies)
Multiverse is an optional dependency of an optional dependency and has
no license info in it's pom but is ASL2 as per
https://github.com/pveentjer/Multiverse.
Openbeans (used within the optional Drooid component) also has no pom
and so is excluded from the report but is ASL2.
Cheers, Paul.
On Fri, Oct 16, 2015 at 5:34 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> No, it is ok on the source, even though we could have used the
> groovy-website wiki section.
>
> 2015-10-15 21:14 GMT+02:00 Keegan Witt <ke...@gmail.com>:
>>
>> Would Apache's Confluence instance be a more appropriate place for these
>> kinds of things?
>>
>> -Keegan
>>
>> On Thu, Oct 15, 2015 at 3:07 PM, Cédric Champeau
>> <ce...@gmail.com> wrote:
>>>
>>> The only problem is that each change triggers a CI build ;)
>>>
>>> 2015-10-15 20:59 GMT+02:00 Konstantin Boudnik <co...@apache.org>:
>>>>
>>>> On Thu, Oct 15, 2015 at 01:52PM, Bertrand Delacretaz wrote:
>>>> > On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
>>>> > <ce...@gmail.com> wrote:
>>>> > > ...I like the idea of having concrete, non
>>>> > > subjective criteria for graduating, even if it could mean in our
>>>> > > case that
>>>> > > graduating would be "stricter"....
>>>> >
>>>> > We're down to 4 TODOs already, and all of them look quite easy to fix.
>>>>
>>>> Looks like 3, actually, and the rest seems to be in order! Last time we
>>>> did
>>>> it on the project website, but having this in the source code is even
>>>> better,
>>>> IMO! Thanks a lot for taking a lead on this!
>>>>
>>>> Cos
>>>>
>>>
>>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
No, it is ok on the source, even though we could have used the
groovy-website wiki section.
2015-10-15 21:14 GMT+02:00 Keegan Witt <ke...@gmail.com>:
> Would Apache's Confluence <https://cwiki.apache.org/confluence/> instance
> be a more appropriate place for these kinds of things?
>
> -Keegan
>
> On Thu, Oct 15, 2015 at 3:07 PM, Cédric Champeau <
> cedric.champeau@gmail.com> wrote:
>
>> The only problem is that each change triggers a CI build ;)
>>
>> 2015-10-15 20:59 GMT+02:00 Konstantin Boudnik <co...@apache.org>:
>>
>>> On Thu, Oct 15, 2015 at 01:52PM, Bertrand Delacretaz wrote:
>>> > On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
>>> > <ce...@gmail.com> wrote:
>>> > > ...I like the idea of having concrete, non
>>> > > subjective criteria for graduating, even if it could mean in our
>>> case that
>>> > > graduating would be "stricter"....
>>> >
>>> > We're down to 4 TODOs already, and all of them look quite easy to fix.
>>>
>>> Looks like 3, actually, and the rest seems to be in order! Last time we
>>> did
>>> it on the project website, but having this in the source code is even
>>> better,
>>> IMO! Thanks a lot for taking a lead on this!
>>>
>>> Cos
>>>
>>>
>>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Keegan Witt <ke...@gmail.com>.
Would Apache's Confluence <https://cwiki.apache.org/confluence/> instance
be a more appropriate place for these kinds of things?
-Keegan
On Thu, Oct 15, 2015 at 3:07 PM, Cédric Champeau <ce...@gmail.com>
wrote:
> The only problem is that each change triggers a CI build ;)
>
> 2015-10-15 20:59 GMT+02:00 Konstantin Boudnik <co...@apache.org>:
>
>> On Thu, Oct 15, 2015 at 01:52PM, Bertrand Delacretaz wrote:
>> > On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
>> > <ce...@gmail.com> wrote:
>> > > ...I like the idea of having concrete, non
>> > > subjective criteria for graduating, even if it could mean in our case
>> that
>> > > graduating would be "stricter"....
>> >
>> > We're down to 4 TODOs already, and all of them look quite easy to fix.
>>
>> Looks like 3, actually, and the rest seems to be in order! Last time we
>> did
>> it on the project website, but having this in the source code is even
>> better,
>> IMO! Thanks a lot for taking a lead on this!
>>
>> Cos
>>
>>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
The only problem is that each change triggers a CI build ;)
2015-10-15 20:59 GMT+02:00 Konstantin Boudnik <co...@apache.org>:
> On Thu, Oct 15, 2015 at 01:52PM, Bertrand Delacretaz wrote:
> > On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
> > <ce...@gmail.com> wrote:
> > > ...I like the idea of having concrete, non
> > > subjective criteria for graduating, even if it could mean in our case
> that
> > > graduating would be "stricter"....
> >
> > We're down to 4 TODOs already, and all of them look quite easy to fix.
>
> Looks like 3, actually, and the rest seems to be in order! Last time we
> did
> it on the project website, but having this in the source code is even
> better,
> IMO! Thanks a lot for taking a lead on this!
>
> Cos
>
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Konstantin Boudnik <co...@apache.org>.
On Thu, Oct 15, 2015 at 01:52PM, Bertrand Delacretaz wrote:
> On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
> <ce...@gmail.com> wrote:
> > ...I like the idea of having concrete, non
> > subjective criteria for graduating, even if it could mean in our case that
> > graduating would be "stricter"....
>
> We're down to 4 TODOs already, and all of them look quite easy to fix.
Looks like 3, actually, and the rest seems to be in order! Last time we did
it on the project website, but having this in the source code is even better,
IMO! Thanks a lot for taking a lead on this!
Cos
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> ...I like the idea of having concrete, non
> subjective criteria for graduating, even if it could mean in our case that
> graduating would be "stricter"....
We're down to 4 TODOs already, and all of them look quite easy to fix.
-Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
> ==== LC20
> _Libraries that are mandatory dependencies of the project's code do not create more restrictions than the Apache License does._
>
> TODO: do we have a documented verification of that? JIRA ticket?
The Groovy all jar bundles ASM and ANTLR as per
licenses/LICENSE-JARJAR file (this is embedded in that Jar). There are
no other mandatory library dependencies when using Groovy.
Although strictly outside of a formal release, the binary convenience
artifacts also have similar license info, e.g. looking inside
LICENSE-BINZIP you will see:
Hamcrest License (needed when using optional JUnit dependency)
JLine2 License (optional dependency used with groovysh)
JSR166y License (optionally used by the optional GPars dependency)
JUnit License (optional dependency when using Groovy for testing)
XStream License (optional dependency when serializing AST as XML)
As for build/tool dependencies, these can be found as mentioned
earlier using 'gradlew dependencies". These are all open source
libraries.
On Thu, Oct 15, 2015 at 9:52 PM, Paul King <pa...@asert.com.au> wrote:
> Guillaume is fixing a few of the missing links on the home page.
>
> Also, wrt:
>
>> ==== CS10
>> _The project maintains a public list of its contributors who have decision power -- the project's PMC (Project Management Committee) consists of those contributors._
>>
>> TODO, I don't think that list exists but it will eventually be at people.apache.org/committers-by-project.html#groovy-pmc
>> once the project graduates.
>
> There is this page here:
> http://incubator.apache.org/projects/groovy.html
>
> We didn't spell out PMC/PPMC on that page. If we did, would that be
> what is expected?
>
>> [...] I'm not familiar with Gradle but I suppose there's a build option to list them?
>
> $ gradlew dependencies
>
> gives a fairly comprehensive list of dependencies including build.tool
> dependencies.
>
> Paul.
>
>
> On Thu, Oct 15, 2015 at 9:43 PM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> Hi Cédric,
>>
>> On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
>> <ce...@gmail.com> wrote:
>>> Bertrand wrote:
>>>> TODO: http://groovy.apache.org/ redirects to http://groovy-lang.org/, do
>>>> we plan on keeping it like that?
>>>
>>> ...My vision to this, what we
>>> might do is using groovy.a.o for *development of Groovy itself*, while
>>> groovy-lang.org would be the user facing site....
>>
>> That sounds good to me, I moved that info to CO10 and updated CD20 to
>> mention the "fork me on github" banner. Note that that banner is not
>> visible for me using Firefox Developer Edition 43.0a2 (2015-10-14).
>>
>>> LC20
>>>> TODO: do we have a documented verification of that? JIRA ticket?
>>>
>>> Apart from using Rat, no, I don't think we have. But I think it adresses
>>> LC30. We don't have any dependency which is not OSS or not approved...
>>
>> do we have, or can we create a jira ticket or similar page that
>> documents all the the current dependencies? I'm not familiar with
>> Gradle but I suppose there's a build option to list them?
>>
>>> RE40
>>> ...Votes and announcements explicitly refer to those binaries as convenience
>>> binaries...
>>
>> Ok, I have updated that and removed the TODO.
>>
>>> QU30
>>>
>>> We have http://groovy-lang.org/security.html, but not linked from top-level
>>> page or menu....
>>
>> I don't think that page explains how to report security issues. A link
>> to http://www.apache.org/security/ would be sufficient.
>>
>> -Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Thu, Oct 15, 2015 at 1:52 PM, Paul King <pa...@asert.com.au> wrote:
>> ==== CS10
...
> There is this page here:
> http://incubator.apache.org/projects/groovy.html
>
> We didn't spell out PMC/PPMC on that page. If we did, would that be
> what is expected?..
Yes but that's kind of duplicate information.
Actually, this is only relevant once the project graduates, as the
current podling's PMC does not have formal decision power.
I have changed CS10 to "OK: will be at
people.apache.org/committers-by-project.html#groovy-pmc once the
project graduates."
> $ gradlew dependencies
> gives a fairly comprehensive list of dependencies including build.tool
> dependencies.
Am I correct that the below "runtime" output of that represents what's
needed to use Groovy? If yes we need IMO to document the licenses of
these libraries, maybe just in a jira ticket so we keep a trace of it.
I don't see any potential problems, it's just to do that cleanly.
-Bertrand
runtime - Runtime classpath for source set 'main'.
+--- antlr:antlr:2.7.7
+--- org.ow2.asm:asm:5.0.3
+--- org.ow2.asm:asm-analysis:5.0.3
| \--- org.ow2.asm:asm-tree:5.0.3
| \--- org.ow2.asm:asm:5.0.3
+--- org.ow2.asm:asm-commons:5.0.3
| \--- org.ow2.asm:asm-tree:5.0.3 (*)
+--- org.ow2.asm:asm-tree:5.0.3 (*)
+--- org.ow2.asm:asm-util:5.0.3
| \--- org.ow2.asm:asm-tree:5.0.3 (*)
+--- commons-cli:commons-cli:1.3.1
+--- org.apache.ant:ant:1.9.6
| \--- org.apache.ant:ant-launcher:1.9.6
+--- com.thoughtworks.xstream:xstream:1.4.8
+--- com.googlecode:openbeans:1.0
+--- org.fusesource.jansi:jansi:1.11
+--- org.apache.ivy:ivy:2.4.0
\--- org.codehaus.gpars:gpars:1.2.1
+--- org.multiverse:multiverse-core:0.7.0
\--- org.codehaus.jsr166-mirror:jsr166y:1.7.0
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Paul King <pa...@asert.com.au>.
Guillaume is fixing a few of the missing links on the home page.
Also, wrt:
> ==== CS10
> _The project maintains a public list of its contributors who have decision power -- the project's PMC (Project Management Committee) consists of those contributors._
>
> TODO, I don't think that list exists but it will eventually be at people.apache.org/committers-by-project.html#groovy-pmc
> once the project graduates.
There is this page here:
http://incubator.apache.org/projects/groovy.html
We didn't spell out PMC/PPMC on that page. If we did, would that be
what is expected?
> [...] I'm not familiar with Gradle but I suppose there's a build option to list them?
$ gradlew dependencies
gives a fairly comprehensive list of dependencies including build.tool
dependencies.
Paul.
On Thu, Oct 15, 2015 at 9:43 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> Hi Cédric,
>
> On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
> <ce...@gmail.com> wrote:
>> Bertrand wrote:
>>> TODO: http://groovy.apache.org/ redirects to http://groovy-lang.org/, do
>>> we plan on keeping it like that?
>>
>> ...My vision to this, what we
>> might do is using groovy.a.o for *development of Groovy itself*, while
>> groovy-lang.org would be the user facing site....
>
> That sounds good to me, I moved that info to CO10 and updated CD20 to
> mention the "fork me on github" banner. Note that that banner is not
> visible for me using Firefox Developer Edition 43.0a2 (2015-10-14).
>
>> LC20
>>> TODO: do we have a documented verification of that? JIRA ticket?
>>
>> Apart from using Rat, no, I don't think we have. But I think it adresses
>> LC30. We don't have any dependency which is not OSS or not approved...
>
> do we have, or can we create a jira ticket or similar page that
> documents all the the current dependencies? I'm not familiar with
> Gradle but I suppose there's a build option to list them?
>
>> RE40
>> ...Votes and announcements explicitly refer to those binaries as convenience
>> binaries...
>
> Ok, I have updated that and removed the TODO.
>
>> QU30
>>
>> We have http://groovy-lang.org/security.html, but not linked from top-level
>> page or menu....
>
> I don't think that page explains how to report security issues. A link
> to http://www.apache.org/security/ would be sufficient.
>
> -Bertrand
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Cédric,
On Thu, Oct 15, 2015 at 11:58 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> Bertrand wrote:
>> TODO: http://groovy.apache.org/ redirects to http://groovy-lang.org/, do
>> we plan on keeping it like that?
>
> ...My vision to this, what we
> might do is using groovy.a.o for *development of Groovy itself*, while
> groovy-lang.org would be the user facing site....
That sounds good to me, I moved that info to CO10 and updated CD20 to
mention the "fork me on github" banner. Note that that banner is not
visible for me using Firefox Developer Edition 43.0a2 (2015-10-14).
> LC20
>> TODO: do we have a documented verification of that? JIRA ticket?
>
> Apart from using Rat, no, I don't think we have. But I think it adresses
> LC30. We don't have any dependency which is not OSS or not approved...
do we have, or can we create a jira ticket or similar page that
documents all the the current dependencies? I'm not familiar with
Gradle but I suppose there's a build option to list them?
> RE40
> ...Votes and announcements explicitly refer to those binaries as convenience
> binaries...
Ok, I have updated that and removed the TODO.
> QU30
>
> We have http://groovy-lang.org/security.html, but not linked from top-level
> page or menu....
I don't think that page explains how to report security issues. A link
to http://www.apache.org/security/ would be sufficient.
-Bertrand
Re: [mentors] experimental graduation maturity assessment in view
of graduating Groovy
Posted by Balachandran Sivakumar <ga...@brahman.balachandran.org>.
Hi,
On Thu, 15 Oct 2015, Cédric Champeau wrote:
>
> It's there in multiple places: the "fork me" banner on the upper right corner and contribute page: http://groovy-lang.org/contribute.html
>
It is there at the bottom of the home page as well in the "About"
column. There is a link labled "Source code" pointing to the github
mirror. Thanks
--
Thank you,
Balachandran Sivakumar
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Cédric Champeau <ce...@gmail.com>.
Thanks Bertrand for setting this up. I like the idea of having concrete,
non subjective criteria for graduating, even if it could mean in our case
that graduating would be "stricter". Here are some of my comments on the
TODOS:
*CD20*
> The project’s code is easily discoverable and publicly accessible.
> TODO: http://groovy.apache.org/ redirects to http://groovy-lang.org/, do
we plan on keeping it like that?
At least for me, yes. The model is OpenOffice, which has it's dedicated
domain. It's also much easier for us given our publication model (docs in
subdomains, ...) and the history of the project. My vision to this, what we
might do is using groovy.a.o for *development of Groovy itself*, while
groovy-lang.org would be the user facing site.
>TODO: http://groovy-lang.org/ does not include an obvious link to the code
repository (unless I missed something)
It's there in multiple places: the "fork me" banner on the upper right
corner and contribute page: http://groovy-lang.org/contribute.html
*LC20*
> Libraries that are mandatory dependencies of the project’s code do not
create more restrictions than the Apache License does.
> TODO: do we have a documented verification of that? JIRA ticket?
Apart from using Rat, no, I don't think we have. But I think it adresses
LC30. We don't have any dependency which is not OSS or not approved.
*RE40*
> Convenience binaries can be distributed alongside source code but they
are not Apache Releases — they are just a convenience provided with no
guarantee.
> TODO check the status of binaries in existing releases and briefly
document it here.
Votes and announcements explicitly refer to those binaries as convenience
binaries.
*QU30*
> The project provides a well-documented channel to report security issues,
along with a documented way of responding to them.
> TODO: http://groovy-lang.org/ does not include that information as far as
I can see. See also
http://www.apache.org/foundation/marks/pmcs.html#navigation for required
links on the project’s homepage.
We have http://groovy-lang.org/security.html, but not linked from top-level
page or menu. The mandatory links must be added.
2015-10-15 11:41 GMT+02:00 Bertrand Delacretaz <bd...@apache.org>:
> On Thu, Oct 15, 2015 at 11:09 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
> ...
> > https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
>
> I have finished my first pass for this assessment - lots of OK but
> also a few TODOs, mostly around the website, nothing major.
>
> If the other mentors agree I suggest that we resolve those TODOs
> before moving on with graduation, either by documenting existing
> decisions, clarifying them or fixing things.
>
> QU30 at least needs fixing the website with required links, unless I
> missed those links.
>
> -Bertrand
>
Re: [mentors] experimental graduation maturity assessment in view of
graduating Groovy
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Oct 15, 2015 at 11:09 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
...
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc
I have finished my first pass for this assessment - lots of OK but
also a few TODOs, mostly around the website, nothing major.
If the other mentors agree I suggest that we resolve those TODOs
before moving on with graduation, either by documenting existing
decisions, clarifying them or fixing things.
QU30 at least needs fixing the website with required links, unless I
missed those links.
-Bertrand