incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [VOTE] Release of Apache BatchEE 0.5-incubating
Date Mon, 11 Dec 2017 00:40:35 GMT
On 10 December 2017 at 19:54, Mark Struberg <> wrote:
>> 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.

I was told that they do have the means.

This is getting OT, but if that were a concern they would have made it
clear that dist/dev was only for RCs that were going to succeed.
Which would negate the point of providing dist/dev.
I don't believe Infra would have offered the service if they could not
handle deletions.

>>> But it still would be a change to what we do in many TLPs since many years.
>> Does not make it the best solution.
>>> 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
>>> 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.

repository.a.o is not used for non-Maven projects, nor does it release
non-Maven artefacts.

> dist.a.o only exists since around 2015 iirc

Yes, and dist.a.o is the replacement for ASF release staging which
used to happen using minotaur personal logins.
The release area was also on minotaur, so the process was to move
successful releases from the personal area to the release area.

The process now is much the same, except that dev and release are on
dist.a.o and use SVN for tracking.

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

dist/dev and dist/release are in the same repo.
Since the RM uses SVN to copy/move the files from dev to release there
is full traceability back from release area to dev area revision to
VOTE mail.

> 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?

No. RMs make mistakes.

> In that case the only thing which helps is a strong hash.

Not, so, see above - the dist/dev revision is sufficient.

> And if you trust the RM then both options are fine anyway.

Even trustworthy RMs make mistakes.

I think the dist/dev process is less error-prone.
Reviewers can see the files that are intended for the release area,
and the move to the release area is tracked through SVN.

> 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.

That is what this thread is all about, surely?

> txs and LieGrue,
> strub
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message