> On Oct 10, 2013, at 11:55 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > Can a release guy detail what is painful and why we cant release with a > script?
That is what I have always ended up doing. The problems start when we try to get everything to work for all components automagically from maven and nexus. Some people use windows so shell scripts to simplify things can't work for everyone. Different components also have slightly different needs. Add in lots of RMs releasing infrequently and it ends up hard to standardize. I would be +1 for component-level scripts / rm readmes so new RMs could step in easily. Gilles did that for [math] a while back and it was very helpful. I have also been +1 for a while for dumping commons parent. Phil > Git or svn are scriptable to be auto so the scm is clearly not the > release issue (maybe not fashion but not blocking) > Le 11 oct. 2013 01:24, "Gary Gregory" <garydgreg...@gmail.com> a écrit : > >> On Oct 10, 2013, at 18:13, Mark Thomas <ma...@apache.org> wrote: >> >>>> On 10/10/2013 23:05, James Carman wrote: >>>>> On Thu, Oct 10, 2013 at 5:48 PM, Mark Thomas <ma...@apache.org> wrote: >>>>> >>>>> I would suggest that a lack of releases is a much greater barrier. >> Folks >>>>> who contribute patches do so because they want to see them in a >> release. >>>>> If there are no releases (and looking back for the past 6 months there >>>>> have been very few releases considering the number of components in >>>>> commons) then, frankly, a move to git is largely irrelevant. What it >>>>> will do little is distract what little effort there is going into >>>>> releases making the overall problem worse not better. >>>> >>>> It's a catch-22. You don't have releases because you don't have >>>> contributors. >>> >>> I disagree. We don't have releases because of an overly complex release >>> process. >> >> >> +1. It's a pain for sure. But there no simple solution aside from >> reducing what we deliver and where :( >> >> Gary >>> Figuring out how to do a Pool 2 release is on my TODO list. >>> Having seen the pain others new to the Commons release process have gone >>> though, I'm not looking forward to it at all. >>> >>> Mark >>> >>>> And, you don't have contributors because you don't have >>>> releases. I agree we need to get busy cranking out some code to let >>>> folks know we're not dead (yet). The only way I see us getting more >>>> code going is to get new people and I honestly believe that using a >>>> tool like Git will help us do that. >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org