Hey, David. Thanks for all the insight. I think what you've mentioned is best. We can continue with the code as it was, fixing headers etc for our first 1.5 and 1.6 release.
I think we will eventually change packages and that is probably worth doing on new code or replacement abstractions etc. Long way of saying +1 to preparing 1.6.1 as our first ASF release. -A On Monday, May 6, 2013, David Nalley wrote: > So in an ideal world you'd flip a switch and everything would be > org.apache.jclouds, but you have existing releases, and a need to > continue to support those. It will already be disruptive enough > changing it in master and making cherry-picking between branches that > much more difficult. Keeping multiple separate repos, would be even > worse. Even in CloudStack we still haven't finished all of that work, > and you'll still find a lot of com.cloud packages. Besides I'd guess > that you plan on supporting 1.5 and especially 1.6 for some time to > come, doing that external to the ASF, especially long term, seems > counter-productive to the efforts to integrate yourself here. > > --David > > > On Mon, May 6, 2013 at 11:14 PM, Adrian Cole > <[email protected]<javascript:;>> > wrote: > > 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:;> > <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:;> > >> <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 > >> >> > >> >
