incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
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 <>:
>> 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
>> 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

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
>> 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.
> (*)

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,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message