batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de.INVALID>
Subject Re: [VOTE] Release of Apache BatchEE 0.5-incubating
Date Sun, 10 Dec 2017 19:54:57 GMT


> Am 10.12.2017 um 13:30 schrieb sebb <sebbaz@gmail.com>:
> 
>> 
>> And one more drawback is that ditching a failed release from SVN will _not_ free
the occupied storage.
>> That might or might not be an issue.
> 
> Infra have ways of dealing with that if necessary.

Hmm, no. Not that I'm aware off. If you commit a big zip to SVN, then the disc is consumed
and will never get freed again.

> 
>> But it still would be a change to what we do in many TLPs since many years.
> 
> Does not make it the best solution.

But viable enough to _not_ kill a perfectly valid podling release!

> 
>> In my personal opinion the dist/dev is a fine solution if the project does not leverage
a fully automated release build.
>> But for projects which use the maven-release-plugin doing a release is as easy as
mvn release:prepare + mvn release:perform.
>> All the rest is done automatically, including the deployment to a staging area at
repository.apache.org.
>> 
>> Forcing dist/dev for those projects would imo be more or less a step back to deploying
release candidates to people.a.o as we did a decade ago.
>> There was a good reason why we did get rid of that, you probably remember...
> 
> The replacement for people/minotaur is precisely dist.apache.org.

No, staging to people.a.o was faded out in ~2009 or 2010. And got replaced with repository.a.o.

dist.a.o only exists since around 2015 iirc


> 
>> Don't get me wrong: it's always good to review and discuss our release process.
>> What Reinhard did with the BatchEE release is really identical to what we do in many
TLPs.
>> What we really need to fix is the part with the sha1 (even better would be sha256
though) as this is the only 100% way to ensure the VOTE is really on the right source zip.
> 
> Indeed, but for projects with multiple release artifacts the dist/dev
> URL plus revision number is shorter.
> The dist/dev URL also makes it more obvious exactly what is planned to
> be released to the ASF mirror system.
> Wheres the parent dir for the source archive (*) includes files that
> won't be published.
> 
> (*) https://repository.apache.org/content/repositories/orgapachebatchee-1005/org/apache/batchee/batchee/0.5-incubating/

If you don't have the exact hash then there is no guarantee (besides the word of the RM) that
the packages in dist proper is the same as in dist/dev.

What is the scenario you want to guard us from? Release Managers who intentionally change
source zips when moving from dist/dev or repository.a.o to dist proper?
In that case the only thing which helps is a strong hash. And if you trust the RM then both
options are fine anyway.

Sebb, can we finally please continue with the actual VOTE for BatchEE-0.5-incubating?
It would be great if you could also take a look at the actual content. 
I know you are really good at spotting problems, so a review would be really welcome. 

txs and LieGrue,
strub



Mime
View raw message