You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Adrian Cole <ad...@gmail.com> on 2013/05/06 18:46:33 UTC
github wrangling
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!
Re: github wrangling
Posted by Andrew Phillips <ap...@qrmedia.com>.
+1 for biting the bullet now and changing the group ID. Can we do some
proactive messaging to prepare people for the change that's going to
be required, e.g. publish a blog and an early heads-up to the user@
list?
ap
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
Sorry, I was referring to the mirroring of the ASF repos.
A
On May 11, 2013, at 7:38 AM, Adrian Cole <ad...@gmail.com> wrote:
> Which "this" are you referring to? :)
>
> On Friday, May 10, 2013, Andrew Bayer wrote:
>
>> So I may be missing something, but there isn't a way to do this
>> automatically, without an update script we own running on some box we
>> control, is there?
>>
>> A
>>
>>
>>
>> On May 10, 2013, at 5:09 PM, Andrew Bayer <an...@gmail.com> wrote:
>>
>>> I was a little more concerned about this before seeing that we don't
>> actually have many RAT license violations outside of incubator-jclouds-labs
>> - but we have quite a few there. We need to remember that any release
>> coming out of ASF has to pass license criteria, etc, so we'll have to deal
>> with missing licenses/dependencies we can't use/etc in all branches we want
>> to release, not just master onward.
>>>
>>> A.
>>>
>>> On Fri, May 10, 2013 at 4:39 PM, Adrian Cole <ad...@gmail.com>
>> wrote:
>>> This thread got long, so I figure it best to paraphrase where we ended
>> up.
>>>
>>> We will release 1.5.x and 1.6.x releases from our ASF repos. It is
>> likely
>>> that our first ASF release will be 1.6.1, and we've probably a couple
>> weeks
>>> before timing of this becomes critical.
>>>
>>> There's a distribution implication of this that was probably not realized
>>> by everyone. Although I'm ok with the implication, I think everyone
>> should
>>> bear below in mind.
>>>
>>> ASF releases are published to ASF repositories as opposed to sonatype.
>> In
>>> Sonatype, we publish to the group id org.jclouds. In ASF we need to
>>> publish to org.apache.jclouds.
>>>
>>> When these jars are published, users will need to change their
>> dependencies
>>> like below:
>>>
>>> compile 'org.jclouds.provider:dynect:1.6.0'
>>> compile 'org.apache.jclouds.provider:dynect:1.6.1'
>>>
>>> There are folks that use wildcard versions, or version properties, etc.
>>> that would have maintenance to do to change the groupid that 1.6.1 now
>>> correlates to. In other words, changing group ids will be at least a
>> small
>>> pain for a patch release, and likely lead to at least a question or two
>> on
>>> the user list about some classpath problem.
>>>
>>> My personal take is that the potential classpath problem for those who
>> have
>>> old and new versions is inevitable. It will happen in 1.7 or 1.6, and
>> heck
>>> even happens without a groupId change often enough. I also feel like
>>> changing this sooner is better. That said there's more to it. I
>>> personally am disinterested in the extra overhead we'd need to have 2
>>> different release processes. It would be one thing if jclouds had a
>>> company staffed to do releases, but we aren't. Choosing to optimize
>>> for multiple distributions has high impact for us, so we should be
>> careful
>>> about that.
>>>
>>> If we wanted to continue to publish to the old ids, I'd probably prefer
>>> this as a secondary task. For example, we could upload a org.jclouds dir
>>> to sonatype after renaming the directories and a recursive sed to apply
>> the
>>> old group id. In other words, it is far easier to republish a dist to
>> the
>>> old group id ad-hoc than maintaining parallel build infrastructure.
>>>
>>> In summary, doing an efficient 1.6.1 in ASF comes with a little baggage:
>>> either a dual-publish or a concession of slight pom break. Even-though
>> the
>>> code we are distributing will be compatible, we should be aware that the
>>> build side of things has impact.
>>>
>>> -A
>>>
>>>
>>>
>>>
>>> On Fri, May 10, 2013 at 2:37 PM, Adrian Cole <adrian.f.cole@gmail.com
>>> wrote:
>>>
>>>> Thanks for the offer!
>>>>
>>>>
>>>> On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <andrew.bayer@gmail.com
>>> wrote:
>>>>
>>>>> I'll make a run at it this weekend.
>>>>>
>>>>> A.
>>>>>
>>>>> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Any volunteers able to see this through?
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/JCLOUDS-13
>>>>>>
>>>>>>
>>>>>> On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmai
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
Which "this" are you referring to? :)
On Friday, May 10, 2013, Andrew Bayer wrote:
> So I may be missing something, but there isn't a way to do this
> automatically, without an update script we own running on some box we
> control, is there?
>
> A
>
>
>
> On May 10, 2013, at 5:09 PM, Andrew Bayer <an...@gmail.com> wrote:
>
> > I was a little more concerned about this before seeing that we don't
> actually have many RAT license violations outside of incubator-jclouds-labs
> - but we have quite a few there. We need to remember that any release
> coming out of ASF has to pass license criteria, etc, so we'll have to deal
> with missing licenses/dependencies we can't use/etc in all branches we want
> to release, not just master onward.
> >
> > A.
> >
> > On Fri, May 10, 2013 at 4:39 PM, Adrian Cole <ad...@gmail.com>
> wrote:
> > This thread got long, so I figure it best to paraphrase where we ended
> up.
> >
> > We will release 1.5.x and 1.6.x releases from our ASF repos. It is
> likely
> > that our first ASF release will be 1.6.1, and we've probably a couple
> weeks
> > before timing of this becomes critical.
> >
> > There's a distribution implication of this that was probably not realized
> > by everyone. Although I'm ok with the implication, I think everyone
> should
> > bear below in mind.
> >
> > ASF releases are published to ASF repositories as opposed to sonatype.
> In
> > Sonatype, we publish to the group id org.jclouds. In ASF we need to
> > publish to org.apache.jclouds.
> >
> > When these jars are published, users will need to change their
> dependencies
> > like below:
> >
> > compile 'org.jclouds.provider:dynect:1.6.0'
> > compile 'org.apache.jclouds.provider:dynect:1.6.1'
> >
> > There are folks that use wildcard versions, or version properties, etc.
> > that would have maintenance to do to change the groupid that 1.6.1 now
> > correlates to. In other words, changing group ids will be at least a
> small
> > pain for a patch release, and likely lead to at least a question or two
> on
> > the user list about some classpath problem.
> >
> > My personal take is that the potential classpath problem for those who
> have
> > old and new versions is inevitable. It will happen in 1.7 or 1.6, and
> heck
> > even happens without a groupId change often enough. I also feel like
> > changing this sooner is better. That said there's more to it. I
> > personally am disinterested in the extra overhead we'd need to have 2
> > different release processes. It would be one thing if jclouds had a
> > company staffed to do releases, but we aren't. Choosing to optimize
> > for multiple distributions has high impact for us, so we should be
> careful
> > about that.
> >
> > If we wanted to continue to publish to the old ids, I'd probably prefer
> > this as a secondary task. For example, we could upload a org.jclouds dir
> > to sonatype after renaming the directories and a recursive sed to apply
> the
> > old group id. In other words, it is far easier to republish a dist to
> the
> > old group id ad-hoc than maintaining parallel build infrastructure.
> >
> > In summary, doing an efficient 1.6.1 in ASF comes with a little baggage:
> > either a dual-publish or a concession of slight pom break. Even-though
> the
> > code we are distributing will be compatible, we should be aware that the
> > build side of things has impact.
> >
> > -A
> >
> >
> >
> >
> > On Fri, May 10, 2013 at 2:37 PM, Adrian Cole <adrian.f.cole@gmail.com
> >wrote:
> >
> > > Thanks for the offer!
> > >
> > >
> > > On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <andrew.bayer@gmail.com
> >wrote:
> > >
> > >> I'll make a run at it this weekend.
> > >>
> > >> A.
> > >>
> > >> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com>
> > >> wrote:
> > >>
> > >> > Any volunteers able to see this through?
> > >> >
> > >> > https://issues.apache.org/jira/browse/JCLOUDS-13
> > >> >
> > >> >
> > >> > On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmai
Re: github wrangling
Posted by David Nalley <da...@gnsa.us>.
>> Regarding synchronization, if possible it would be cleaner and better to
>> setup a server side git hook [2] to push the changes to the mirror in the
>> 'post-receive' stage.
>
>
> Sounds like the cleanest option, but I don't know whether we are able to set
> up hooks in the Apache Git repos.
>
Short answer: You are not.
--David
Re: github wrangling
Posted by Andrew Phillips <ap...@qrmedia.com>.
Quoting Ignasi <ig...@gmail.com>:
> Maybe if we recreate the repos with the --mirror option [1] itis then
> properly shown as a mirror.
>
> Regarding synchronization, if possible it would be cleaner and better to
> setup a server side git hook [2] to push the changes to the mirror in the
> 'post-receive' stage.
Sounds like the cleanest option, but I don't know whether we are able
to set up hooks in the Apache Git repos.
Failing that, we can certainly set up a scheduled job on CloudBees to
do that. Shouldn't even be a problem with credentials, as I'd imagine
we'd simply be doing a clean checkout from the Apache repo and then
copying that over (using the --mirror command?)?
I've just set up an experimental job to try this to one of my repos:
https://jclouds.ci.cloudbees.com/job/EXPERIMENTAL-mirror-apache-to-demobox/
It uses a deploy key (i.e. not *my* key) stored in the "private" area
of the CloudBees account which only has rights to the mirror repo.
Obviously, there is still potential of the key being leaked, but I
figure the worst case scenario is that bad stuff gets pushed to my
mirror repo. Since that's a read-only mirror in any case, and should
be overwritten regularly, this would seem acceptable to me..?
ap
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
Is that actually usable yet? And how would that work for auto pushing? Looks like it still needs an intermediary daemon to pick up the message and act on it, which doesn't really supply much additional value over a basic clone/push (with --mirror) job/cron.
A.
On May 11, 2013, at 12:42 PM, David Nalley <da...@gnsa.us> wrote:
> gitpubsub?
> On May 11, 2013 3:33 PM, "Andrew Bayer" <an...@gmail.com> wrote:
>
>> We can't get any post receive hooks in at ASF, hence the need to do this
>> ourselves. I'll try the --mirror thing, but I don't think that'll work.
>>
>> I'm wary of a CB job because we then have to put the deploy key into the
>> job, which is very not ideal. If we had a Jenkins setup with static slaves,
>> ones we could keep a key on permanently, that'd be different, but as of
>> now, we don't.
>>
>> A.
>>
>>
>>
>> On May 11, 2013, at 12:26 PM, Ignasi <ig...@gmail.com> wrote:
>>
>>> Maybe if we recreate the repos with the --mirror option [1] itis then
>>> properly shown as a mirror.
>>>
>>> Regarding synchronization, if possible it would be cleaner and better to
>>> setup a server side git hook [2] to push the changes to the mirror in the
>>> 'post-receive' stage.
>>>
>>> [1]
>> https://help.github.com/articles/importing-an-external-git-repository
>>> [2] http://git-scm.com/book/ch7-3.html
>>> El 11/05/2013 21:12, "Adrian Cole" <ad...@gmail.com> escribió:
>>>
>>>> Couldn't we just setup a scheduled job on cloudbees? Maybe I'm
>>>> oversimplifying...
>>>>
>>>> On Saturday, May 11, 2013, Andrew Bayer wrote:
>>>>
>>>>> Hrm. Looks like Deltacloud is handling their repos in their org
>>>>> differently than the github.com/apache ones - the latter say "mirrored
>>>>> from...", the former don't. So I'm guessing they're pushing to the repo
>>>>> themselves. That's a perfectly viable option - we would just need a box
>>>>> somewhere that we could run a cronjob on to do the mirroring. I just
>>>> don't
>>>>> feel comfortable setting that up on a box here at Cloudera (due to lack
>>>> of
>>>>> visibility/access for anyone but me) or on a VM I set up somewhere,
>> since
>>>>> then it's dependent on my account etc... In the absence of any better
>>>>> option in the near term, I'll go with the VM, but yeah, that doesn't
>> feel
>>>>> like the right move long term.
>>>>>
>>>>> A,
>>>>>
>>>>>
>>>>>
>>>>> On May 11, 2013, at 11:14 AM, David Nalley <david@gnsa.us
>> <javascript:;>>
>>>>> wrote:
>>>>>
>>>>>> On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <andrew.bayer@gmail.com
>>>> <javascript:;>>
>>>>> wrote:
>>>>>>> So I may be missing something, but there isn't a way to do this
>>>>> automatically, without an update script we own running on some box we
>>>>> control, is there?
>>>>>>>
>>>>>>
>>>>>> Yes - this is how infra mirrors to github.com/apache/* and I have to
>>>>>> imagine how deltacloud does as well, though I am not sure how that
>>>>>> really happens.
>>>>>>
>>>>>> --David
>>>>>
>>>>
>>
Re: github wrangling
Posted by David Nalley <da...@gnsa.us>.
gitpubsub?
On May 11, 2013 3:33 PM, "Andrew Bayer" <an...@gmail.com> wrote:
> We can't get any post receive hooks in at ASF, hence the need to do this
> ourselves. I'll try the --mirror thing, but I don't think that'll work.
>
> I'm wary of a CB job because we then have to put the deploy key into the
> job, which is very not ideal. If we had a Jenkins setup with static slaves,
> ones we could keep a key on permanently, that'd be different, but as of
> now, we don't.
>
> A.
>
>
>
> On May 11, 2013, at 12:26 PM, Ignasi <ig...@gmail.com> wrote:
>
> > Maybe if we recreate the repos with the --mirror option [1] itis then
> > properly shown as a mirror.
> >
> > Regarding synchronization, if possible it would be cleaner and better to
> > setup a server side git hook [2] to push the changes to the mirror in the
> > 'post-receive' stage.
> >
> > [1]
> https://help.github.com/articles/importing-an-external-git-repository
> > [2] http://git-scm.com/book/ch7-3.html
> > El 11/05/2013 21:12, "Adrian Cole" <ad...@gmail.com> escribió:
> >
> >> Couldn't we just setup a scheduled job on cloudbees? Maybe I'm
> >> oversimplifying...
> >>
> >> On Saturday, May 11, 2013, Andrew Bayer wrote:
> >>
> >>> Hrm. Looks like Deltacloud is handling their repos in their org
> >>> differently than the github.com/apache ones - the latter say "mirrored
> >>> from...", the former don't. So I'm guessing they're pushing to the repo
> >>> themselves. That's a perfectly viable option - we would just need a box
> >>> somewhere that we could run a cronjob on to do the mirroring. I just
> >> don't
> >>> feel comfortable setting that up on a box here at Cloudera (due to lack
> >> of
> >>> visibility/access for anyone but me) or on a VM I set up somewhere,
> since
> >>> then it's dependent on my account etc... In the absence of any better
> >>> option in the near term, I'll go with the VM, but yeah, that doesn't
> feel
> >>> like the right move long term.
> >>>
> >>> A,
> >>>
> >>>
> >>>
> >>> On May 11, 2013, at 11:14 AM, David Nalley <david@gnsa.us
> <javascript:;>>
> >>> wrote:
> >>>
> >>>> On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <andrew.bayer@gmail.com
> >> <javascript:;>>
> >>> wrote:
> >>>>> So I may be missing something, but there isn't a way to do this
> >>> automatically, without an update script we own running on some box we
> >>> control, is there?
> >>>>>
> >>>>
> >>>> Yes - this is how infra mirrors to github.com/apache/* and I have to
> >>>> imagine how deltacloud does as well, though I am not sure how that
> >>>> really happens.
> >>>>
> >>>> --David
> >>>
> >>
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
Hi, CB peeps.
Thanks for the years of help you've given to jclouds!
We currently are considering CloudBees Dev@Cloud to push snapshots to the
ASF repos instead of Sonatype as we currently operate. I suppose our
current means of just storing creds is perceived as "not safe enough".
Fair point. Someone could grab these credentials if they hacked into
cloudbees and publish a bad snapshot. We don't want that.
What do you recommend for this? Are there other ASF projects that use
dev@cloud to publish snapshots to the official repos? How do they do it?
Cheers,
-A
On Sat, May 11, 2013 at 12:47 PM, Andrew Bayer <an...@gmail.com>wrote:
> Yup. Exactly that.
>
> A.
>
>
>
> On May 11, 2013, at 12:45 PM, Andrew Phillips <ap...@qrmedia.com>
> wrote:
>
> >> I'm wary of a CB job because we then have to put the deploy key into
> the job
> >
> > Could you explain? You mean the credentials to be able to *push* to the
> jclouds GitHub account?
> >
> > ap
>
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
Yup. Exactly that.
A.
On May 11, 2013, at 12:45 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> I'm wary of a CB job because we then have to put the deploy key into the job
>
> Could you explain? You mean the credentials to be able to *push* to the jclouds GitHub account?
>
> ap
Re: github wrangling
Posted by Andrew Phillips <ap...@qrmedia.com>.
> I'm wary of a CB job because we then have to put the deploy key into the job
Could you explain? You mean the credentials to be able to *push* to
the jclouds GitHub account?
ap
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
We can't get any post receive hooks in at ASF, hence the need to do this ourselves. I'll try the --mirror thing, but I don't think that'll work.
I'm wary of a CB job because we then have to put the deploy key into the job, which is very not ideal. If we had a Jenkins setup with static slaves, ones we could keep a key on permanently, that'd be different, but as of now, we don't.
A.
On May 11, 2013, at 12:26 PM, Ignasi <ig...@gmail.com> wrote:
> Maybe if we recreate the repos with the --mirror option [1] itis then
> properly shown as a mirror.
>
> Regarding synchronization, if possible it would be cleaner and better to
> setup a server side git hook [2] to push the changes to the mirror in the
> 'post-receive' stage.
>
> [1] https://help.github.com/articles/importing-an-external-git-repository
> [2] http://git-scm.com/book/ch7-3.html
> El 11/05/2013 21:12, "Adrian Cole" <ad...@gmail.com> escribió:
>
>> Couldn't we just setup a scheduled job on cloudbees? Maybe I'm
>> oversimplifying...
>>
>> On Saturday, May 11, 2013, Andrew Bayer wrote:
>>
>>> Hrm. Looks like Deltacloud is handling their repos in their org
>>> differently than the github.com/apache ones - the latter say "mirrored
>>> from...", the former don't. So I'm guessing they're pushing to the repo
>>> themselves. That's a perfectly viable option - we would just need a box
>>> somewhere that we could run a cronjob on to do the mirroring. I just
>> don't
>>> feel comfortable setting that up on a box here at Cloudera (due to lack
>> of
>>> visibility/access for anyone but me) or on a VM I set up somewhere, since
>>> then it's dependent on my account etc... In the absence of any better
>>> option in the near term, I'll go with the VM, but yeah, that doesn't feel
>>> like the right move long term.
>>>
>>> A,
>>>
>>>
>>>
>>> On May 11, 2013, at 11:14 AM, David Nalley <david@gnsa.us<javascript:;>>
>>> wrote:
>>>
>>>> On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <andrew.bayer@gmail.com
>> <javascript:;>>
>>> wrote:
>>>>> So I may be missing something, but there isn't a way to do this
>>> automatically, without an update script we own running on some box we
>>> control, is there?
>>>>>
>>>>
>>>> Yes - this is how infra mirrors to github.com/apache/* and I have to
>>>> imagine how deltacloud does as well, though I am not sure how that
>>>> really happens.
>>>>
>>>> --David
>>>
>>
Re: github wrangling
Posted by Ignasi <ig...@gmail.com>.
Maybe if we recreate the repos with the --mirror option [1] itis then
properly shown as a mirror.
Regarding synchronization, if possible it would be cleaner and better to
setup a server side git hook [2] to push the changes to the mirror in the
'post-receive' stage.
[1] https://help.github.com/articles/importing-an-external-git-repository
[2] http://git-scm.com/book/ch7-3.html
El 11/05/2013 21:12, "Adrian Cole" <ad...@gmail.com> escribió:
> Couldn't we just setup a scheduled job on cloudbees? Maybe I'm
> oversimplifying...
>
> On Saturday, May 11, 2013, Andrew Bayer wrote:
>
> > Hrm. Looks like Deltacloud is handling their repos in their org
> > differently than the github.com/apache ones - the latter say "mirrored
> > from...", the former don't. So I'm guessing they're pushing to the repo
> > themselves. That's a perfectly viable option - we would just need a box
> > somewhere that we could run a cronjob on to do the mirroring. I just
> don't
> > feel comfortable setting that up on a box here at Cloudera (due to lack
> of
> > visibility/access for anyone but me) or on a VM I set up somewhere, since
> > then it's dependent on my account etc... In the absence of any better
> > option in the near term, I'll go with the VM, but yeah, that doesn't feel
> > like the right move long term.
> >
> > A,
> >
> >
> >
> > On May 11, 2013, at 11:14 AM, David Nalley <david@gnsa.us<javascript:;>>
> > wrote:
> >
> > > On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <andrew.bayer@gmail.com
> <javascript:;>>
> > wrote:
> > >> So I may be missing something, but there isn't a way to do this
> > automatically, without an update script we own running on some box we
> > control, is there?
> > >>
> > >
> > > Yes - this is how infra mirrors to github.com/apache/* and I have to
> > > imagine how deltacloud does as well, though I am not sure how that
> > > really happens.
> > >
> > > --David
> >
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
Couldn't we just setup a scheduled job on cloudbees? Maybe I'm
oversimplifying...
On Saturday, May 11, 2013, Andrew Bayer wrote:
> Hrm. Looks like Deltacloud is handling their repos in their org
> differently than the github.com/apache ones - the latter say "mirrored
> from...", the former don't. So I'm guessing they're pushing to the repo
> themselves. That's a perfectly viable option - we would just need a box
> somewhere that we could run a cronjob on to do the mirroring. I just don't
> feel comfortable setting that up on a box here at Cloudera (due to lack of
> visibility/access for anyone but me) or on a VM I set up somewhere, since
> then it's dependent on my account etc... In the absence of any better
> option in the near term, I'll go with the VM, but yeah, that doesn't feel
> like the right move long term.
>
> A,
>
>
>
> On May 11, 2013, at 11:14 AM, David Nalley <david@gnsa.us <javascript:;>>
> wrote:
>
> > On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <andrew.bayer@gmail.com<javascript:;>>
> wrote:
> >> So I may be missing something, but there isn't a way to do this
> automatically, without an update script we own running on some box we
> control, is there?
> >>
> >
> > Yes - this is how infra mirrors to github.com/apache/* and I have to
> > imagine how deltacloud does as well, though I am not sure how that
> > really happens.
> >
> > --David
>
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
Hrm. Looks like Deltacloud is handling their repos in their org differently than the github.com/apache ones - the latter say "mirrored from...", the former don't. So I'm guessing they're pushing to the repo themselves. That's a perfectly viable option - we would just need a box somewhere that we could run a cronjob on to do the mirroring. I just don't feel comfortable setting that up on a box here at Cloudera (due to lack of visibility/access for anyone but me) or on a VM I set up somewhere, since then it's dependent on my account etc... In the absence of any better option in the near term, I'll go with the VM, but yeah, that doesn't feel like the right move long term.
A,
On May 11, 2013, at 11:14 AM, David Nalley <da...@gnsa.us> wrote:
> On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <an...@gmail.com> wrote:
>> So I may be missing something, but there isn't a way to do this automatically, without an update script we own running on some box we control, is there?
>>
>
> Yes - this is how infra mirrors to github.com/apache/* and I have to
> imagine how deltacloud does as well, though I am not sure how that
> really happens.
>
> --David
Re: github wrangling
Posted by David Nalley <da...@gnsa.us>.
On Sat, May 11, 2013 at 2:13 AM, Andrew Bayer <an...@gmail.com> wrote:
> So I may be missing something, but there isn't a way to do this automatically, without an update script we own running on some box we control, is there?
>
Yes - this is how infra mirrors to github.com/apache/* and I have to
imagine how deltacloud does as well, though I am not sure how that
really happens.
--David
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
So I may be missing something, but there isn't a way to do this automatically, without an update script we own running on some box we control, is there?
A
On May 10, 2013, at 5:09 PM, Andrew Bayer <an...@gmail.com> wrote:
> I was a little more concerned about this before seeing that we don't actually have many RAT license violations outside of incubator-jclouds-labs - but we have quite a few there. We need to remember that any release coming out of ASF has to pass license criteria, etc, so we'll have to deal with missing licenses/dependencies we can't use/etc in all branches we want to release, not just master onward.
>
> A.
>
> On Fri, May 10, 2013 at 4:39 PM, Adrian Cole <ad...@gmail.com> wrote:
> This thread got long, so I figure it best to paraphrase where we ended up.
>
> We will release 1.5.x and 1.6.x releases from our ASF repos. It is likely
> that our first ASF release will be 1.6.1, and we've probably a couple weeks
> before timing of this becomes critical.
>
> There's a distribution implication of this that was probably not realized
> by everyone. Although I'm ok with the implication, I think everyone should
> bear below in mind.
>
> ASF releases are published to ASF repositories as opposed to sonatype. In
> Sonatype, we publish to the group id org.jclouds. In ASF we need to
> publish to org.apache.jclouds.
>
> When these jars are published, users will need to change their dependencies
> like below:
>
> compile 'org.jclouds.provider:dynect:1.6.0'
> compile 'org.apache.jclouds.provider:dynect:1.6.1'
>
> There are folks that use wildcard versions, or version properties, etc.
> that would have maintenance to do to change the groupid that 1.6.1 now
> correlates to. In other words, changing group ids will be at least a small
> pain for a patch release, and likely lead to at least a question or two on
> the user list about some classpath problem.
>
> My personal take is that the potential classpath problem for those who have
> old and new versions is inevitable. It will happen in 1.7 or 1.6, and heck
> even happens without a groupId change often enough. I also feel like
> changing this sooner is better. That said there's more to it. I
> personally am disinterested in the extra overhead we'd need to have 2
> different release processes. It would be one thing if jclouds had a
> company staffed to do releases, but we aren't. Choosing to optimize
> for multiple distributions has high impact for us, so we should be careful
> about that.
>
> If we wanted to continue to publish to the old ids, I'd probably prefer
> this as a secondary task. For example, we could upload a org.jclouds dir
> to sonatype after renaming the directories and a recursive sed to apply the
> old group id. In other words, it is far easier to republish a dist to the
> old group id ad-hoc than maintaining parallel build infrastructure.
>
> In summary, doing an efficient 1.6.1 in ASF comes with a little baggage:
> either a dual-publish or a concession of slight pom break. Even-though the
> code we are distributing will be compatible, we should be aware that the
> build side of things has impact.
>
> -A
>
>
>
>
> On Fri, May 10, 2013 at 2:37 PM, Adrian Cole <ad...@gmail.com>wrote:
>
> > Thanks for the offer!
> >
> >
> > On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <an...@gmail.com>wrote:
> >
> >> I'll make a run at it this weekend.
> >>
> >> A.
> >>
> >> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com>
> >> wrote:
> >>
> >> > Any volunteers able to see this through?
> >> >
> >> > https://issues.apache.org/jira/browse/JCLOUDS-13
> >> >
> >> >
> >> > On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmail.com
> >> > >wrote:
> >> >
> >> > > So, I've changed jclouds into an org and folks should have access to
> >> make
> >> > > changes needed to redirect repos and run the project with minimal
> >> changes
> >> > > for now.
> >> > >
> >> > > It seems clear from others there's no sense in making new orgs, so
> >> let's
> >> > > drop the idea. Thanks for the participation folks!
> >> > >
> >> > > -A
> >> > >
> >> > >
> >> > > On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <adrian.f.cole@gmail.com
> >> > >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!
> >> > >>
> >> > >
> >> > >
> >> >
> >>
> >
> >
>
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
I was a little more concerned about this before seeing that we don't
actually have many RAT license violations outside of incubator-jclouds-labs
- but we have quite a few there. We need to remember that any release
coming out of ASF has to pass license criteria, etc, so we'll have to deal
with missing licenses/dependencies we can't use/etc in all branches we want
to release, not just master onward.
A.
On Fri, May 10, 2013 at 4:39 PM, Adrian Cole <ad...@gmail.com>wrote:
> This thread got long, so I figure it best to paraphrase where we ended up.
>
> We will release 1.5.x and 1.6.x releases from our ASF repos. It is likely
> that our first ASF release will be 1.6.1, and we've probably a couple weeks
> before timing of this becomes critical.
>
> There's a distribution implication of this that was probably not realized
> by everyone. Although I'm ok with the implication, I think everyone should
> bear below in mind.
>
> ASF releases are published to ASF repositories as opposed to sonatype. In
> Sonatype, we publish to the group id org.jclouds. In ASF we need to
> publish to org.apache.jclouds.
>
> When these jars are published, users will need to change their dependencies
> like below:
>
> compile 'org.jclouds.provider:dynect:1.6.0'
> compile 'org.apache.jclouds.provider:dynect:1.6.1'
>
> There are folks that use wildcard versions, or version properties, etc.
> that would have maintenance to do to change the groupid that 1.6.1 now
> correlates to. In other words, changing group ids will be at least a small
> pain for a patch release, and likely lead to at least a question or two on
> the user list about some classpath problem.
>
> My personal take is that the potential classpath problem for those who have
> old and new versions is inevitable. It will happen in 1.7 or 1.6, and heck
> even happens without a groupId change often enough. I also feel like
> changing this sooner is better. That said there's more to it. I
> personally am disinterested in the extra overhead we'd need to have 2
> different release processes. It would be one thing if jclouds had a
> company staffed to do releases, but we aren't. Choosing to optimize
> for multiple distributions has high impact for us, so we should be careful
> about that.
>
> If we wanted to continue to publish to the old ids, I'd probably prefer
> this as a secondary task. For example, we could upload a org.jclouds dir
> to sonatype after renaming the directories and a recursive sed to apply the
> old group id. In other words, it is far easier to republish a dist to the
> old group id ad-hoc than maintaining parallel build infrastructure.
>
> In summary, doing an efficient 1.6.1 in ASF comes with a little baggage:
> either a dual-publish or a concession of slight pom break. Even-though the
> code we are distributing will be compatible, we should be aware that the
> build side of things has impact.
>
> -A
>
>
>
>
> On Fri, May 10, 2013 at 2:37 PM, Adrian Cole <adrian.f.cole@gmail.com
> >wrote:
>
> > Thanks for the offer!
> >
> >
> > On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <andrew.bayer@gmail.com
> >wrote:
> >
> >> I'll make a run at it this weekend.
> >>
> >> A.
> >>
> >> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com>
> >> wrote:
> >>
> >> > Any volunteers able to see this through?
> >> >
> >> > https://issues.apache.org/jira/browse/JCLOUDS-13
> >> >
> >> >
> >> > On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmail.com
> >> > >wrote:
> >> >
> >> > > So, I've changed jclouds into an org and folks should have access to
> >> make
> >> > > changes needed to redirect repos and run the project with minimal
> >> changes
> >> > > for now.
> >> > >
> >> > > It seems clear from others there's no sense in making new orgs, so
> >> let's
> >> > > drop the idea. Thanks for the participation folks!
> >> > >
> >> > > -A
> >> > >
> >> > >
> >> > > On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <
> adrian.f.cole@gmail.com
> >> > >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!
> >> > >>
> >> > >
> >> > >
> >> >
> >>
> >
> >
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
This thread got long, so I figure it best to paraphrase where we ended up.
We will release 1.5.x and 1.6.x releases from our ASF repos. It is likely
that our first ASF release will be 1.6.1, and we've probably a couple weeks
before timing of this becomes critical.
There's a distribution implication of this that was probably not realized
by everyone. Although I'm ok with the implication, I think everyone should
bear below in mind.
ASF releases are published to ASF repositories as opposed to sonatype. In
Sonatype, we publish to the group id org.jclouds. In ASF we need to
publish to org.apache.jclouds.
When these jars are published, users will need to change their dependencies
like below:
compile 'org.jclouds.provider:dynect:1.6.0'
compile 'org.apache.jclouds.provider:dynect:1.6.1'
There are folks that use wildcard versions, or version properties, etc.
that would have maintenance to do to change the groupid that 1.6.1 now
correlates to. In other words, changing group ids will be at least a small
pain for a patch release, and likely lead to at least a question or two on
the user list about some classpath problem.
My personal take is that the potential classpath problem for those who have
old and new versions is inevitable. It will happen in 1.7 or 1.6, and heck
even happens without a groupId change often enough. I also feel like
changing this sooner is better. That said there's more to it. I
personally am disinterested in the extra overhead we'd need to have 2
different release processes. It would be one thing if jclouds had a
company staffed to do releases, but we aren't. Choosing to optimize
for multiple distributions has high impact for us, so we should be careful
about that.
If we wanted to continue to publish to the old ids, I'd probably prefer
this as a secondary task. For example, we could upload a org.jclouds dir
to sonatype after renaming the directories and a recursive sed to apply the
old group id. In other words, it is far easier to republish a dist to the
old group id ad-hoc than maintaining parallel build infrastructure.
In summary, doing an efficient 1.6.1 in ASF comes with a little baggage:
either a dual-publish or a concession of slight pom break. Even-though the
code we are distributing will be compatible, we should be aware that the
build side of things has impact.
-A
On Fri, May 10, 2013 at 2:37 PM, Adrian Cole <ad...@gmail.com>wrote:
> Thanks for the offer!
>
>
> On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <an...@gmail.com>wrote:
>
>> I'll make a run at it this weekend.
>>
>> A.
>>
>> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com>
>> wrote:
>>
>> > Any volunteers able to see this through?
>> >
>> > https://issues.apache.org/jira/browse/JCLOUDS-13
>> >
>> >
>> > On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmail.com
>> > >wrote:
>> >
>> > > So, I've changed jclouds into an org and folks should have access to
>> make
>> > > changes needed to redirect repos and run the project with minimal
>> changes
>> > > for now.
>> > >
>> > > It seems clear from others there's no sense in making new orgs, so
>> let's
>> > > drop the idea. Thanks for the participation folks!
>> > >
>> > > -A
>> > >
>> > >
>> > > On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <adrian.f.cole@gmail.com
>> > >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!
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
Thanks for the offer!
On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <an...@gmail.com>wrote:
> I'll make a run at it this weekend.
>
> A.
>
> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com>
> wrote:
>
> > Any volunteers able to see this through?
> >
> > https://issues.apache.org/jira/browse/JCLOUDS-13
> >
> >
> > On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmail.com
> > >wrote:
> >
> > > So, I've changed jclouds into an org and folks should have access to
> make
> > > changes needed to redirect repos and run the project with minimal
> changes
> > > for now.
> > >
> > > It seems clear from others there's no sense in making new orgs, so
> let's
> > > drop the idea. Thanks for the participation folks!
> > >
> > > -A
> > >
> > >
> > > On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <adrian.f.cole@gmail.com
> > >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!
> > >>
> > >
> > >
> >
>
Re: github wrangling
Posted by Andrew Bayer <an...@gmail.com>.
I'll make a run at it this weekend.
A.
On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <ad...@gmail.com> wrote:
> Any volunteers able to see this through?
>
> https://issues.apache.org/jira/browse/JCLOUDS-13
>
>
> On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmail.com
> >wrote:
>
> > So, I've changed jclouds into an org and folks should have access to make
> > changes needed to redirect repos and run the project with minimal changes
> > for now.
> >
> > It seems clear from others there's no sense in making new orgs, so let's
> > drop the idea. Thanks for the participation folks!
> >
> > -A
> >
> >
> > On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <adrian.f.cole@gmail.com
> >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!
> >>
> >
> >
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
Any volunteers able to see this through?
https://issues.apache.org/jira/browse/JCLOUDS-13
On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <ad...@gmail.com>wrote:
> So, I've changed jclouds into an org and folks should have access to make
> changes needed to redirect repos and run the project with minimal changes
> for now.
>
> It seems clear from others there's no sense in making new orgs, so let's
> drop the idea. Thanks for the participation folks!
>
> -A
>
>
> On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <ad...@gmail.com>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!
>>
>
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
So, I've changed jclouds into an org and folks should have access to make
changes needed to redirect repos and run the project with minimal changes
for now.
It seems clear from others there's no sense in making new orgs, so let's
drop the idea. Thanks for the participation folks!
-A
On Mon, May 6, 2013 at 9:46 AM, Adrian Cole <ad...@gmail.com> 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!
>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
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 <adrian.f.cole@gmail.com<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 <adrian.f.cole@gmail.com<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 <
> adrian.f.cole@gmail.com <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
> >> >>
> >>
>
RE: github wrangling
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
>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:david@gnsa.us]
Sent: Monday, May 06, 2013 10:24 PM
To: dev@jclouds.incubator.apache.org
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 <ad...@gmail.com> 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
>> <adrian.f.cole@gmail.com<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
>> >> <adrian.f.cole@gmail.com<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
>> >>
>>
Re: github wrangling
Posted by David Nalley <da...@gnsa.us>.
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 <ad...@gmail.com> 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 <adrian.f.cole@gmail.com<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 <adrian.f.cole@gmail.com<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
>> >>
>>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
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 <adrian.f.cole@gmail.com<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 <adrian.f.cole@gmail.com<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
> >>
>
Re: github wrangling
Posted by David Nalley <da...@gnsa.us>.
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 <ad...@gmail.com> 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 <adrian.f.cole@gmail.com<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
>>
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
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 <adrian.f.cole@gmail.com<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
>
Re: github wrangling
Posted by David Nalley <da...@gnsa.us>.
On Mon, May 6, 2013 at 12:46 PM, Adrian Cole <ad...@gmail.com> 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
Re: github wrangling
Posted by Ignasi <ig...@gmail.com>.
Switching the forks should be as easy as updating the remotes:
git remote set-url <remote name> <new url>
Something like:
git remote set-url upstream
https://git-wip-us.apache.org/repos/asf/incubator-jclouds.git
Would do the change in most cases.
On 6 May 2013 21:04, Andrew Phillips <ap...@qrmedia.com> wrote:
>> +1 to use deltacloud's process (and probably rip-off the README :))
>>
>> Process aside, do you think the namespace plan seems ok? (ex. jclouds/* ->
>> jclouds-legacy/*; incubator-jclouds-* fork into jclouds/* )
>
>
> +1. Would perhaps go for "jclouds-archived" rather than "legacy", but that's
> more of a nitty naming thing - not important.
>
> Is there any easy way to help people switch their forks over? Can we point
> to a doc or StackOverflow entry for that?
>
> ap
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
I don't mind. jclouds-archived jclouds-deprecated... let's try and choose
one in the next day. Any folks are happier with?
-A
On Mon, May 6, 2013 at 12:04 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> +1 to use deltacloud's process (and probably rip-off the README :))
>>
>> Process aside, do you think the namespace plan seems ok? (ex. jclouds/* ->
>> jclouds-legacy/*; incubator-jclouds-* fork into jclouds/* )
>>
>
> +1. Would perhaps go for "jclouds-archived" rather than "legacy", but
> that's more of a nitty naming thing - not important.
>
> Is there any easy way to help people switch their forks over? Can we point
> to a doc or StackOverflow entry for that?
>
> ap
>
Re: github wrangling
Posted by Andrew Phillips <ap...@qrmedia.com>.
> +1 to use deltacloud's process (and probably rip-off the README :))
>
> Process aside, do you think the namespace plan seems ok? (ex. jclouds/* ->
> jclouds-legacy/*; incubator-jclouds-* fork into jclouds/* )
+1. Would perhaps go for "jclouds-archived" rather than "legacy", but
that's more of a nitty naming thing - not important.
Is there any easy way to help people switch their forks over? Can we
point to a doc or StackOverflow entry for that?
ap
Re: github wrangling
Posted by Adrian Cole <ad...@gmail.com>.
+1 to use deltacloud's process (and probably rip-off the README :))
Process aside, do you think the namespace plan seems ok? (ex. jclouds/* ->
jclouds-legacy/*; incubator-jclouds-* fork into jclouds/* )
On Mon, May 6, 2013 at 10:35 AM, Andrew Phillips <an...@apache.org> wrote:
> Folks have expressed interest in continuing use of github for the purpose
>> of review.
>>
>
> Are we planning to use the GitHub workflow from Deltacloud [1]. Any
> changes to that we'd like to suggest and should run past our mentors?
>
> ap
>
> [1] https://github.com/deltacloud/**deltacloud-core/wiki/GIT-**Workflow<https://github.com/deltacloud/deltacloud-core/wiki/GIT-Workflow>
>
Re: github wrangling
Posted by Andrew Phillips <an...@apache.org>.
> Folks have expressed interest in continuing use of github for the purpose
> of review.
Are we planning to use the GitHub workflow from Deltacloud [1]. Any
changes to that we'd like to suggest and should run past our mentors?
ap
[1] https://github.com/deltacloud/deltacloud-core/wiki/GIT-Workflow