from:"Cédric Champeau"

Re: [VOTE] Drop the incubator- prefix for podling's GitHub repo name

2024-05-08 Thread Cédric Champeau

+1

Le mer. 8 mai 2024 à 17:21, Christofer Dutz  a
écrit :

> +1 binding
>
> Chris
>
>
> Von: larry mccay 
> Datum: Mittwoch, 8. Mai 2024 um 17:06
> An: general@incubator.apache.org 
> Betreff: Re: [VOTE] Drop the incubator- prefix for podling's GitHub repo
> name
> +1 binding
>
> Can't we move the indicator to the About section where it says Mirror of
> (project name).
> Extend that to include Under Incubation as well.
>
> On Wed, May 8, 2024 at 10:53 AM Daniel Gruno  wrote:
>
> > On 5/8/24 09:45, sebb wrote:
> > > On Wed, 8 May 2024 at 15:15, Daniel Gruno 
> wrote:
> > >>
> > >> On 5/8/24 03:20, Sheng Wu wrote:
> > >>> sebb  于2024年5月8日周三 16:12写道：
> > 
> >  Remember that the purpose of the incubator prefix is to clearly
> signal
> >  that the code is under Incubation.
> > 
> >  It is essential that this change does not result in losing this
> > indication.
> > 
> >  AFAICT, for most podlings, dropping the incubator prefix will
> require
> >  additional work to ensure that the Incubation status is clear to
> >  users,
> >  and will require additional work by the IPMC to ensure that podlings
> >  adequately display the Incubation status for each repository.
> > >>>
> > >>> Can't agree more on this.
> > >>> In this vote proposal, we implicitly add many more checks for IPMC,
> > >>> and lead more potential arguments about whether the incubating status
> > >>> indicator is clear enough.
> > >>> We are making IPMC pay the price in the future by removing a simple
> > >>> GitHub supported operation.
> > >>>
> > >>> On second thought, I am changing my vote to -1 binding.
> > >>
> > >> This seems to point at more systemic failings of the IPMC if we are
> > >> relying on the incubator- repository prefix for denoting podlings.
> I'll
> > >> note that, as far as I can tell, the original reason for the incubator
> > >> prefix was that of a technical limitation with the incubator, and
> > >> shouldn't (imho) be used as a crutch for failings elsewhere in the
> > >> branding of podlings.
> > >
> > > It's not a crutch if the naming convention satisfies the requirement;
> > > it's just another way of doing it.
> > >
> > >> I am +1 (binding) on dropping the prefix myself. Incubation notices
> > >> should be handled during releases, and on the official podling
> website.
> > >
> > > IMO Incubation status needs to be made clear from the very start.
> > > It is not something that can be left until later.
> >
> > *We* know what incubation means, and *we* know what the incubator-
> > prefix denotes. Does the general public have any clue? Does the prefix
> > matter to the end user?
> >
> > I know the prefix requires additional work from the projects and infra
> > upon graduation, which is a tangible downside. Is there a tangible
> > upside to the prefix, empirically speaking?
> >
> > >
> > >>>
> > 
> > 
> >  On Wed, 8 May 2024 at 08:30, alin.jerpe...@sony.com
> >   wrote:
> > >
> > > +1 (non binding)
> > >
> > > from my experience will make the documentation and releases easy to
> > migrate after graduation
> > >
> > > Best regards
> > > Alin
> > > 
> > > Från: hulk 
> > > Skickat: den 8 maj 2024 09:06
> > > Till: general@incubator.apache.org 
> > > Ämne: Re: [VOTE] Drop the incubator- prefix for podling's GitHub
> > repo name
> > >
> > > -0 (binding) On Wed, 8 May 2024 at 13: 58, Richard Zowalla
>  > zowalla. com> wrote: > -0 (binding) > > (I like the prefix) > > Am 8. Mai
> > 2024 07: 41: 16 MESZ schrieb Sheng Wu : >
> > >-0
> > > ZjQcmQRYFpfptBannerStart
> > > Caution : This email originated from outside of Sony.
> > > Do not click links or open any attachments unless you recognize the
> > sender and know the content is safe. Please report phishing if unsure.
> > >
> > > ZjQcmQRYFpfptBannerEnd
> > >
> > > -0 (binding)
> > >
> > > On Wed, 8 May 2024 at 13:58, Richard Zowalla 
> > wrote:
> > >
> > >> -0 (binding)
> > >>
> > >> (I like the prefix)
> > >>
> > >> Am 8. Mai 2024 07:41:16 MESZ schrieb Sheng Wu <
> > wu.sheng.841...@gmail.com>:
> > >>> -0 binding
> > >>>
> > >>> Sheng Wu 吴晟
> > >>> Twitter, wusheng1108
> > >>>
> > >>> Dave Fisher  于2024年5月8日周三 12:16写道：
> > 
> >  +0 (binding) wave
> > 
> > > On May 7, 2024, at 5:34 PM, Francis Chuang <
> > francischu...@apache.org>
> > >> wrote:
> > >
> > > +1 (binding)
> > >
> > > I think this is a pragmatic and well-thought out approach.
> > >
> > > Francis
> > >
> > > On 8/05/2024 10:31 am, tison wrote:
> > >> Hi,
> > >> Following the discussion thread [1], I'd start a vote on the
> > >> following
> > >> proposals:
> > >> 1. Establish a consensus to allow and finally converge
> podling's
> > >> GitHub repo to
> >

Re: eliminating MD5 and SHA1 signatures

2020-01-23 Thread Cédric Champeau

Fwiw if you use Gradle 6+ it publishes sha256 and sha512 by default.

Le ven. 17 janv. 2020 à 21:51, leerho  a écrit :

> When I deploy to repository.apache.org
>  in addition to the .asc
> signatures, either the Maven deploy plugin or the repository always adds
> MD5 and SHA1 signatures as well.
>
> Is there a configuration somewhere that will eliminate these being added?
>
> Lee.
>

Re: How to review so-called "binary releases"?

2018-11-07 Thread Cédric Champeau

While officially binaries are only convenience, it happened several times
with Groovy that we downvote a release _because_ of broken binaries. So we
integrate them as part of our review process. Basically, we do the usual
checks on sources (checksums, signatures, build, ...), but we _also_ check
that the convenience binaries work. That means, unzip, try to run the app,
play with it, ... Most of this process is automated during the build, there
are still a few quirks because of cross-platform testing, but I just wanted
to highlight that we don't have to restrict our reviews to what is legally
needed.

Le mer. 7 nov. 2018 à 01:55, Daniel Shahaf  a
écrit :

> CC += legal-discuss@ since this really isn't an incubator-specific topic
> any
> more.  The context is precompiled binary artifacts on
> https://www.apache.org/dist/.
>
> David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> > So let's assume a PMC (or PPMC) goes through the same process with
> > binaries in terms of reviewing, voting on, promoting, and publishing
> > to the world a binary release on behalf of the PMC and Foundation.
> > Binaries are published to the same location that source tar balls are
> > - are featured on download pages provided by the ASF. Perhaps even
> > with the situation being that people download the binary artifacts
> > from ASF resources tens of thousands, or maybe even millions of times
> > more frequently than the source tarballs.
> >
> > From that scenario I have some questions:
> >
> > 1. Would a reasonable person (or jury) suspend disbelief long enough
> > to consider our protestations that our 'releases' are source only, and
> > that as a Foundation we didn't release, propagate, promote, or
> > distribute the binaries in question? A rose by any other name.
> > 2. Should the Board be taking an active interest in projects (release
> > managers?) who promote and publish their binaries in this manner on
> > our hardware?
> > 3. Is lack of Board action tantamount to tacit approval of this
> > behavior? Can we really claim ignorance?
> > 4. Should Infrastructure be actively monitoring and removing binaries
> > which find their way to dist.a.o/archive.a.o - especially since our
> > header for dist.a.o says that the directories contain releases of
> > Apache software?
> > 5. Should we be alerting individual release managers that publishing
> > convenience binaries exposes them individually to liability?
>
> 6. What alternative can we offer to projects that want to distribute
> binaries?
> Can the RM upload precompiled binaries to his https://home.a.o/~availid/
> space?
> Can the project's download page link to them as the
> primary/canonical/recommended binaries?  Can the project's download page
> link
> to the RM's binaries as one alternative among many (compare
> https://subversion.apache.org/packages#windows)?
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-06 Thread Cédric Champeau

@wade it would be better to continue the discussion in the discuss vote,
rather than this vote which has been cancelled.

See
https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E

2017-01-06 17:32 GMT+01:00 Wade Chandler :

> On Jan 4, 2017 4:46 AM, "Jochen Theodorou"  wrote:
>
> On 04.01.2017 07:28, Mark Struberg wrote:
> [...]
>
> I'm a bit surprised that groovy still uses the org.codehaus groupId, but I
> > guess they have a deal with Ben (the former owner and thus (former?)
> > copyright holder of 'Codehaus').
> > So while this will work for now I guess that even groovy will move to
> > org.apache.groovy in the long term (maybe with a new major version).
> >
>
> A new major version is a big thing for Groovy, but yes. In our view it is
> the only realistic way, since people can expect breaking changes between
> major versions and that includes in our view package names as well as group
> ids.
>
>
> It's not a big deal YET, but http://codehaus.org is not reachable anymore.
> > And if anyone buys this domain he will have a much better position
> > regarding trademarks than we do.
> > What if someone buys the codehaus.org domain and publishes own artifacts
> > under org.codehaus.groovy? Can we even prevent someone else to e.g
> publish
> > org.codehaus.groovyng artifacts?
> >
>
> Assume we change and 2 months later somebody does that? How is the
> situation then any better?
>
> Actually I wonder if Ben would donate the domain to the ASF...
>
>
> This would be a huge deal for NetBeans too. Too many projects based off of
> it. The domain is being donated to Apache though AFAIK, but still, end
> users shouldn't have to change so many sources or break other dependencies,
> which may not be using the new package names, just because the package
> names are org.netbeans and someone thinks they should be
> org.apache.netbeans unless there is a true legal reason, and that would be
> rare, but a different email thread I imagine, but way more complicated than
> just changing the package name in the case of Groovy or NetBeans because we
> are talking about whole ecosystems and dependency graphs.
>
> Thanks
>
> Wade
>

Re: [DISCUSS] Significance of Artifact Names

2017-01-04 Thread Cédric Champeau

Cross-posting since I missed this topic in the first place. My apologies
for the duplicate:

