I think the summary of the rationale would have been around the need to repackage the code under org.apache vs org.jclouds. If that isn't the case, then yeah we could cut 1.6.1 from inside the incubator which would be far less complicated and obviate the other repositories.
-A On Monday, May 6, 2013, David Nalley wrote: > So there may be plenty of background I don't know, feel free to > educate me. But why not make a 1.5.x or 1.6.x release as your first > ASF releases? It strikes me as being the easier than another feature > release, and from a quick initial perusal it doesn't seem like your > code base is riddled with licensing or dependency problems. > LICENSE, NOTICE, DISCLAIMER, and license headers, and you probably > aren't terribly far off from a release. (I _personally_ wouldn't worry > with package name changes in the 'legacy' branches, just on master). > You've also got a number of committer/PMC members on other projects on > your initial committer list, so it's not like you it's a completely > unfamiliar process. Plus you really need to have a release or two > under your belt to graduate, to show you can deal with the process - > no need to make it more complicated or drawn out than it needs to be > IMO. > > That said, I am not doing the work, just comments from the peanut gallery. > > --David > > On Mon, May 6, 2013 at 10:12 PM, Adrian Cole > <[email protected]<javascript:;>> > wrote: > > Mainly to release 1.6 and 1.5 (pre-asf) releases, unless it is > appropriate > > to do so from ASF repos... > > > > On Monday, May 6, 2013, David Nalley wrote: > > > >> On Mon, May 6, 2013 at 12:46 PM, Adrian Cole > >> <[email protected]<javascript:;> > <javascript:;>> > >> wrote: > >> > Hi, team. > >> > > >> > Folks have expressed interest in continuing use of github for the > purpose > >> > of review. I've discussed a plan for how we can transition and > figured > >> it > >> > best to repost it here. The idea is to have a place for legacy code > >> > updates to occur from until the end of the year, and make space for > the > >> > next line of collaboration. > >> > > >> > Current status: > >> > > >> > jclouds on github is an account controlled only by me. This includes > the > >> > repositories being imported into the ASF prefixed with incubator- > >> > > >> > Ideal status (subject to debate): > >> > > >> > jclouds on github is an org with representative members correlating to > >> the > >> > PPMC. It contains forked repositories from the authoritative sources > in > >> > apache. > >> > jclouds-legacy on github is an org with representative members > >> correlating > >> > to the PPMC. Its repositories are the old ones, which were > transferred > >> to > >> > it. These repositories and the account are marked as deprecated. > >> > > >> > I've already provisioned the org jclouds-legacy, and migrating repos > to > >> it > >> > is pretty trivial. Converting the existing jclouds account to an org > is > >> > very easy. In other words, this process from a technical POV is > stupidly > >> > simple. > >> > > >> > This all in mind, let's chat about any blocking concerns. If there > >> aren't > >> > any, we should start the process so that we can start using github as > a > >> > collaboration point for code updates into the ASF. > >> > > >> > you're on! > >> > >> So what's the point of jclouds-legacy? > >> The history is complete in the ASF repos, and would be complete in > >> github mirrors of the ASF repos, so I am not sure I understanding the > >> reasoning by creating another gh org. > >> > >> --David > >> >
