Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Message-ID: <55A8E395.4090603@asert.com.au>
Date: Fri, 17 Jul 2015 21:14:29 +1000
From: Paul King <paulk@asert.com.au>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: general@incubator.apache.org
Subject: Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating
References: 
 <CADQzvmkt333A70zYWx6_jxH9Km4tUzYvQsXZ1eoJWafcvvz-PA@mail.gmail.com>
	<4C228491-AED5-45BF-9359-991A7E96D750@classsoftware.com>
	<55A76F95.2040208@gmail.com>
	<CA+ULb+vTHGB1LgSq5j5xSYnyCmtL8Z61ethO13qbxYvCCgxzuw@mail.gmail.com>
	<CADQzvmnZTHw0Qh06CO+oG-hV_ue3=m4Z-zy+vic=HyRMP-MzfQ@mail.gmail.com>
	<CA+ULb+vLVCpatF6J5ZUffBe_JvbQgW2=dBJx+-Ki9xDSvK2PrQ@mail.gmail.com>
 <CADQzvm=Ye7EM6MeHVeUF=XNVvTDSeen6c+VP1fNYVPnR7fZy6A@mail.gmail.com>
 <55A8AF35.9060601@gmail.com> <55A8D2AB.5070106@gmx.org>
 <55A8D463.4000500@gmail.com>
In-Reply-To: <55A8D463.4000500@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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