I would argue that one of the Foundation mottos is "community first". In
that sense, enforcing a policy like that is not thinking about users. It's
adding a burden they don't care about. I am strongly against anything that
enforces technical requirements where there shouldn't be. Enforcing Maven
coordinates, or enforcing a _version string_ is going too far into the
technical details. There's branding and there's technical. Maven already
makes the mistake of mixing how you build the project and how you consume
it, which is the root of a lot of pain. Let's not make the error again at
the policy level, it's a total non sense.

The Foundation can host a variety of different projects, from new ones
written in C to "old" ones written in Java, and all the different things we
can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
you consume a project, by Maven coordinates or version string is an
implementation detail. Branding the project is not. In other words, as long
as your package name, maven artifacts, Docker images, ... do not infringe
copyright, it's a no brainer. However, the project page *must* state about
incubating status and *explain* what it means. A *lot* of people don't care
what *incubating* means in the Foundation sense (and even worse, podling
can have very negative image). It would have been terrible for Groovy to
change the way people consume the artifacts, making them think of low
quality software, because they don't understand what "incubating" mean. To
me it sounds even worse than "alpha". Since "incubating" is meant towards
*incubating project in the sense of the Apache community*, it should *only*
appear where it makes sense: DISCLAIMER, web site, ... That is to say
everywhere you can give an explanation about its meaning. It should also
appear in the source package name, because that is what we legally care
about. But the version *string*, inside the package, is purely, again,
internal details, just like package name, Maven coordinates, NPM
coordinates, ... Why would you force me to use a version pattern if what I
want is the revision hash as the version number? The policy should NOT
impact how we design software or how we want the design to be. There are
potential technical issues with putting such a label in a version string
(OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
name the Java ecosystem), so to me enforcing the policy here is just an
error.

As for Groovy and the Codehaus package and Maven coordinates, we plan to
change this in a major, breaking, 3.0 release, not before. Because it would
be a breaking change, and some dependency management engines, typically,
are very poor when it comes to dependency substitution, which would add too
much burden for people to upgrade. We had an agreement with Ben from
Codehaus to use the name when we joined the ASF.



2017-01-04 6:24 GMT+01:00 Alex Harui :

> Sorry for top-posting.
>
> It's always been interesting to me that the ASF says that it only releases
> source code, but still has policy about the contents of convenience
> binaries such as [6].  So, I suppose the ASF could dictate naming of
> binary packages.
>
> I know very little about Maven, but in my mind, the -incubating suffix is
> supposed to help warn the customer or cover the ASFs butt or both.  I
> don't know if anybody actually points to a source artifact from Maven, but
> if the downstream user is being careful enough to work from sources, it
> makes sense to me to put in an additional warning by adding the
> -incubating suffix to the source package. It says that these source
> packages are not like other ASF source packages without having to open the
> package.
>
> But for a binary artifact, given that the ASF already thinks it isn't
> audit-able and thus not an official release, does the customer care that
> the artifact may not be ASF-grade (especially if the artifacts were
> already considered open before entering Apache)?  Do they really need
> early warning?  Would it really affect the ASF if something bad was later
> found in a binary artifact?
>
> IMO, the answer to all 3 questions is no.  I don't know how hard it is to
> suffix the source artifact with -incubating but not for the binary
> artifacts.  But if it is hard, could the next version of Maven do it?
>
> Also, if someone is concerned enough about the licensing of the artifacts
> they depend on to go digging through all of the poms of their binary
> dependencies, wouldn't they check the  section of each POM?
> According to [7] there is a comments section there.  Could incubating
> podlings be required to make it clear in the  section that this
> thing may not be fully ASF compliant instead of having to add a suffix to
> the version of their binary artifacts?
>
> My 2 cents,
> -Alex
>
> [6] https://www.apache.org/legal/src-headers.html#faq-binaries
>

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-04 Thread Cédric Champeau

I would argue that one of the Foundation mottos is "community first". In
that sense, enforcing a policy like that is not thinking about users. It's
adding a burden they don't care about. I am strongly against anything that
enforces technical requirements where there shouldn't be. Enforcing Maven
coordinates, or enforcing a _version string_ is going too far into the
technical details. There's branding and there's technical. Maven already
makes the mistake of mixing how you build the project and how you consume
it, which is the root of a lot of pain. Let's not make the error again at
the policy level, it's a total non sense.

The Foundation can host a variety of different projects, from new ones
written in C to "old" ones written in Java, and all the different things we
can see in our ecosystem: Javascript, Go, ... Enforcing a rule about _how_
you consume a project, by Maven coordinates or version string is an
implementation detail. Branding the project is not. In other words, as long
as your package name, maven artifacts, Docker images, ... do not infringe
copyright, it's a no brainer. However, the project page *must* state about
incubating status and *explain* what it means. A *lot* of people don't care
what *incubating* means in the Foundation sense (and even worse, podling
can have very negative image). It would have been terrible for Groovy to
change the way people consume the artifacts, making them think of low
quality software, because they don't understand what "incubating" mean. To
me it sounds even worse than "alpha". Since "incubating" is meant towards
*incubating project in the sense of the Apache community*, it should *only*
appear where it makes sense: DISCLAIMER, web site, ... That is to say
everywhere you can give an explanation about its meaning. It should also
appear in the source package name, because that is what we legally care
about. But the version *string*, inside the package, is purely, again,
internal details, just like package name, Maven coordinates, NPM
coordinates, ... Why would you force me to use a version pattern if what I
want is the revision hash as the version number? The policy should NOT
impact how we design software or how we want the design to be. There are
potential technical issues with putting such a label in a version string
(OSGi, Jigsaw, dependency resolution with Maven, Ivy or Gradle, ... just to
name the Java ecosystem), so to me enforcing the policy here is just an
error.

As for Groovy and the Codehaus package and Maven coordinates, we plan to
change this in a major, breaking, 3.0 release, not before. Because it would
be a breaking change, and some dependency management engines, typically,
are very poor when it comes to dependency substitution, which would add too
much burden for people to upgrade. We had an agreement with Ben from
Codehaus to use the name when we joined the ASF.

2017-01-04 8:51 GMT+01:00 Pierre Smits :

> John,
>
> I guess the discussion will go on, every time the topic will be brought
> forward to the public mailings lists. Conducting politics is part of the
> human nature. Keeping the discussion going will have the Incubator project
> running in circles. Calling a vote on a procedural change and reporting the
> result will help the project.
>
> Not everything needs unanimous consent. A simple majority suffices to
> establish a direction until the next vote on the same subject.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Wed, Jan 4, 2017 at 7:28 AM, Mark Struberg 
> wrote:
>
> > I guess you are talking about log4j/log4j or the various commons-*
> > groupIds?
> > This is true, but for completness sake I want to point out that there is
> a
> > difference to use a different _unused_ groupId vs using a _foreign_ one.
> >
> > I guess everyone would agree that the ASF does not like to publish
> > artifacts with a com.oracle groupId, right?
> >
> > I'm a bit surprised that groovy still uses the org.codehaus groupId, but
> I
> > guess they have a deal with Ben (the former owner and thus (former?)
> > copyright holder of 'Codehaus').
> > So while this will work for now I guess that even groovy will move to
> > org.apache.groovy in the long term (maybe with a new major version).
> >
> > It's not a big deal YET, but http://codehaus.org is not reachable
> > anymore. And if anyone buys this domain he will have a much better
> position
> > regarding trademarks than we do.
> > What if someone buys the codehaus.org domain and publishes own artifacts
> > under org.codehaus.groovy? Can we even prevent someone else to e.g
> publish
> > org.codehaus.groovyng artifacts?
> >
> > LieGrue,
> > strub
> >
> > > Am 04.01.2017 um 02:49 schrieb John D. Ament :
> > >
> > > On Tue, Jan 3, 2017 at 8:43 PM Daniel Dekany 
> > wrote:
> > >
> >

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-03 Thread Cédric Champeau

2017-01-03 13:41 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> 2017-01-03 13:38 GMT+01:00 Cédric Champeau <cedric.champ...@gmail.com>:
>
> > +1
> >
> > Note that for Groovy, the source artifact, which is what legal is all
> > about, contained the -incubating appendix. The Maven artifacts did not,
> and
> > I think it's a reasonable thing: people were used to stable versions of
> > Groovy for years, there was no reason why a new one wouldn't be.
> >
> >
> @Cédric: incubator is not about code maturity so still think it makes sense
> (but agree for very big projects - by users - like groovy which are widely
> used already it is weird so can be the exception confirming the rule?)
>
>
Yes but the problem is that "incubating" carries the concept of maturity.
So I was ok to have it in the source zip file name, because that is the
reference that the ASF cares about, legally speaking. But Maven
coordinates, including the version string, should not be affected by this
policy. In other words, the requirement should not leak into technical
aspects of consuming an artifact.


>
> > 2017-01-03 13:25 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com>:
> >
> > > 2017-01-03 13:06 GMT+01:00 Guillaume Laforge <glafo...@gmail.com>:
> > >
> > > > When you say "it denotes a lack of maturity which is exactly the
> > purpose
> > > > AFAIK", what do you mean my maturity?
> > > > Maturity in terms of how well it follows Apache processes and
> > principles?
> > > > Or in terms of "the project is not ready for prime time"?
> > > >
> > > > For example, for Apache Groovy, the project was very mature, and was
> > > > already 11 years old when it joined the ASF.
> > > > It was very stable, very mature, very solid.
> > > > And it was a bit weird to append "-incubating", as people thought it
> > > meant
> > > > "not ready for prime time" rather that "going through ASF
> incubation".
> > > > Furthermore it forced users to also change the appId although they
> > > usually
> > > > change only the version number, which might be in some property file
> > > > externally. It's not such a big big deal, but it's still something
> they
> > > had
> > > > to do, which is a bit unconvenient.
> > > >
> > > >
> > > And that is exactly this. Don't get me wrong, I'm part of several
> > > incubating projects and I don't like to have -incubating cause it looks
> > not
> > > mature where sometimes code is very robust...but the project is
> immature
> > -
> > > otherwise it wouldn't be in incubator. Even for groovy, there were few
> > > chances but still some, it doesn't match ASF and it could have moved
> > > somewhere else which is a stability issue which is important to show in
> > the
> > > published artifacts.
> > >
> > > Not sure I get the appId since most incubator projects don't reflect
> the
> > > state in the groupId but only the version for this exact reason (make
> > user
> > > upgrade from incubator to TLP just a version to change and not all
> > > coordinates - which makes the classifier as bad as the groupId and
> > version
> > > a good compromise).
> > >
> > >
> > > > I also second the idea that such a rule should apply to all kind of
> > > > artifacts or none, but not be an exception of Maven artifacts.
> > > > It doesn't make sense to enforce a rule for just one... and hence the
> > > idea
> > > > of lifting that rule altogether for everybody.
> > > >
> > > > On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > -1, I think it is important to show that the artifact dependency is
> > not
> > > > > stable and should be used as such (if the project never graduates,
> > even
> > > > if
> > > > > code is very mature then you still get all the troubles you can
> think
> > > > > about).
> > > > >
> > > > > Question is IMHO the opposite: why others don't follow the
> > -incubating
> > > > rule
> > > > > as well?
> > > > >
> > > > > PS: of course an alternative to follow maven common practise would
> be
> > > to
> > > > &

