Le 17/07/15 12:02, Jochen Theodorou a écrit : > Am 17.07.2015 09:31, schrieb Emmanuel Lécharny: > [...] >> Now, I'm a bit scared : why the hell can't we make it easier to cut a >> release at Apache for this project ? I mean, the infrastructure should >> not be a limitation here : we do have a CI, we most certainly can tune >> it to fit Groovy. > > that would not change anything. What makes things complicated is > points of human interaction in the middle of the release process. That > won't be different with a better tuned CI I'm puzzled. Cédric said in a previous mail that before being an Apache podling, releasing was just a matter of a couple of hours and very few human interaction. What makes it so more complex in an Apache environement ?
> > [...] >> I'd like to remember everyone that each project is quite able to define >> the way they do things, as soon as they fits in the Apache process, >> which is not that rigid. > > Not as rigid... on this list it has been made clear, that anything > that is even remotely something like a release is to be handled as > such. Furthermore, it was made clear, that third parties are supposed > to be prevented to provide their own releases, even if it means to use > the brand to force things. Even maven central is seen as evil in that > sense. And of course any apache member is not allowed to do some kind > f release on its own. This is just to give an example of the things > that accompany the process. And those are rigid already. Let me be clear : I'm cutting releases for years on Apache projects. The process is quite simple : - I use Maven *locally*. When the release is completed, I just have to close the staging repository on Nexus, and push the packages on dist. Nothing that can't be done automatically, except closing the repository - last, not least, I stage the release on nexus. Tell me what's different for Groovy, that requires much more manual processing ? --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
