> 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. > >> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