Re: [VOTE] Drop incubating requirement of Maven artifacts

2017-01-03 Thread Cédric Champeau

+1

Note that for Groovy, the source artifact, which is what legal is all
about, contained the -incubating appendix. The Maven artifacts did not, and
I think it's a reasonable thing: people were used to stable versions of
Groovy for years, there was no reason why a new one wouldn't be.

2017-01-03 13:25 GMT+01:00 Romain Manni-Bucau :

> 2017-01-03 13:06 GMT+01:00 Guillaume Laforge :
>
> > When you say "it denotes a lack of maturity which is exactly the purpose
> > AFAIK", what do you mean my maturity?
> > Maturity in terms of how well it follows Apache processes and principles?
> > Or in terms of "the project is not ready for prime time"?
> >
> > For example, for Apache Groovy, the project was very mature, and was
> > already 11 years old when it joined the ASF.
> > It was very stable, very mature, very solid.
> > And it was a bit weird to append "-incubating", as people thought it
> meant
> > "not ready for prime time" rather that "going through ASF incubation".
> > Furthermore it forced users to also change the appId although they
> usually
> > change only the version number, which might be in some property file
> > externally. It's not such a big big deal, but it's still something they
> had
> > to do, which is a bit unconvenient.
> >
> >
> And that is exactly this. Don't get me wrong, I'm part of several
> incubating projects and I don't like to have -incubating cause it looks not
> mature where sometimes code is very robust...but the project is immature -
> otherwise it wouldn't be in incubator. Even for groovy, there were few
> chances but still some, it doesn't match ASF and it could have moved
> somewhere else which is a stability issue which is important to show in the
> published artifacts.
>
> Not sure I get the appId since most incubator projects don't reflect the
> state in the groupId but only the version for this exact reason (make user
> upgrade from incubator to TLP just a version to change and not all
> coordinates - which makes the classifier as bad as the groupId and version
> a good compromise).
>
>
> > I also second the idea that such a rule should apply to all kind of
> > artifacts or none, but not be an exception of Maven artifacts.
> > It doesn't make sense to enforce a rule for just one... and hence the
> idea
> > of lifting that rule altogether for everybody.
> >
> > On Tue, Jan 3, 2017 at 12:55 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > -1, I think it is important to show that the artifact dependency is not
> > > stable and should be used as such (if the project never graduates, even
> > if
> > > code is very mature then you still get all the troubles you can think
> > > about).
> > >
> > > Question is IMHO the opposite: why others don't follow the -incubating
> > rule
> > > as well?
> > >
> > > PS: of course an alternative to follow maven common practise would be
> to
> > > put incubating in the groupId instead of version but in practise we
> have
> > > more easily a placeholder for the version than the groupId so I still
> > think
> > > version is the easiest place for users. Also note no user complained
> > about
> > > that excepted about the fact it denotes a lack of maturity which is
> > exactly
> > > the purpose AFAIK.
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github  > > rmannibucau> |
> > > LinkedIn  | JavaEE Factory
> > > 
> > >
> > > 2017-01-03 12:50 GMT+01:00 Myrle Krantz :
> > >
> > > > +1 non-binding
> > > >
> > > > If a best practice targets only maven and not the others, wouldn't
> that
> > > be
> > > > a reason for a podling to consider avoiding using maven to distribute
> > > > binaries at all?  Is it fair for Apache to disadvantage maven that
> way?
> > > >
> > > > Can Apache enforce policies about binaries not released under the
> > Apache
> > > > name? Wouldn't that sort of policy be in contradiction to the Apache
> > > > license?
> > > >
> > > > Keeping a best practice which is not only unenforceable and
> > inconsistent,
> > > > but also disadvantageous to any project which tries to follow it,
> > > > discredits other best practices as well. (Broken windows theory)
> > > >
> > > > Greets from Germany
> > > > Myrle
> > > >
> > > >
> > > > On Tue, Jan 3, 2017 at 12:34 PM, John D. Ament <
> johndam...@apache.org>
> > > > wrote:
> > > >
> > > > > Carsten, Julian,
> > > > >
> > > > > I want to reiterate my notes from a prior message [1] in case there
> > is
> > > > any
> > > > > confusion over the ask.  There is a "best practice" around maven
> > > specific
> > > > > releases that has been treated as policy,  [2].  This best practice
> > for
> > > > > some reason is only applied if you are using the

[RESULT] [VOTE] Release Apache Groovy 2.4.5-incubating

2015-09-24 Thread Cédric Champeau

Hi everyone!

Vote for the release of Groovy 2.4.5-incubating passed with 6 +1 votes (5
binding) and no 0/-1 votes.

Vote thread:
http://mail-archives.apache.org/mod_mbox/incubator-general/201509.mbox/%3CCADQzvm%3DRbC-1649Vt62e%3D%2BK35KRE4difPg0s7ryuQKoDSJc-QA%40mail.gmail.com%3E

Thank you all!

[VOTE] Release Apache Groovy 2.4.5-incubating

2015-09-20 Thread Cédric Champeau

Hi all!

The Apache Groovy PPMC has successfully voted the release of Apache Groovy
2.4.5-incubating [1], with 4 "+1" binding votes, one "+1" non binding and
no 0/-1 votes. We are now asking the IPMC to vote it too.

This release was done in a particular context, at the SpringOne2GX
conference. Following a very successful BOF session, we followed up with a
release initiation party to share the knowledge about how to perform a
release! We anticipate this will make it easier for more of us to be
involved with releases in the future. It's worth noting that the release
was performed with the presence of Baruch Sadogursky from JFrog
(Artifactory/Bintray) that we use, and he could already suggest some nice
improvements in our release process that we're going to improve for the
upcoming releases.

Vote on dev list:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201509.mbox/%3CCADQzvmkCoEUFXfmSR%2B71K%2BEmSYHAjkFWa1HH76LEcPDLMNSYZQ%40mail.gmail.com%3E
Result of vote on dev list:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201509.mbox/%3CCADQzvm%3DDzF-6T46crzuOBizG2wq0xPArfuz%3DQio_OwgQxEHEcw%40mail.gmail.com%3E

This release fixes documentation issues, a potential memory leak when
loading the Groovy runtime from different classloaders, some JSON fixes and
improvements and numerous small bug fixes.

The changelog for this release can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123=12332749

Tag:
https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=commit;h=13934972b400d40600c994377308b26978fcc325

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/incubator/groovy/

Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/groovy/KEYS
Vote is open for at least 72 hours. Artifacts will be moved to dist as soon
as the vote passes.

[ ] +1, release Apache Groovy 2.4.5-incubating
[ ] 0, I don't care
[ ] -1, because...

Re: [VOTE] Release Apache Brooklyn 0.7.0-incubating [rc1]

2015-07-22 Thread Cédric Champeau

 * renaming of packages from brooklyn.* to org.apache.brooklyn.* will be
 required for graduation, I strongly encourage that step to be taken care of
 in the next release.

Where is such a requirement described? As far as I understand, package
names are best suited if they start with org.apache.*, but it's not a
strong requirement. If it is, then it would basically mean that Groovy
(the podling I am member of) would never go out of incubation, because
of our binary backwards compatibility requirements.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Cédric Champeau


 Lets be clear, what I was referring to is this: the identified LN issue
 is a non-code change that has no implication to the stability of your
 release whatsoever. Hence manually fixing it, re-spinning the RC and
 calling a shortened (12-24h) vote doesn't seem to present a problem

First of all, the fact of rolling back a release already takes time.
There's much more involved than a couple of artifacts uploaded on
dist.apache.org. We are very picky at quality, and a release is issued
from a CI server, which automates all tasks that are subject to human
errors. It involves creating a release branch, tagging, uploading
Maven artifacts to Artifactory, uploading the distribution to Bintray,
synchronizing to Maven Central, etc... What we did for the new Apache
release process is cut this into small steps that introduce potential
human errors. And basically, we have staging areas for the
source/distribution artifacts (what you vote on), and staging area for
the complete set of artifacts (Groovy produces more than 270 jar
artifacts). Rolling back, as I said, implies several steps, including
closing those staging repos, removing the tags, branches, ... And due
to some restrictions of the Apache infrastructure, we have a complex
setup (we need to push the tags on personal branches from GitHub, then
push them to Apache Git, as explained in our release document [1]).

So, rolling back a release is not cheap. And then, you have to release
again. And releasing, for the same reasons, is far from being cheap. I
am the first one really annoyed by this as the release manager,
because as I explained when joining Apache, I spent numerous hours
polishing the Groovy release process, and releasing was a single click
button. I could release 2 branches of Groovy in a couple of hours.
*That* was cheap. For this release, it took me several hours and a lot
of manual steps are involved. I know most of you are used to release
from your own computers. That simplifies things a little, but that's
not a guarantee of quality, in the sense that human errors are
possible: you could release from a local source tree which is not
exactly what the source reference is (so produce a correct source zip
but that would differ from what the real source is), you could have
dependencies in your local Maven repo which wouldn't be found
otherwise (caching problem), you could build on a non-approved JDK
(our CI builds do it from JDKs which were approved to be bug-free by
the team, in particular with invokedynamic...), ... We don't want to
do that.

In addition, fixing this LN issue is not cheap either. First of all,
we were not aware that the source and binary versions had to be
different (and it seems that our mentors missed it for the first RC we
tried). Second, we are still working on the issue, because we want to
avoid being downvoted again, so it implies a lot of new sanity checks.
Paul is doing that, but that's all on personal time of a distributed
team, so no, we wouldn't have released in time. And there were already
changes to the codebase after the rc was issued (development doesn't
stop during voting), so either we would have to fork the RC branch,
release from it and add new burden to our release process, or we would
have to revote for everything including sources.

