On 10 December 2017 at 19:54, Mark Struberg <strub...@yahoo.de.invalid> wrote: > > >> Am 10.12.2017 um 13:30 schrieb sebb <seb...@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.
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 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. 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. >> >> (*) >> 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. 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: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
