>From a user viewpoint, I would be unpleasantly surprised to have to change all >my jclouds imports, regardless of how advanced my search & replace is.
-Zack -----Original Message----- From: David Nalley [mailto:[email protected]] Sent: Monday, May 06, 2013 10:24 PM To: [email protected] Subject: Re: github wrangling 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]> 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:;>> >> 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 >> >> >>