Last but not least, I would also say that none of us was aware that a
shortened vote period was possible. And since at Apache, everybody
seem to have an opinion on everything, we would have taken the risk of
being downvoted for not giving enough time to vote. That said, given
that our vote on dev@ passed because we gave enough time to our
voters. With 24h voting period we wwouldn't have had enough votes.
Also, if we reissue a rc for the IPMC, I don't see why only the IPMC
should vote. Otherwise it means that the artifacts that were voted on
dev@ are different from those voted on general@. And that's a bad
thing IMHO.

To my mind, incubating is about learning how this works, and I think
we're doing a reasonable job in that area. If you put the entry level
too high, then you just discourage people to contribute.


 I just don't understand why you didn't entertain that as an option. Personally
 I would've made myself available to cast my vote under very compressed
 schedule if you actually ASKED for it.

 Not releasing would not have been serious, and we could have missed
 the short timeframe we have given the vacations of the team.
 It's also unfair because we took *very seriously* the comments for the
 first attempt of the release, a few weeks ago, and fixed *all of them*
 (and did even more than what you asked us to do).
 So I think our community deserved that release more than having the
 perfect LN files (especially because as we said, the License file
 contains more, but not less, than required), and as
 Paul said, all jars produces *do* have them.

 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

 I sincerely hope my

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Cédric Champeau

Thanks Justin. We had read that document, but even reading the binary
section, it wasn't clear that source and binary LN had to be
different. I would suggest to update the page to make it clear that
These additional dependencies must be accounted for in LICENSE and
NOTICE. doesn't mean that the LICENSE and NOTICE files need to be
updated to include those additional dependencies, but that *separate*
LN files *must* be issued including these additional dependencies.

2015-07-17 1:02 GMT+02:00 Justin Mclean justinmcl...@me.com:
 Hi,

 +1 ! And adding such a tool into rat or whatever would be extremely
 helpful, too...

 The “tools” I use generally make a bit of noise and require some 
 interpretation / filtering so I’m not sure they could be automated cleanly. 
 One thing rat might be able to do that I don’t think it currently does is 
 detect files containing more than one license header.

 Best advice I can give is follow this guide [1] and use it when reviewing 
 releases.

 Thanks,
 Justin

 1. http://www.apache.org/dev/licensing-howto.html
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-17 Thread Cédric Champeau

Realizing I forgot the link to the release doc (WIP):
http://groovy-lang.org/wiki/incubation-release-process.html

2015-07-17 9:31 GMT+02:00 Emmanuel Lécharny elecha...@gmail.com:
 Le 17/07/15 09:21, Cédric Champeau a écrit :
 Lets be clear, what I was referring to is this: the identified LN issue
 is a non-code change that has no implication to the stability of your
 release whatsoever. Hence manually fixing it, re-spinning the RC and
 calling a shortened (12-24h) vote doesn't seem to present a problem
 First of all, the fact of rolling back a release already takes time.
 There's much more involved than a couple of artifacts uploaded on
 dist.apache.org. We are very picky at quality, and a release is issued
 from a CI server, which automates all tasks that are subject to human
 errors. It involves creating a release branch, tagging, uploading
 Maven artifacts to Artifactory, uploading the distribution to Bintray,
 synchronizing to Maven Central, etc... What we did for the new Apache
 release process is cut this into small steps that introduce potential
 human errors. And basically, we have staging areas for the
 source/distribution artifacts (what you vote on), and staging area for
 the complete set of artifacts (Groovy produces more than 270 jar
 artifacts). Rolling back, as I said, implies several steps, including
 closing those staging repos, removing the tags, branches, ... And due
 to some restrictions of the Apache infrastructure, we have a complex
 setup (we need to push the tags on personal branches from GitHub, then
 push them to Apache Git, as explained in our release document [1]).

 So, rolling back a release is not cheap. And then, you have to release
 again. And releasing, for the same reasons, is far from being cheap. I
 am the first one really annoyed by this as the release manager,
 because as I explained when joining Apache, I spent numerous hours
 polishing the Groovy release process, and releasing was a single click
 button. I could release 2 branches of Groovy in a couple of hours.
 *That* was cheap. For this release, it took me several hours and a lot
 of manual steps are involved. I know most of you are used to release
 from your own computers. That simplifies things a little, but that's
 not a guarantee of quality, in the sense that human errors are
 possible: you could release from a local source tree which is not
 exactly what the source reference is (so produce a correct source zip
 but that would differ from what the real source is), you could have
 dependencies in your local Maven repo which wouldn't be found
 otherwise (caching problem), you could build on a non-approved JDK
 (our CI builds do it from JDKs which were approved to be bug-free by
 the team, in particular with invokedynamic...), ... We don't want to
 do that.

 In addition, fixing this LN issue is not cheap either. First of all,
 we were not aware that the source and binary versions had to be
 different (and it seems that our mentors missed it for the first RC we
 tried). Second, we are still working on the issue, because we want to
 avoid being downvoted again, so it implies a lot of new sanity checks.
 Paul is doing that, but that's all on personal time of a distributed
 team, so no, we wouldn't have released in time. And there were already
 changes to the codebase after the rc was issued (development doesn't
 stop during voting), so either we would have to fork the RC branch,
 release from it and add new burden to our release process, or we would
 have to revote for everything including sources.

 Last but not least, I would also say that none of us was aware that a
 shortened vote period was possible. And since at Apache, everybody
 seem to have an opinion on everything, we would have taken the risk of
 being downvoted for not giving enough time to vote. That said, given
 that our vote on dev@ passed because we gave enough time to our
 voters. With 24h voting period we wwouldn't have had enough votes.
 Also, if we reissue a rc for the IPMC, I don't see why only the IPMC
 should vote. Otherwise it means that the artifacts that were voted on
 dev@ are different from those voted on general@. And that's a bad
 thing IMHO.

 To my mind, incubating is about learning how this works, and I think
 we're doing a reasonable job in that area. If you put the entry level
 too high, then you just discourage people to contribute.

 ALl of this makes perfect sense to me.

 Now, I'm a bit scared : why the hell can't we make it easier to cut a
 release at Apache for this project ? I mean, the infrastructure should
 not be a limitation here : we do have a CI, we most certainly can tune
 it to fit Groovy.

 I suggest we discuss this matter instead of arguing about why this
 release was not perfect (we all agreed on that already) The critical
 point is that it should not take hours to cut a release nor to rollback
 it. That would be a constructive discussion.

 I'd like to remember everyone that each project is quite able

[RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Cédric Champeau

This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
binding votes. Despite the negative votes, we will release and fix the L/N
files in the next release and try to clarify the README. It is very
important to get this 2.4.4 release out ASAP.

Thanks to all voters!

2015-07-13 10:33 GMT+02:00 Cédric Champeau cedric.champ...@gmail.com:

Hi all!

The Apache Groovy PPMC has successfully voted the release of Apache Groovy
2.4.4-incubating [1], with 6 +1 binding votes, one +1 non binding, no
0 votes and one -1 vote (see the explanation below). We are now asking
the IPMC to vote it too. Since it is our first release under the Apache
Software Foundation umbrella, let me give a few more details:

- this release is our second attempt to release Apache Groovy 2.4.4. The
first vote failed, mainly because our documentation was licensed under
Creative Commons by-sa. The issue has been mitigated with the community, we
have voted to relicense it under AL2.0 and approvals for all contributors
of the documentation have been tracked on a JIRA ticket (see below).
- since our pre-Apache era, all files have been modified to include the
normalized AL2.0 license headers. Files which couldn't be modified, such as
test files which must not include any header, have been excluded from Rat
checks.
- We have updated our build to use the Gradle license check plugin, then
Apache Rat plugin
- All jars have been removed from the source distribution, including those
which were used in tests (they are now generated by the build itself)
- Added the DISCLAIMER file, updated the LICENSE and NOTICE files
- Added a section on the README to indicate how to bootstrap Gradle, since
the Apache policy forbids to include the Gradle wrapper. It's worth noting
that Andrés actually missed that when he voted -1, meaning he thought the
wrapper was missing and that we couldn't build from source.
- We updated our release process for Apache (obviously), which already
required a noticeable amount of work. We have in particular worked with the
folks at JFrog to mitigate the problems we faced in automation (our
previous release process only required a single click...).

During the vote, the following points have been raised:

- the gradle.properties file doesn't contain the license header. This is
actually a glitch due to our automation process: builds are triggered from
the CI server which automates the update of the properties file. During
that process, the license header is lost. The consequence is that running
Rat from the source zip will fail with a warning on that file. However,
it is not critical since this file doesn't contain any IP, just version
number and VM parameters. We will fix this in the next release, by either
excluding the file from the Rat checks, or working with JFrog so that their
plugin reincludes the header file. This problem is the main reason for the
-1 vote we had from Andrés. In case of doubt, one can verify that it's
really the CI server which removed the license by checking this commit
(716b0b1bd5) which belongs to the REL_BRANCH_2_4_4 release branch.
- The incubating suffix (2.4.4-incubating) is only used on the source
zip. This is *intentional*. Groovy has a long history already, and our
users woudn't understand that newer releases include -incubating in the
version number. So the Maven artifacts, in particular, do not include
-incubating, which will greatly simplify upgrading and version conflict
resolution.
- Similarily, the directory that is created doesn't include apache- in
the file name. Some tools widely used in the community like GVM expect a
particular layout that would break if we changed that.

To summarize:

Vote on dev list:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201507.mbox/%3CCADQzvm%3DzDNCxpOua3LQ1ZNo62Aq40QZM7SJwgER5MfkArWrTeA%40mail.gmail.com%3E
Result of vote on dev list:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201507.mbox/%3CCADQzvmn1yEMMz_ZaCL5QqqUtQJdgd0NNcy8v7BVY8Lt4Uog0Zg%40mail.gmail.com%3E
Relicensing of the documentation tracking:
https://issues.apache.org/jira/browse/GROOVY-7470
Vote for relicensing the docs:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/%3CCADQzvm%3DMfajQuMxoZJmpLe%2B4W22a_MDY_dC4W%2BNMWiakEEOyNg%40mail.gmail.com%3E
Result of vote for relicensing the docs:
http://mail-archives.apache.org/mod_mbox/incubator-groovy-dev/201506.mbox/%3CCADQzvmkQyOEk3ofOrnTHfnvTKO5xECY87hKAGf5pD%2BuePyA8UA%40mail.gmail.com%3E

The changelog for this release can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123version=12331941

Tag for the release:
https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=commit;h=716b0b1bd56eeab04e4441eecc91c2cd8bfda8b6

https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2

The artifacts to be voted on are located

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Cédric Champeau

2015-07-16 10:41 GMT+02:00 Justin Mclean jus...@classsoftware.com:

 Hi,

  This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
  binding votes.

 If you read carefully I think you find there were 3 -1 votes on the binary
 releases.


Agreed for binaries. However AFAIK, what Apache legally cares about is
sources.



  It is very important to get this 2.4.4 release out ASAP.

 Given that the changes were not major and could of been quickly fixed I
 don't see the the need for the rush but no issue either way a long as they
 are fixed in the next release and before graduation.


There's a rush that has been discussed on private@. The reason will soon be
disclosed.. And given the 2x72h voting period, it was very problematic. And
honestly, too long since our community had an update of Groovy. Before we
joined Apache, releasing took a couple of hours, and releasing another
version was cheap. It's far from being the case anymore.



 Thanks,
 Justin
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-16 Thread Cédric Champeau

2015-07-16 18:49 GMT+02:00 Roman Shaposhnik ro...@shaposhnik.org:
 On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com 
 wrote:
 Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.

 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?

 Personally, I'm disappointed in the podling for not taking
 care of feedback that seems really easy to take care of.


Again, saying we don't take this seriously is at best an error and
honestly unfair. We take it very seriously and I am very disappointed
that you think we don't.
If you look at the commits, you will see that we started fixing those
issues *before* the release vote was finished. We *deserved* a release
for the community and *it was critical*. The
reasons why were explained on private@, and we could *not* afford
another 2x72 voting period + 24h mitigation period, that could also
potentially fail the IPMC vote (yes, because despite
the fact that we fixed all issues reported for our first trial, the
second had undetected errors too). Also, why having rules for votes if
you don't follow them? Like it or not, it passed the vote.

Not releasing would not have been serious, and we could have missed
the short timeframe we have given the vacations of the team.
It's also unfair because we took *very seriously* the comments for the
first attempt of the release, a few weeks ago, and fixed *all of them*
(and did even more than what you asked us to do).
So I think our community deserved that release more than having the
perfect LN files (especially because as we said, the License file
contains more, but not less, than required), and as
Paul said, all jars produces *do* have them.

 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

I sincerely hope my position is understood this time.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Cédric Champeau

No particular reason but avoiding putting on dist artifacts that maybe
downvoted, so the idea is to put the artifacts there once they've been
voted. Consider people.a.o as a staging repo for those artifacts.

2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

 HI,

  The artifacts to be voted on are located here:
  http://people.apache.org/~cchampeau/groovy/


 Is there any reason the artefacts are not available here: [1]
 https://dist.apache.org/repos/dist/dev/incubator/groovy

 Thanks,
 Justin

 1. http://www.apache.org/dev/release.html#host-rc

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Cédric Champeau

Here: http://www.apache.org/dev/release.html#host-rc



2015-07-13 13:48 GMT+02:00 Daniel Gruno humbed...@apache.org:

 Where is this documentation? If it is stated anywhere that
 people.apache.org is an acceptable place for RCs, it is clearly wrong and
 needs fixing.

 With regards,
 Daniel.


 On 2015-07-13 13:43, Gianmarco De Francisci Morales wrote:

 It would be good to update the piece of documentation that suggests to put
 RC on personal space on p.a.o.

 --
 Gianmarco

 On 13 July 2015 at 13:55, Cédric Champeau cedric.champ...@gmail.com
 wrote:

  Right. Will make sure to use it next time.

 2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:

  Hi Cédric,
 The whole point of the /dev/ branch on dist is for putting release
 candidates to be voted on.
 Once a release is approved, it is then moved to the /release/ branch.
 people.apache.org really should not be used for this, especially as
 that
 machine will probably disappear in the not-too-distant future.

 With regards,
 Daniel.


 On 2015-07-13 12:49, Cédric Champeau wrote:

  No particular reason but avoiding putting on dist artifacts that
 maybe
 downvoted, so the idea is to put the artifacts there once they've been
 voted. Consider people.a.o as a staging repo for those artifacts.

 2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

   HI,

   The artifacts to be voted on are located here:

 http://people.apache.org/~cchampeau/groovy/

  Is there any reason the artefacts are not available here: [1]
 https://dist.apache.org/repos/dist/dev/incubator/groovy

 Thanks,
 Justin

 1. http://www.apache.org/dev/release.html#host-rc

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org



  -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Cédric Champeau

Right. Will make sure to use it next time.

2015-07-13 12:53 GMT+02:00 Daniel Gruno humbed...@apache.org:

 Hi Cédric,
 The whole point of the /dev/ branch on dist is for putting release
 candidates to be voted on.
 Once a release is approved, it is then moved to the /release/ branch.
 people.apache.org really should not be used for this, especially as that
 machine will probably disappear in the not-too-distant future.

 With regards,
 Daniel.


 On 2015-07-13 12:49, Cédric Champeau wrote:

 No particular reason but avoiding putting on dist artifacts that maybe
 downvoted, so the idea is to put the artifacts there once they've been
 voted. Consider people.a.o as a staging repo for those artifacts.

 2015-07-13 12:46 GMT+02:00 Justin Mclean justinmcl...@me.com:

  HI,

  The artifacts to be voted on are located here:
 http://people.apache.org/~cchampeau/groovy/


 Is there any reason the artefacts are not available here: [1]
 https://dist.apache.org/repos/dist/dev/incubator/groovy

 Thanks,
 Justin

 1. http://www.apache.org/dev/release.html#host-rc

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org




 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Cédric Champeau

2015-07-13 16:03 GMT+02:00 Emmanuel Lécharny elecha...@gmail.com:

 Le 13/07/15 13:48, Daniel Gruno a écrit :
  Where is this documentation? If it is stated anywhere that
  people.apache.org is an acceptable place for RCs, it is clearly wrong
  and needs fixing.

 It's not written, it's a common usage for almost all of the projects,
 AFAICT. It's good to know that it's not the right place for such packages.

 It *was* written a couple of hours ago:

Projects typically use http://people.apache.org/~${RM}/** or the newer /dev
tree of the dist repository https://dist.apache.org/repos/dist/dev or the
staging features of repository.apache.org to host release candidates posted
for developer testing/voting (prior to being, potentially, formally blessed
as a GA release).

Now this has just been changed :)


 What's the alternative ?


 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Groovy 2.4.4-incubating

2015-07-13 Thread Cédric Champeau

Hi all!

During the vote, the following points have been raised:

To summarize:

The changelog for this release can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123version=12331941

Tag for the release:
https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=commit;h=716b0b1bd56eeab04e4441eecc91c2cd8bfda8b6

https://git1-us-west.apache.org/repos/asf?p=incubator-groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2

The artifacts to be voted on are located here:
http://people.apache.org/~cchampeau/groovy/

Release artifacts are signed with the following keys:
http://people.apache.org/~cchampeau/groovy/KEYS

Vote is open for at least 72 hours. Artifacts will be moved to dist as soon
as the vote passes.

[ ] +1, release Apache Groovy 2.4.4-incubating
[ ] 0, I don't care
[ ] -1, because...

Best regards,

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

2015-06-24 Thread Cédric Champeau


 +1

 Personally I think the policy should be clarified such that nightly builds
 MUST only live on ASF infrastructure (whether that be the Nexus SNAPSHOTs
 repo, committer web space etc).  As soon as you start putting them on
 external services like DockerHub then they are potentially widely visible
 to the general public.


Please do NOT do this. The policy is already painful enough. I can
understand why SOURCES must live
under the Apache organization infrastructure, because they are the ONLY
thing that legal cares about, but
please, for the sake of my mental sanity, do NOT impose any kind of
arbitrary rules like this for binaries/
distribution. It's total madness. Projects like Groovy have been using a
well working infrastructure for a
long time: snapshots published on a snapshot repository, releases pushed
onto Bintray, and we have good reasons
to do this. Our community *loves* to test snapshots, and they are not
stupid. They know that testing something
which is NOT an official release gives no guarantee whatsoever. I think we
should trust our community, and
not try to impose some kind of arbitrary process for the sake of having a
process.

I see no reason why one would like to impose using something like Nexus, it
should be the choice
of each project like it is today. Binaries/distributions are a convenience
and official releases *must* stay sources. For
anything else, it should be up to the project to decide.

I echo what Jochen said already: the move is towards continuous
integration. There's technically no difference between
a snapshot and a release. Apache makes it clear that some releases are
official and that an official release means that
sources for that release are voted and stamped as compliant. That's more
than enough. Toolchains, release process,
how we make binaries/distributions available for testing to our community
should remain under control of the project.

Re: Robot vs. personal KEYS for signing releases

2015-06-09 Thread Cédric Champeau

2015-06-08 17:41 GMT+02:00 David Nalley da...@gnsa.us:

 On Mon, Jun 8, 2015 at 9:40 AM, Cédric Champeau
 cedric.champ...@gmail.com wrote:
  We are not using the Apache CI servers for that but our own CI server.
 IMHO
  you should make a difference between building and checking. Building
 should
  be automated as much as possible. Checking the release is a human job.
  There are lots of reasons why we stopped releasing from a local computer
  years ago.

 Who has access to the keys? How are they secured, and what's the plan
 for going forward with that? (and this should all be documented) I ask
 this because I know of more than one project that has had a
 'centralized key' to sign with; but which the PMC didn't control; and
 that eventually caused problems when the person with access to the key
 disappeared from the community.


The key is on the CI server. All PMC members have access to it. It is also
on Bintray. I have signed the key too.

Re: Groovy release and LEGAL-171

2015-06-08 Thread Cédric Champeau

It can easily be replaced with a Gradle plugin.

