On Fri, Jan 14, 2011 at 09:32, Eric Baldeschwieler <[email protected]> wrote: > I'm a huge supporter of the idea. On a related note, we've been looking for > the right time to mavenize. Maybe we can do both together. We could pitch in > a bunch of work on both if we could get the timing right.
Adding maveninzation - a great effort by itself with a lot of potential pitfalls - into the splitting frenzy has a good chances to be pretty disruptive for individual developers. I well remember how people were screaming because virtually nothing worked in past-split time and they had to invent and learn new tricks to merely do their work. Being a great tool Maven has a relatively steep learning curve which won't ease the fact the projects layout have changed again and everyone will have to adjust their workbenches to address that fact. I suggest these two events are better be well separated in time. Cos > We've got a huge batch of commits in flight now, but if we can find something > that satisfied the 22 crowd after we sync in, we'd be happy to pitch in on > unsplit and/or maven. > > --- > E14 - via iPhone > > On Jan 14, 2011, at 5:43 AM, "Ian Holsman" <[email protected]> wrote: > >> on that note... I propose we discuss un-splitting the project altogether. >> >> On Jan 14, 2011, at 3:39 AM, Jakob Homan wrote: >> >>> +1. The project split is a lie. >>> >>> On Fri, Jan 14, 2011 at 12:32 AM, Ian Holsman <[email protected]> wrote: >>>> +1 full agreement. >>>> >>>> I think it will be a pita admin wise (due to how svn authorization is set >>>> up), so it might slow down creation of a new branch, but its worth it. >>>> >>>> --- >>>> Ian Holsman >>>> AOL Inc >>>> [email protected] >>>> (703) 879-3128 / AIM:ianholsman >>>> >>>> it's just a technicality >>>> >>>> On Jan 14, 2011, at 2:25 AM, Eric Baldeschwieler <[email protected]> >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Death to the project split! Or short of that, anything to tame it. >>>>> >>>>> On Jan 13, 2011, at 10:18 PM, Nigel Daley wrote: >>>>> >>>>>> Folks, >>>>>> >>>>>> As I look more at the impact of the common/MR/HDFS project split on what >>>>>> and how we release Hadoop, I feel like the split needs an adjustment. >>>>>> Many folks I've talked to agree that the project split has caused us a >>>>>> splitting headache. I think 1 relatively small change could alleviate >>>>>> some of that. >>>>>> >>>>>> CURRENT SVN REPO: >>>>>> >>>>>> hadoop / [common, mapreduce, hdfs] / trunk >>>>>> hadoop / [common, mapreduce, hdfs] / branches >>>>>> >>>>>> PROPOSAL: >>>>>> >>>>>> hadoop / trunk / [common, mapreduce, hdfs] >>>>>> hadoop / branches / [common, mapreduce, hdfs] >>>>>> >>>>>> We're a long way from releasing these 3 projects independently. Given >>>>>> that, they should be branched and released as a unit. This SVN >>>>>> structure enforces that and provides a more natural place to keep a top >>>>>> level build and pkg scripts that operate across all 3 projects. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Cheers, >>>>>> Nige >>>>> >>>> >> >
