You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Cédric Champeau <ce...@gmail.com> on 2015/07/16 10:31:27 UTC
[RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
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 <ce...@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=12318123&version=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: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Cédric Champeau <ce...@gmail.com>.
2015-07-16 10:41 GMT+02:00 Justin Mclean <ju...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 16/07/15 19:48, Daniel Gruno a écrit :
> Can someone show me where in the bylaws this dreaded and apparently
> mandatory 72+ hour window is?
> When last I looked, it was the preferred thing to do in most
> circumstances, it was not _MANDATED BY LAW_.
Nobody said that. However, I like it when a pdoling absorbed the
information that a vote must be hold for 72 h : that means they
understand how it works.
That being said, you are right : those 72 h can be bypassed when required.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Daniel Gruno <hu...@apache.org>.
Can someone show me where in the bylaws this dreaded and apparently
mandatory 72+ hour window is?
When last I looked, it was the preferred thing to do in most
circumstances, it was not _MANDATED BY LAW_.
If this issue is as serious as you say it is, fix the minor nits, call a
speedy new vote, get your 3x+1, get it shipped.
Just don't make it a habit.
With regards,
Daniel.
On 2015-07-16 19:34, Jochen Theodorou wrote:
> Am 16.07.2015 18:49, schrieb Roman Shaposhnik:
>> On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny
>> <el...@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.
>
> but not in time, because the apache process is too slow. What so you
> prefer? A unfixed zero-day vulnerability reported against an apache
> project, or a podling release which is not 100% according to strict
> apache views. We are not a TLP yet after all.
>
> And this release is a special case.
>
> That security fix is the only reason why we did want release ASAP. We
> own it to the community to be able to react to such things fast. And I
> really would not like to explain to our users that we could not do a
> release, because of a minor issue. If the apache process would not be
> so slow, we would of course have made it different. But waiting
> another 6 days, while some will be in holidays already, would have
> been a problem.
>
> bye blackdrag
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by jan i <ja...@apache.org>.
On Thursday, July 16, 2015, Jochen Theodorou <bl...@gmx.org> wrote:
> Am 16.07.2015 18:49, schrieb Roman Shaposhnik:
>
>> On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny <el...@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.
>>
>
> but not in time, because the apache process is too slow. What so you
> prefer? A unfixed zero-day vulnerability reported against an apache
> project, or a podling release which is not 100% according to strict apache
> views. We are not a TLP yet after all.
>
> And this release is a special case.
>
> That security fix is the only reason why we did want release ASAP. We own
> it to the community to be able to react to such things fast. And I really
> would not like to explain to our users that we could not do a release,
> because of a minor issue. If the apache process would not be so slow, we
> would of course have made it different. But waiting another 6 days, while
> some will be in holidays already, would have been a problem.
Security problems must be dealt with as fast as possible even if it means
twisting the apache process.
rgds
jan i
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> blog: http://blackdragsview.blogspot.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
--
Sent from My iPad, sorry for any misspellings.
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 16.07.2015 18:49, schrieb Roman Shaposhnik:
> On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny <el...@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.
but not in time, because the apache process is too slow. What so you
prefer? A unfixed zero-day vulnerability reported against an apache
project, or a podling release which is not 100% according to strict
apache views. We are not a TLP yet after all.
And this release is a special case.
That security fix is the only reason why we did want release ASAP. We
own it to the community to be able to react to such things fast. And I
really would not like to explain to our users that we could not do a
release, because of a minor issue. If the apache process would not be so
slow, we would of course have made it different. But waiting another 6
days, while some will be in holidays already, would have been a problem.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Cédric Champeau <ce...@gmail.com>.
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 <el...@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 L&N 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 L&N 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 to define
> the way they do things, as soon as they fits in the Apache process,
> which is not that rigid. At this point, we may dedicate some time with
> mentors, someone from infra and obviously the project's RM. If we don't
> do that now we are painfully impairing the project...
>
> My 2cts.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Paul King <pa...@asert.com.au>.
On 17/07/2015 8:09 PM, Emmanuel Lécharny wrote:
> Le 17/07/15 12:02, Jochen Theodorou a écrit :
>> Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
>> [...]
>>> 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.
>>
>> that would not change anything. What makes things complicated is
>> points of human interaction in the middle of the release process. That
>> won't be different with a better tuned CI
> I'm puzzled. Cédric said in a previous mail that before being an Apache
> podling, releasing was just a matter of a couple of hours and very few
> human interaction. What makes it so more complex in an Apache environement ?
Cédric already explained in other emails and in his release process
documentation some of the nitty gritty details so I won't repeat that.
The tl;dr version is that we had a fully automated process that took
care of many of the tricky aspects of a Groovy release (we have to
build on recent JDK versions to bake in invoke dynamic behavior but
still run on old JDK versions and avoid the many JDK versions with
early buggy invoke dynamic support). Our previous setup used
machines (outside ASF) and software (Team City) that don't fit the
Apache mold. We have broken our original process into pieces so that
we can stop it (e.g. for voting) half-way through and so that we have
artifacts that we can potentially feed back into existing Apache
processes. Over time we could retrofit more of the pieces that don't
fit the current mold into more Apache friendly variants but we aren't
in a position to down tools for three months and change everything now.
Our users expect new features and new releases and we must balance
the time we spend on sideways or backwards movements on the
infrastructure side of things.
Cheers, Paul.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Guillaume Laforge <gl...@gmail.com>.
I'm particularly interested in the build / release aspect here. What were
the Cordova struggles.
For the L&N, that's indeed a human task that has to be done once (plus some
Rat & automated checks)
What I'd like is to be able to automate the release as much as possible,
with the least error prone human interaction.
Le 17 juil. 2015 18:21, "Alex Harui" <ah...@adobe.com> a écrit :
>
>
> On 7/17/15, 7:05 AM, "Guillaume Laforge" <gl...@gmail.com> wrote:
>
> >On Fri, Jul 17, 2015 at 3:59 PM, Alex Harui <ah...@adobe.com> wrote:
> >
> >> [...]
> >> And if folks are interested in other stories about release process
> >> inefficiency, I will write to some Cordova folks off-list and ask them
> >>to
> >> add their thoughts to this thread.
> >>
> >
> >Hmm this might be interesting, to see if there are some commonalities
> >between theirs and our problems with our now sub-par release process.
> >Apache, for me, should thrive for the best release quality process, but
> >we've had to regress in that area to comply with the Apache expectations
> >(with the various manual steps, etc), and I'm hopeful we can further
> >improve such process for more automation, less human intervention, shorter
> >release times, etc.
>
> I don’t know how IP checking was done in the past for Groovy, but I don’t
> know of a way to automate comparing the format of Apache L&N against the
> contents of the packages, so I’ve resigned myself to some level of human
> involvement. I just hope those with the best techniques for finding
> issues will share them.
>
> It was pointed out to me that this is a pretty big list, so instead of
> having the Cordova folks join this thread and re-hash the past
> discussions, I’ll supply a link to a public archive of one thread. There
> are a couple of other threads on non-public lists. And you can probably
> drop in on the Cordova dev list and have them get involved on your dev
> list.
>
> http://s.apache.org/kvO
>
>
> -Alex
>
>
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Alex Harui <ah...@adobe.com>.
On 7/17/15, 7:05 AM, "Guillaume Laforge" <gl...@gmail.com> wrote:
>On Fri, Jul 17, 2015 at 3:59 PM, Alex Harui <ah...@adobe.com> wrote:
>
>> [...]
>> And if folks are interested in other stories about release process
>> inefficiency, I will write to some Cordova folks off-list and ask them
>>to
>> add their thoughts to this thread.
>>
>
>Hmm this might be interesting, to see if there are some commonalities
>between theirs and our problems with our now sub-par release process.
>Apache, for me, should thrive for the best release quality process, but
>we've had to regress in that area to comply with the Apache expectations
>(with the various manual steps, etc), and I'm hopeful we can further
>improve such process for more automation, less human intervention, shorter
>release times, etc.
I don’t know how IP checking was done in the past for Groovy, but I don’t
know of a way to automate comparing the format of Apache L&N against the
contents of the packages, so I’ve resigned myself to some level of human
involvement. I just hope those with the best techniques for finding
issues will share them.
It was pointed out to me that this is a pretty big list, so instead of
having the Cordova folks join this thread and re-hash the past
discussions, I’ll supply a link to a public archive of one thread. There
are a couple of other threads on non-public lists. And you can probably
drop in on the Cordova dev list and have them get involved on your dev
list.
http://s.apache.org/kvO
-Alex
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Guillaume Laforge <gl...@gmail.com>.
On Fri, Jul 17, 2015 at 3:59 PM, Alex Harui <ah...@adobe.com> wrote:
> [...]
> And if folks are interested in other stories about release process
> inefficiency, I will write to some Cordova folks off-list and ask them to
> add their thoughts to this thread.
>
Hmm this might be interesting, to see if there are some commonalities
between theirs and our problems with our now sub-par release process.
Apache, for me, should thrive for the best release quality process, but
we've had to regress in that area to comply with the Apache expectations
(with the various manual steps, etc), and I'm hopeful we can further
improve such process for more automation, less human intervention, shorter
release times, etc.
--
Guillaume Laforge
Groovy Project Manager
Product Ninja & Advocate at Restlet <http://restlet.com>
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Alex Harui <ah...@adobe.com>.
On 7/17/15, 3:09 AM, "Emmanuel Lécharny" <el...@gmail.com> wrote:
>>that would not change anything. What makes things complicated is
>> points of human interaction in the middle of the release process. That
>> won't be different with a better tuned CI
>I'm puzzled. Cédric said in a previous mail that before being an Apache
>podling, releasing was just a matter of a couple of hours and very few
>human interaction. What makes it so more complex in an Apache
>environement ?
From my personal experience, before Apache you could ship anything you
want and if someone found an IP issue, you would fix it after you shipped.
At Apache, the rules are more stringent (no binaries, L&N in jars), and
you get shamed for not catching stuff when there is no clear process for
catching that stuff.
In the end, it is necessary since clean IP is important to Apache and your
customers, but it isn’t efficient while you go through the cleaning up
process, especially in the incubator if your mentors don’t apply the same
level of scrutiny that will occur when the greater IPMC does its scrutiny.
Our mentors never scrutinized our binaries and we are only now as a TLP
cleaning those up.
And if folks are interested in other stories about release process
inefficiency, I will write to some Cordova folks off-list and ask them to
add their thoughts to this thread.
-Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 17/07/15 12:02, Jochen Theodorou a écrit :
> Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
> [...]
>> 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.
>
> that would not change anything. What makes things complicated is
> points of human interaction in the middle of the release process. That
> won't be different with a better tuned CI
I'm puzzled. Cédric said in a previous mail that before being an Apache
podling, releasing was just a matter of a couple of hours and very few
human interaction. What makes it so more complex in an Apache environement ?
>
> [...]
>> I'd like to remember everyone that each project is quite able to define
>> the way they do things, as soon as they fits in the Apache process,
>> which is not that rigid.
>
> Not as rigid... on this list it has been made clear, that anything
> that is even remotely something like a release is to be handled as
> such. Furthermore, it was made clear, that third parties are supposed
> to be prevented to provide their own releases, even if it means to use
> the brand to force things. Even maven central is seen as evil in that
> sense. And of course any apache member is not allowed to do some kind
> f release on its own. This is just to give an example of the things
> that accompany the process. And those are rigid already.
Let me be clear : I'm cutting releases for years on Apache projects. The
process is quite simple :
- I use Maven *locally*. When the release is completed, I just have to
close the staging repository on Nexus, and push the packages on dist.
Nothing that can't be done automatically, except closing the repository
- last, not least, I stage the release on nexus.
Tell me what's different for Groovy, that requires much more manual
processing ?
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Jochen Theodorou <bl...@gmx.org>.
Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
[...]
> 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.
that would not change anything. What makes things complicated is points
of human interaction in the middle of the release process. That won't be
different with a better tuned CI
[...]
> I'd like to remember everyone that each project is quite able to define
> the way they do things, as soon as they fits in the Apache process,
> which is not that rigid.
Not as rigid... on this list it has been made clear, that anything that
is even remotely something like a release is to be handled as such.
Furthermore, it was made clear, that third parties are supposed to be
prevented to provide their own releases, even if it means to use the
brand to force things. Even maven central is seen as evil in that sense.
And of course any apache member is not allowed to do some kind f release
on its own. This is just to give an example of the things that accompany
the process. And those are rigid already.
bye blackdrag
--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@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 L&N 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 L&N 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 to define
the way they do things, as soon as they fits in the Apache process,
which is not that rigid. At this point, we may dedicate some time with
mentors, someone from infra and obviously the project's RM. If we don't
do that now we are painfully impairing the project...
My 2cts.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Cédric Champeau <ce...@gmail.com>.
>
> Lets be clear, what I was referring to is this: the identified L&N 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 L&N 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 L&N 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.
>
> Then, perhaps, following up with the dot release once the current one
> is out, would be a way to go. Dot releases are cheap and easy and
> having a releases that is actually squeaky clean from the IP perspective
> is what Incubation is partially about.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Hi Cédric,
let me start with saying that I do appreciate your personal efforts
and the Groovy podling efforts in general. You guys are really
on-boarding quite well and are one of the easiest podling to mentor.
What I felt disappointed about is not that you produced a release
with L&N issues, but rather that you seems to have denied yourself
an opportunity to do it right based on incorrect assumptions. See bellow:
This email is not meant to block your RC (as it wasn't the case
with my original vote) but rather to try and refute some of those incorrect
assumptions.
On Thu, Jul 16, 2015 at 9:59 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> 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 <el...@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.
Lets be clear, what I was referring to is this: the identified L&N 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.
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 L&N 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.
Then, perhaps, following up with the dot release once the current one
is out, would be a way to go. Dot releases are cheap and easy and
having a releases that is actually squeaky clean from the IP perspective
is what Incubation is partially about.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 17/07/15 09:28, Cédric Champeau a écrit :
> Thanks Justin. We had read that document, but even reading the "binary
> section", it wasn't clear that source and binary L&N had to be
> different.
Guiding Principle :
"The |LICENSE| and |NOTICE| files must *exactly* represent the contents
of the distribution they reside in."
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Alex Harui <ah...@adobe.com>.
That’s why it would be great to have Justin write up a “This is how I test
a release” page somewhere that explains how he goes about it. Mentors and
release managers should be able to generate the same data sets and try to
interpret it in the same way early in the release process. You still may
not catch everything Justin will, but hopefully you will catch enough that
any issues found can be rolled to the next release.
-Alex
On 7/17/15, 12:28 AM, "Cédric Champeau" <ce...@gmail.com> wrote:
>Thanks Justin. We had read that document, but even reading the "binary
>section", it wasn't clear that source and binary L&N 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*
>L&N files *must* be issued including these additional dependencies.
>
>2015-07-17 1:02 GMT+02:00 Justin Mclean <ju...@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-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Cédric Champeau <ce...@gmail.com>.
Thanks Justin. We had read that document, but even reading the "binary
section", it wasn't clear that source and binary L&N 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*
L&N files *must* be issued including these additional dependencies.
2015-07-17 1:02 GMT+02:00 Justin Mclean <ju...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 17/07/15 01:02, Justin Mclean a écrit :
> 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.
Thank Justin !
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Justin Mclean <ju...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 16/07/15 20:43, Alex Harui a écrit :
> IMO, what would really help would be a step-by-step guide to examining a
> release for L & N issues. Justin explained part of his technique in this
> thread already. The person creating the release artifacts should have a
> decent chance at finding these issues before opening any vote thread.
+1 ! And adding such a tool into rat or whatever would be extremely
helpful, too...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Alex Harui <ah...@adobe.com>.
IMO, what would really help would be a step-by-step guide to examining a
release for L & N issues. Justin explained part of his technique in this
thread already. The person creating the release artifacts should have a
decent chance at finding these issues before opening any vote thread.
-Alex
On 7/16/15, 11:28 AM, "Marvin Humphrey" <ma...@rectangular.com> wrote:
>On Thu, Jul 16, 2015 at 9:59 AM, Cédric Champeau
><ce...@gmail.com> wrote:
>
>> Like it or not, it passed the vote.
>
>Given the logistics of rolling another RC (even with a shortened
>window) and the urgency of the release due to security issues, I think
>this was a decent outcome.
>
>That said, contended release votes are extremely rare at Apache, and
>the release contains some licensing glitches which would ordinarily
>merit a respin in my judgment. I considered voting +1 but in the end
>decided to abstain.
>
>> (especially because as we said, the License file
>> contains more, but not less, than required),
>
>This is not quite the case.
>
>There were some bundled dependencies whose licenses were not noted in
>the top-level LICENSE file. This is a licensing documentation bug,
>rather than a licensing error -- it does not make distribution
>illegal, but it might lead to a downstream consumer failing to uphold
>the conditions of the omitted licenses. For example, they may fail to
>give proper attribution in a binary redistribution.
>
>Additionally, in the case of normalize.css (hidden inside
>stylesheet.css) and FileNameCompleter.groovy, an Apache header was
>added inappropriately to files containing BSD-licensed and
>MIT-licensed content. Assuming that the content of those files has
>never been licensed under the ALv2, this is a licensing error, and it
>is a judgment call as to whether a reasonable consumer would interpret
>that header as a mistake.
>
>> and as
>> Paul said, all jars produces *do* have them.
>
>Indeed -- I only spot checked, but that's what I saw as well.
>
>Marvin Humphrey
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Jul 16, 2015 at 9:59 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> Like it or not, it passed the vote.
Given the logistics of rolling another RC (even with a shortened
window) and the urgency of the release due to security issues, I think
this was a decent outcome.
That said, contended release votes are extremely rare at Apache, and
the release contains some licensing glitches which would ordinarily
merit a respin in my judgment. I considered voting +1 but in the end
decided to abstain.
> (especially because as we said, the License file
> contains more, but not less, than required),
This is not quite the case.
There were some bundled dependencies whose licenses were not noted in
the top-level LICENSE file. This is a licensing documentation bug,
rather than a licensing error -- it does not make distribution
illegal, but it might lead to a downstream consumer failing to uphold
the conditions of the omitted licenses. For example, they may fail to
give proper attribution in a binary redistribution.
Additionally, in the case of normalize.css (hidden inside
stylesheet.css) and FileNameCompleter.groovy, an Apache header was
added inappropriately to files containing BSD-licensed and
MIT-licensed content. Assuming that the content of those files has
never been licensed under the ALv2, this is a licensing error, and it
is a judgment call as to whether a reasonable consumer would interpret
that header as a mistake.
> and as
> Paul said, all jars produces *do* have them.
Indeed -- I only spot checked, but that's what I saw as well.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Cédric Champeau <ce...@gmail.com>.
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 <el...@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 L&N 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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 16/07/15 18:49, Roman Shaposhnik a écrit :
> On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny <el...@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.
I'm not.
They are dealing with a zero-day exploit, and it was clearly explained
on the private mailing list.
That some missing and incorrect N&L were detected after the release has
been cut is unfortunate (or fortunate, considering taht it has been
detected), but this is know known and will be addressed. IMO,
considering that a new release will occur soon, for which patches will
be applied to fix those incorrect N&L is good enough to vote this release.
I seriously *wish* that all the other Apache projects are as respectful
to the requirements regarding N&L, and I must say that, having been
through Seb scrutinity (thanks, Seb, btw), my own projects were not
perfect despite many releases that have been cut in the past.
I find it a but tough to say you are disapointed, because they *have*
considered the pros and cons of releasing now vs postponing to get the
N&L fixed.
>
>> I'll change my vote to -0 to avoid sucha dead lock :-)
>>
>> I expect the groovy podling to cut a release asap that fixes the N&L issues.
> That's my strong expectation as well. If we're doing this whole
> mentoring thing -- lets do it right.
I think they are doing it right, so far. My remark was more for the
record than anything else.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny <el...@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.
> I'll change my vote to -0 to avoid sucha dead lock :-)
>
> I expect the groovy podling to cut a release asap that fixes the N&L issues.
That's my strong expectation as well. If we're doing this whole
mentoring thing -- lets do it right.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Emmanuel Lécharny <el...@gmail.com>.
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 ?
I'll change my vote to -0 to avoid sucha dead lock :-)
I expect the groovy podling to cut a release asap that fixes the N&L issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
Posted by Justin Mclean <ju...@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.
> 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.
Thanks,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org