2015-06-08 9:07 GMT+02:00 Sergio Fernández wik...@apache.org:

 Hi,

 my two cents without knowing in detail the issue:

 Could I make a clean build from a source release without that file?

 Without looking to the source code, I'm pretty sure it could be replaced by
 the right flags of the maven-javadoc-plugin...

 Other opinions better formed than mine are welcomed to the discussion.

 Cheers,


 On Mon, Jun 8, 2015 at 8:57 AM, Roman Shaposhnik r...@apache.org wrote:

  Hi!
 
  Groovy is currently voting a release where exactly
  the same issue as LEGAL-171 got raised. Their
  tarball currently contains the file in question:
  buildSrc/src/main/java/JavadocFixTool.java
  with the LICENSE described in LEGAL-171.
 
  My understanding is that this file should NOT
  be redistributed by releases of software under
  ALv2 even though Groovy only uses it during
  the build and doesn't create a shipable binary.
 
  Thoughts?
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 Sergio Fernández
 Partner Technology Manager
 Redlink GmbH
 m: +43 6602747925
 e: sergio.fernan...@redlink.co
 w: http://redlink.co

Re: Robot vs. personal KEYS for signing releases

2015-06-08 Thread Cédric Champeau

Well I guess the debate is because of Groovy and our use of robot keys, so
should vs must. If it's a should, I think we're ok. The reason we use
robot signing is automation. We want to avoid as many human intervention in
the release process as possible. That is to say, in the end, the whole
release process should be automated, only checking the artifacts should be
human based. This is not possible if we involve individual signatures.
Basically, for Groovy, before joining Apache, we used to automate
everything but checking the artifacts. It worked pretty well so far... Of
course one option is to put our private keys into the CI server but ahem...
I don't really like the idea of having my private key in the wild.

2015-06-08 14:50 GMT+02:00 Jake Farrell jfarr...@apache.org:

 The release manager should use their individual key, details on signing and
 keys are available at [1]

 -Jake

 [1]: http://www.apache.org/dev/release-signing.html

 On Mon, Jun 8, 2015 at 2:59 AM, Roman Shaposhnik r...@apache.org wrote:

  Hi!
 
  my recollection is that the collective opinion
  was to discourage the use of KEYS of robots
  for signing the releases and prefer individuals
  do that with their keys.
 
  I remember a thread to that effect, but I cant
  google it. Am I misremembering?
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org

Re: Robot vs. personal KEYS for signing releases

2015-06-08 Thread Cédric Champeau

We are not using the Apache CI servers for that but our own CI server. IMHO
you should make a difference between building and checking. Building should
be automated as much as possible. Checking the release is a human job.
There are lots of reasons why we stopped releasing from a local computer
years ago.

2015-06-08 15:36 GMT+02:00 Jake Farrell jfarr...@apache.org:

 No debate, the Apache CI servers are not intended to produce release
 artifacts and should not be used for this purpose. The release manager
 should build the artifacts locally and sign them before uploading them to
 be tested and voted on. Most projects have this process scripted out fully
 and will run the same script run on jenkins and then if a release flag is
 used sign and upload the artifacts accordingly (would also recommend making
 a template of the vote email so links and other details are not hand
 edited). If you would like any examples please let me know

 -Jake


 On Mon, Jun 8, 2015 at 8:55 AM, Cédric Champeau cedric.champ...@gmail.com
 
 wrote:

  Well I guess the debate is because of Groovy and our use of robot keys,
 so
  should vs must. If it's a should, I think we're ok. The reason we use
  robot signing is automation. We want to avoid as many human intervention
 in
  the release process as possible. That is to say, in the end, the whole
  release process should be automated, only checking the artifacts should
 be
  human based. This is not possible if we involve individual signatures.
  Basically, for Groovy, before joining Apache, we used to automate
  everything but checking the artifacts. It worked pretty well so far... Of
  course one option is to put our private keys into the CI server but
 ahem...
  I don't really like the idea of having my private key in the wild.
 
  2015-06-08 14:50 GMT+02:00 Jake Farrell jfarr...@apache.org:
 
   The release manager should use their individual key, details on signing
  and
   keys are available at [1]
  
   -Jake
  
   [1]: http://www.apache.org/dev/release-signing.html
  
   On Mon, Jun 8, 2015 at 2:59 AM, Roman Shaposhnik r...@apache.org
 wrote:
  
Hi!
   
my recollection is that the collective opinion
was to discourage the use of KEYS of robots
for signing the releases and prefer individuals
do that with their keys.
   
I remember a thread to that effect, but I cant
google it. Am I misremembering?
   
Thanks,
Roman.
   
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Robot vs. personal KEYS for signing releases

2015-06-08 Thread Cédric Champeau


 Would it be possible to sign the robot keys with your own keys?

 I think it is possible, yes.

Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...

2015-03-26 Thread Cédric Champeau

 In the case of groovy, does Pivotal own it or does someone else own it?

Nobody owns it.

   If
 I look at https://github.com/groovy/groovy-core/blob/master/NOTICE it
 indicates that an entity known as The Groovy community owns it, in which
 case the SGA should probably come from them, no?  Or is The Groovy
 community not a legal entity?

 The Groovy community is not a legal entity. A lot of people contributed to
Groovy already, and in the Groovy ecosystem, the community is a notion
larger than the language itself.

Re: [GROOVY] mailing lists are ready, see you there!

2015-03-26 Thread Cédric Champeau

BTW should we already update the links [1] on the website? How should we
proceed to migrate/deprecate the Codehaus lists?

[1] http://groovy-lang.org/mailing-lists.html

2015-03-26 20:34 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com:

 I got them too.
 Le 26 mars 2015 19:10, Guillaume Laforge glafo...@gmail.com a écrit :

 I also got moderation messages

 2015-03-26 18:51 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:

  I don't.
 
  On Thu, Mar 26, 2015 at 10:47 AM, Andrew Bayer andrew.ba...@gmail.com
  wrote:
   Just making sure - others besides me are getting the subscribe
 moderation
   emails?
  
   A.
  
   On Thu, Mar 26, 2015 at 10:22 AM, Bertrand Delacretaz 
   bdelacre...@apache.org wrote:
  
   On Thu, Mar 26, 2015 at 6:21 PM, Jochen Theodorou blackd...@gmx.org
 
   wrote:
...listname-subscribe@groovy.incubator.a.o ?
  
   of course yes, sorry - the names on INFRA-9339 are correct.
  
   -Bertrand
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 Guillaume Laforge
 Groovy Project Manager

 Blog: http://glaforge.appspot.com/
 Social: @glaforge http://twitter.com/glaforge / Google+
 https://plus.google.com/u/0/114130972232398734985/posts

Re: [GROOVY] mailing lists are ready, see you there!

2015-03-26 Thread Cédric Champeau

I got them too.
Le 26 mars 2015 19:10, Guillaume Laforge glafo...@gmail.com a écrit :

 I also got moderation messages

 2015-03-26 18:51 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:

  I don't.
 
  On Thu, Mar 26, 2015 at 10:47 AM, Andrew Bayer andrew.ba...@gmail.com
  wrote:
   Just making sure - others besides me are getting the subscribe
 moderation
   emails?
  
   A.
  
   On Thu, Mar 26, 2015 at 10:22 AM, Bertrand Delacretaz 
   bdelacre...@apache.org wrote:
  
   On Thu, Mar 26, 2015 at 6:21 PM, Jochen Theodorou blackd...@gmx.org
   wrote:
...listname-subscribe@groovy.incubator.a.o ?
  
   of course yes, sorry - the names on INFRA-9339 are correct.
  
   -Bertrand
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 Guillaume Laforge
 Groovy Project Manager

 Blog: http://glaforge.appspot.com/
 Social: @glaforge http://twitter.com/glaforge / Google+
 https://plus.google.com/u/0/114130972232398734985/posts

Re: [Groovy] Next steps...

2015-03-26 Thread Cédric Champeau

Thank you all! I still have a few days full time on Groovy, so if we can
leverage that to start the migration of the Git repo for example it would
be nice. Not sure what is required though, given we're migrating from
GitHub.

Also I have a document ready that describes the questions and necessary
steps to adapt our release process. It's an asciidoc document that I
convert locally to HTML, I wonder what's the best way to share it.

2015-03-26 8:25 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org:

 On Thu, Mar 26, 2015 at 7:54 AM, Guillaume Laforge glafo...@gmail.com
 wrote:
  For JIRA, can you import our JIRA from Codehaus?
  http://jira.codehaus.org/browse/GROOVY

 Emmanuel created INFRA-9340 for that and the main Codehaus Jira
 migration ticket is INFRA-9116

 -Bertrand

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] [VOTE] Accept Groovy into the Apache Incubator

2015-03-23 Thread Cédric Champeau

Awesome! Thanks everyone! Now we rely on our champion and mentors to help
us get started :)

2015-03-23 17:54 GMT+01:00 Roman Shaposhnik r...@apache.org:

 On Wed, Mar 18, 2015 at 11:55 PM, Roman Shaposhnik r...@apache.org wrote:
  Following the discussion earlier in the thread:
 http://s.apache.org/KWE
 
  I would like to call a VOTE for accepting Groovy
  as a new incubator project.
 
  The proposal is available at:
  https://wiki.apache.org/incubator/GroovyProposal
  and is also included at the bottom of this email.
 
  Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST
 
   [ ] +1 accept Groovy in the Incubator
   [ ] ±0
   [ ] -1 because...

 With 27 +1 binding votes, 14 +1 non-binding votes (41 +1 votes total)
 NO +/-0 or -1 votes, this VOTE passes.

 Thanks to all who voted! Here's a tally of +1 binding votes:
Emmanuel Lecharny
Romain Manni-Bucau
Rob Vesse
Upayavira
John D. Ament
Olivier Lamy
Bertrand Delacretaz
Daniel Kulp
Nick Burch
Siegfried Goeschl
Jake Farrell
Matt Franklin
Henry Saputra
Alan Cabrera
Jan I
Richard Frovarp
Konstantin Boudnik
Andrus Adamchik
   Jean-Baptiste Onofré
   Andrew Bayer
   Chris Mattmann
   Ted Dunning
   John Chambers
   Andrew Purtell
   Ate Douma
   Sergio Fernández
   Roman Shaposhnik
 and an additional tally of +1 non-binding votes:
   Stian Soiland-Reyes
   Ashish Paliwal
   Benedikt Ritter
   Jacopo Cappellato
   Marvin Humphrey
   Stuart Williams
   Jacques Le Roux
   Amareshwari Sriramdasu
   Dennis E. Hamilton
   Luke Han
   Stephen Connolly
   Dave Lester
   James Masanz
   P. Taylor Goetz

 Thanks,
 Roman.

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-17 Thread Cédric Champeau


Hi Hervé,

It would be very nice, if it fits the general schedule (Groovy is not 
yet voted).


Best regards,

On 16/03/2015 23:00, Hervé Boutemy wrote:

Hi,

We're scheduling the Jira migration for Maven projects on the week-end of
4/5/6 april.
If this schedule is fine for Groovy, I suppose it would be ok to add Groovy
Jira project to the actual list [1]
Just tell, and I'll avoid to remove Groovy from the full dump we'll have
during the migration.

Regards,

Hervé

Notice: please CC me if necessary, since I'm not subscribed to
general@incubator

[1] https://issues.apache.org/jira/browse/INFRA-9116

Le lundi 16 mars 2015 09:53:00 Stephen Connolly a écrit :

Arg! hit send too soon.

You should really check in with Hervé to confirm that Groovy was in the
export. I am 99% confident that your issues and comments are in the XML
dump, but you really should check with Hervé to be certain.

Also you may want to ask Mark Thomas what exactly is involved in preparing
and doing such an import. Our own timelines for Maven's switch may not
align with the Groovy incubation timelines... (mind you we are all at the
grace of Ben for getting our timeline for the second export he committed to
the Maven project)

On 16 March 2015 at 09:49, Stephen Connolly stephen.alan.conno...@gmail.com

wrote:



On 16 March 2015 at 09:19, Cédric Champeau cedric.champ...@gmail.com

wrote:

Thanks Stephen, sounds like a good news. For us the attachments do not
matter much, there are not so many. However, keeping track of comments is
very important, because some issues have a lot of discussions.

2015-03-16 10:08 GMT+01:00 Stephen Connolly 
stephen.alan.conno...@gmail.com


On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org wrote:

Am 16.03.2015 09:25, schrieb Upayavira:

When Stephen Connolly says ”We @ Maven will have a full dump of the
Codehaus JIRA and we have a VM set
up to test migration…” isn’t he implying that the Groovy issues are
*included* in that? I.e. there’s not so much for you to worry about
here?

Even if Stephen gets a full dump, this does not mean we will get the
Groovy part out of it. Ben was so far telling us he cannot give it
out

like


that, because of private and internal data in there. Instead he

suggested a


json export (which most likely will not contain everything)

Well we are getting the full XML dump because that's all you can get
via
the XML dump, but whether we get *all* attachments or only those for

Maven


is a different question.


So unless Stephy has this clear with his employee I stand on the
part,
that we don't have that.

Clarification: Ben and I are co-workers.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Vote ? was [DISCUSS] Groovy Incubation proposal

2015-03-17 Thread Cédric Champeau


On 17/03/2015 15:34, Bertrand Delacretaz wrote:

On Tue, Mar 17, 2015 at 3:19 PM, Emmanuel Lécharny elecha...@gmail.com wrote:

...We already have demonstrated our ability to raises various points on
various subjects, time to demonstrate The ASF in action !..

+1 - as I said elsethread it's in theory Roman's job to start the
vote, as the Groovy champion.

But I guess if any of the mentors feel impatient we can do that as
well...going once... ;-)

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

I wouldn't mind starting a vote early, given the time constraints that 
we have :)


--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-16 Thread Cédric Champeau

Thanks Stephen, sounds like a good news. For us the attachments do not
matter much, there are not so many. However, keeping track of comments is
very important, because some issues have a lot of discussions.

2015-03-16 10:08 GMT+01:00 Stephen Connolly stephen.alan.conno...@gmail.com
:

 On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org wrote:

  Am 16.03.2015 09:25, schrieb Upayavira:
 
  When Stephen Connolly says ”We @ Maven will have a full dump of the
  Codehaus JIRA and we have a VM set
  up to test migration…” isn’t he implying that the Groovy issues are
  *included* in that? I.e. there’s not so much for you to worry about
  here?
 
 
  Even if Stephen gets a full dump, this does not mean we will get the
  Groovy part out of it. Ben was so far telling us he cannot give it out
 like
  that, because of private and internal data in there. Instead he
 suggested a
  json export (which most likely will not contain everything)
 

 Well we are getting the full XML dump because that's all you can get via
 the XML dump, but whether we get *all* attachments or only those for Maven
 is a different question.


 
  So unless Stephy has this clear with his employee I stand on the part,
  that we don't have that.


 Clarification: Ben and I are co-workers.


 
 
  bye Jochen
 
  --
  Jochen blackdrag Theodorou - Groovy Project Tech Lead
  blog: http://blackdragsview.blogspot.com/
  german groovy discussion newsgroup: de.comp.lang.misc
  For Groovy programming sources visit http://groovy-lang.org
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-13 Thread Cédric Champeau

Yes the biggest problem is going to be the migration of JIRA. Codehaus only
wants to provide a CSV export which is far from being enough for us. I hope
someone at Apache has experience on this and will be able to get in touch
with Codehaus to provide a better migration path.

2015-03-13 18:33 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org:

 On Fri, Mar 13, 2015 at 5:49 PM, Stian Soiland-Reyes st...@apache.org
 wrote:
  ...Is the wider Groovy community aware that transitioning to Apache is
 not
  done overnight? There is no guarantee this will be complete by mid-April,
  which to me sounds optimistic...

 The full transition might take some time, but as soon as a podling has
 a dev mailing list, code repository and issue tracker it can start to
 operate.

 And code obviously...so working on the software grants already [1]
 might be a good idea, and the Groovy podling committers who don't have
 @apache.org accounts yet can already send their iCLAs in [2], that
 doesn't hurt.

 Apache accounts creation is fast these days in my experience, I
 haven't seen  24 hours lately.

 -Bertrand

 [1] https://www.apache.org/licenses/software-grant.txt
 [2] http://www.apache.org/licenses/icla.txt

 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-12 Thread Cédric Champeau


On 12/03/2015 17:53, Daniel Kulp wrote:

On Mar 12, 2015, at 8:51 AM, Bertrand Delacretaz bdelacre...@apache.org wrote:

On Thu, Mar 12, 2015 at 12:04 PM, Jochen Wiedmann
jochen.wiedm...@gmail.com wrote:

... I am quite certain, most Incubator members would accept a project to
have a vibrant community, if the project could show, for example,...

Note that we don't care about the state of the community when entering
the incubator, that's an exit criteria. Not even vibrant for exit,
just a community that is open to including new people and knows how to
do that as an Apache project.


Agreed.   And personally, I prefer the smaller “enter” community compared to 
the piling on of bunches of people that may or may not contribute that I’ve 
seen on a bunch of projects. I’d greatly prefer seeing the community 
start small and “grow” during incubation.


Agreed. Even though I think Groovy is IMHO special. It's a 12 years old 
project, which have seen lots of contributors. Some contributed a lot in 
the past, some contribute a lot now and even some always contributed.I 
have no doubt more committers will come, and more people will contribute.


I understand why we need to go through the incubation phase, but there 
are things like this which bother me. I think Apache and Groovy worked 
more or less the same way in the way we accept new committers: 
contribute on a regular basis, with our quality standards and you're 
good to go. Not so many candidates but I can already see some, but in 
any case, I think meritocracy is very important. So I see no point in 
wanting to reach a target number of committers. Having a large number of 
quality contributions, more contributors is IMHO more important than 
people having write access to the repo.


And as seeing a language like Groovy grow during incubation, it all 
depends how long we will stay in incubating phase. I just recently 
realized for example that we would have to version with -incubating. For 
our community, for our users (and for me), it is very strange to have a 
12 yo project suddenly having version with -incubating. For example 
we're about to release 2.4.2, and then we would have 2.4.3-incubating. I 
don't like it at all because it sounds like not ready. So the shorter 
the incubation phase, the better. And if there are arbitrary objectives 
like let's reach X committers, I don't really see the point. 
Understanding the Apache Way is important, adapting the release process 
is important, making sure that we respect the community is very 
important. The number of committers is not.


--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-12 Thread Cédric Champeau


On 12/03/2015 18:19, Roman Shaposhnik wrote:

On Thu, Mar 12, 2015 at 10:13 AM, Cédric Champeau
cedric.champ...@gmail.com wrote:

I made this remark to myself, which is that too many people still think that
Groovy is only a dynamic language. I think it's a problem because
it's not, and some people really dislike dynamic languages. When they read
something like the Groovy dynamic object-oriented programming language
(from the Apache blog post)
may not realize that it's much more than that (it was only dynamic a few
years ago, but it has evolved a lot, and now a static language as much as
it is a dynamic one). So I would lean towards rephrasing the first paragraph
of the proposal from It is a primarily dynamic language with features
similar to those of Python, Ruby, Perl, and Smalltalk.
to It is a programming language with features similar to those of Python,
Ruby, Java, Perl, and Smalltalk.
And if possible, everything we see dynamic programming language, remove
the mention to dynamic to just programming language. What do you think?
It's not that I don't like the dynamic
programming aspects of Groovy of course, but I think we should not cut off
part of our user base just by making erroneous statements.

Sure. That looks good to me. That being said -- what's written on the proposal
is only important to the IPMC so I don't think it'll be a huge change in outside
perception one way or another.
In fact, my reaction comes from the fact that I am reading many press 
articles where we read the Groovy dynamic language or variants.
And since this is written in the Apache Blog itself[1] and the proposal 
[2] we cannot really blame them. Marketing-wise, looks like a bad move :)


[1] https://blogs.apache.org/foundation/entry/groovy_submitted_to_become_a
[2] https://wiki.apache.org/incubator/GroovyProposal

--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-12 Thread Cédric Champeau

 ===

The community proposing Groovy for incubation is a strong and vibrant
open source project. Even though the sponsorship of the core team by
Pivotal is ending on March 31st, the sheer size and diversity of the
community is a guarantee against the project being orphaned.

=== Inexperience with Open Source ===
The majority of the proposers here have day jobs that has them working near
full-time on open source projects. A few of us have helped carry
other projects through the Incubator.  Groovy to date has been developed as
an open source project.

=== Homogeneous Developers ===
Now that Pivotal is ending its sponsorship, the initial group of committers
is going to be extremely heterogeneous when it comes to corporate affiliations.
The Groovy community is also extremely diverse in terms of geography and
backgrounds of developers.

=== Reliance on Salaried Developers ===
Most of the contributors are paid to work in the Java ecosystem.
While we might wander from our current employers, we probably won’t
go far from the Java family tree.

=== Relationships with Other Apache Products ===
Groovy currently has a few ASF projects as optional dependencies but
otherwise doesn't depend on any ASF projects. A few
ASF projects already depend on Groovy.

=== An Excessive Fascination with the Apache Brand ===
While we intend to leverage the Apache ‘branding’ when talking to other
projects as testament of our project’s ‘neutrality’, we have no plans
for making use of Apache brand in press releases nor posting billboards
advertising acceptance of Groovy into Apache Incubator.


== Documentation ==
See [[http://www.groovy-lang.org/documentation.html|documentation]]
for the current state of the Groovy documentation.

A mature project website is also available at
[[http://www.groovy-lang.org/|groovy-lang.org]].

== Initial Source ==
Initial source is available on GitHub under the ALv2
[[https://github.com/groovy/groovy-core|groovy-core]]


== Source and Intellectual Property Submission Plan ==
We know of no legal encumberments in the way of transfer of source to
Apache. In fact, given the series of corporate due diligence
procedures performed on the source code during two of the acquisitions
we expect the code base to be squeaky clean from an IP perspective.

== External Dependencies ==
Embedded dependencies (relocated):

* Antlr 2, ANTLR 2 License (development branch includes Antlr4
using BSD license)
* ASM, BSD
* Openbeans (ALv2)
* Apache Commons CLI (ALv2)

Module or optional dependencies:

* Apache Ant (ALv2)
* Apache Commons BSF (ALv2)
* Apache Commons Logging (ALv2)
* Apache Ivy (ALv2)
* Apache Log4j (ALv2)
* Apache Log4j 2 (ALv2)
* JAnsi (ALv2)
* JCommander (ALv2)
* JLine 2 (BSD)
* JUnit (EPL 1.0)
* Logback (EPL 1.0)
* QDox (ALv2)
* SLF4J (MIT)
* TestNG (ALv2)

Build only dependencies:

* bnd (ALv2)
* jarjar (ALv2)
* Checkstyle (LGPL)
* Cobertura (GPL)
* Gradle (ALv2)
* Asciidoctor (MIT)
* Simian (http://www.harukizaemon.com/simian/get_it_now.html)

Test only dependencies:

* Apache Commons HTTP Client (ALv2)
* Apache Lucene (ALv2)
* Eclipse OSGi (EPL 1.0)
* GPars (ALv2)
* HSQLDB (BSD)
* JMock (jMock Project License)
* OpenEJB (ALv2)
* Spock (ALv2)
* XMLUnit 1 (BSD)
* XStream (BSD)

Cryptography
N/A

== Required Resources ==

=== Mailing lists ===
   * priv...@groovy.incubator.apache.org (moderated subscriptions)
   * comm...@groovy.incubator.apache.org
   * d...@groovy.incubator.apache.org
   * iss...@groovy.incubator.apache.org
   * u...@groovy.incubator.apache.org

=== Git Repository ===
https://git-wip-us.apache.org/repos/asf/incubator-groovy.git

=== Issue Tracking ===
JIRA Groovy (GROOVY)

=== Other Resources ===

A build server is currently sponsored by Jetbrains (TeamCity):
http://ci.groovy-lang.org?guest=1
The CI server has a number of build plans including multiple JDKs (5
to 9), 3rd party joint builds and integration with the Groovy website
(automatic deployment upon push).

Means of setting up regular builds for Groovy on builds.apache.org

== Initial Committers ==
   * Cédric Champeau
   * Guillaume Laforge
   * Jochen Theodorou
   * Paul King
   * Pascal Schumacher

== Affiliations ==
   * Pivotal: Cédric Champeau, Jochen Theodorou
   * Restlet: Guillaume Laforge
   * ASERT: Paul King
   * Pascal Schumacher

== Sponsors ==

=== Champion ===
Roman Shaposhnik

=== Nominated Mentors ===
   * Bertrand Delacretaz - Apache Member
   * Emmanuel Lecharny - Apache Member
   * Jim Jagielski - Apache Member
   * Roman Shaposhnik - Apache Member
   * Andrew Bayer - Apache Member
   * Konstantin Boudnik - IPMC Member

Six mentors is plenty, we are not looking for more mentors at this time.

=== Sponsoring Entity ===
We would like to propose Apache incubator to sponsor this project.



--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http

Re: [DISCUSS] Groovy Incubation proposal

2015-03-11 Thread Cédric Champeau

Don't worry your question is perfectly legitimate. I don't know if it's
specific to Groovy, but we indeed have a lot of contributors, but not so
many recurrent one that may become committers.

2015-03-11 22:11 GMT+01:00 jan i j...@apache.org:

 On Wednesday, March 11, 2015, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  On Wed, Mar 11, 2015 at 12:08 PM, jan i j...@apache.org javascript:;
  wrote:
   Hi.
  
   Having just skimmed the proposal, that in general look good, one thing
   caught my eye.
  
   The proposal talks several places about a vibrant community and the
  initial
   commiters are only 5.
 
  This, is a GREAT question! Thank you so much for raising it. While
  preparing a proposal I've struggled with the same issue, because looking
  at this: https://github.com/groovy/groovy-core/graphs/contributors makes
  me wonder exactly the same thing.
 
  In the end, we decided to go ahead with the proposal the way it is and
  position
  the initial list of committers more as a PMC for the project.
 
  That still doesn't answer your (or mine! ;-)) question of what's the best
  way
  to make sure than anybody who feels like they have a stake in the project
  and have contributed in the past get invited.
 
  There are a few alternatives I could see, but I would really
  appreciate Incubator's
  collective wisdom on what would be the best way to proceed here given
  that Groovy is a very mature project with a lot of contributors in the
  past.
  Some of whom may or may not wish to keep contributing.


 Just to be sure I am not misunderstood, I will be happy to vote +1 with 5
 initial committers.

 I was simply (as you) puzzled over what seems to non logical.

 rgds
 jan i

 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  javascript:;
  For additional commands, e-mail: general-h...@incubator.apache.org
  javascript:;
 
 

 --
 Sent from My iPad, sorry for any misspellings.

Re: [DISCUSS] Groovy Incubation proposal

2015-03-11 Thread Cédric Champeau

A good answer to this is to take a look at who actually contributed for the
past 4 years:
https://github.com/groovy/groovy-core/graphs/contributors?from=2011-01-01to=2015-03-11type=c
and you will see that there are not so many regular contributors. GitHub
helped us a lot recently to have more contributions, from simple typos to
complex bug fixes, but one should not forget that a contribution in GitHub
doesn't mean that the author is a committer : it's just that authors are
preserved.

While we have a lot of contributors, only a few of us have a deep knowledge
of Groovy internals. We will certainly encourage regular contributors to
become committers (we already think of some), as long as those are
following quality standards, take care of important things like maintaining
backwards compatibility etc... We had more than 5 committers in the past,
but lots of them just stopped pushing code, for various reasons. In the end
I would be the first pleased to see more committers, but meritocracy is
also important. And to be clear, we do not think only about code:
contributions like documentation or tests are also very important.

2015-03-11 20:17 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:

On Wed, Mar 11, 2015 at 12:08 PM, jan i j...@apache.org wrote:
Hi.

Having just skimmed the proposal, that in general look good, one thing
caught my eye.

The proposal talks several places about a vibrant community and the
initial
commiters are only 5.

This, is a GREAT question! Thank you so much for raising it. While
preparing a proposal I've struggled with the same issue, because looking
at this: https://github.com/groovy/groovy-core/graphs/contributors makes
me wonder exactly the same thing.

In the end, we decided to go ahead with the proposal the way it is and
position
the initial list of committers more as a PMC for the project.

That still doesn't answer your (or mine! ;-)) question of what's the best
way
to make sure than anybody who feels like they have a stake in the project
and have contributed in the past get invited.

There are a few alternatives I could see, but I would really
appreciate Incubator's
collective wisdom on what would be the best way to proceed here given
that Groovy is a very mature project with a lot of contributors in the
past.
Some of whom may or may not wish to keep contributing.

Thanks,
Roman.

Re: [DISCUSS] Groovy Incubation proposal

2015-03-11 Thread Cédric Champeau

2015-03-11 21:24 GMT+01:00 Benedikt Ritter brit...@apache.org:

Is the groovy project aware that (to my knowledge) the coding has to happen
on ASF infrastructure? You won't be able to use the github web UI for
merging PRs for example, because currently the ASF only mirrors git
repositories from git.apache.org to github.

Yes, we are aware (and TBH a bit worried about it) of it, but we hope that
it will be minor inconvenience. In particular GitHub has proved to be a
very effective tool to bring new contributors and we fear that having the
Groovy project in the middle of a ton of other projects in the apache
organization will reduce the number of PRs we receive, but I guess this is
a price to pay.

I'm very excited about this project, and will definitively be on board if
groovy enters incubation.

Thanks!

Benedikt

2015-03-11 21:11 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com:

A good answer to this is to take a look at who actually contributed for
the
past 4 years:

https://github.com/groovy/groovy-core/graphs/contributors?from=2011-01-01to=2015-03-11type=c
and you will see that there are not so many regular contributors. GitHub
helped us a lot recently to have more contributions, from simple typos to
complex bug fixes, but one should not forget that a contribution in
GitHub
doesn't mean that the author is a committer : it's just that authors are
preserved.

While we have a lot of contributors, only a few of us have a deep
knowledge
of Groovy internals. We will certainly encourage regular contributors to
become committers (we already think of some), as long as those are
following quality standards, take care of important things like
maintaining
backwards compatibility etc... We had more than 5 committers in the past,
but lots of them just stopped pushing code, for various reasons. In the
end
I would be the first pleased to see more committers, but meritocracy is
also important. And to be clear, we do not think only about code:
contributions like documentation or tests are also very important.

2015-03-11 20:17 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:

On Wed, Mar 11, 2015 at 12:08 PM, jan i j...@apache.org wrote:
Hi.

Having just skimmed the proposal, that in general look good, one
thing
caught my eye.

The proposal talks several places about a vibrant community and the
initial
commiters are only 5.

This, is a GREAT question! Thank you so much for raising it. While
preparing a proposal I've struggled with the same issue, because
looking
at this: https://github.com/groovy/groovy-core/graphs/contributors
makes
me wonder exactly the same thing.

In the end, we decided to go ahead with the proposal the way it is and
position
the initial list of committers more as a PMC for the project.

That still doesn't answer your (or mine! ;-)) question of what's the
best
way
to make sure than anybody who feels like they have a stake in the
project
and have contributed in the past get invited.

Thanks,
Roman.

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

43 matches

Mail list logo