Of Forks
Ingy dot Net
Next order of business: we want to fork the GitHub repos cloudfoundry/vcap and cloudfoundry/vmc under the CloudFreeStyle organization.
Should we fork on GitHub or should we clone and push?
Also what should the repo names be?
vcap == VMware Cloud Application Platform
vmc == VMware Client
These names make little sense under CFS. What about:
vcap => cfs-vm
vmc => cfs-client
Those are just quick thoughts. Please improve.
M. Edward (Ed) Borasky
> Greetings,
>
> Next order of business: we want to fork the GitHub repos cloudfoundry/vcap
> and cloudfoundry/vmc under the CloudFreeStyle organization.
>
> Should we fork on GitHub or should we clone and push?
I wish I knew enough about Git / Github to know the tradeoffs. I just
need something I can fork, hack on and send pull requests to. And for
someone to tell me whether I need a separate Github repo if I want to
build code to add R to an instance.
>
> Also what should the repo names be?
>
> vcap == VMware Cloud Application Platform
> vmc == VMware Client
>
> These names make little sense under CFS. What about:
>
> vcap => cfs-vm
> vmc => cfs-client
>
> Those are just quick thoughts. Please improve.
Or tack a letter on front "cvcap" = cloudfreestyle virtual AP; cvmc =
cloudfreestyle virtual MC
>
--
Twitter: http://twitter.com/znmeb Computational Journalism Server
http://j.mp/compjournoserver
Data is the new coal - abundant, dirty and difficult to mine.
Jonathan "Duke" Leto
> Should we fork on GitHub or should we clone and push?
I am of the opinion that we can fork for now, and when the time comes
when there is real divergence, the names of repos will need to be
changed and we can do a clean push then. This is the friendly thing to
do and would please Github, since the repos we are talking about are
huge.
Currently there is a huge amount of detritus in the history of
vcap.git which was never cleaned out, which is why cloning it takes so
long. When we do our "clean push", we can filter history to get rid of
all that junk.
> Also what should the repo names be?
>
> vcap == VMware Cloud Application Platform
> vmc == VMware Client
>
> These names make little sense under CFS. What about:
>
> vcap => cfs-vm
> vmc => cfs-client
>
> Those are just quick thoughts. Please improve.
>
My vote is for:
vcap -> cloudfreestyle
vmc -> cfs
The first is because "vcap" really means nothing, it should actually
be called "cloudfoundry".
As for vmc -> cfs, that is a command many people will be typing many
times, so I prefer cfs (or even just cf) over cfs-client.
Naming is hard, let's go coding!
Duke
--
Jonathan "Duke" Leto <jona...@leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
M. Edward (Ed) Borasky
<jona...@leto.net> wrote:
> Howdy,
>
>> Should we fork on GitHub or should we clone and push?
>
> I am of the opinion that we can fork for now, and when the time comes
> when there is real divergence, the names of repos will need to be
> changed and we can do a clean push then. This is the friendly thing to
> do and would please Github, since the repos we are talking about are
> huge.
Yep ... it wouldn't say "fork me" if we shouldn't fork it. ;-) But
seriously, if there's this whole other infrastructure as shown in your
book and the source is actually managed by a human committee of VMware
employees, how do we know how what we fork relates to what's in a
deployed CloudFoundry instance?
Jonathan "Duke" Leto
Ed, you are confusing issues. If you deploy Cloud Foundry, you get CF
code deployed.
If you deploy CloudFreeStyle, you get that code. Think of them as *BSD
cousins. They might use some of the same things, but they are not the
same.
Maybe vmware should change the slogan to "NetBSD of the Cloud".
Duke
--
M. Edward (Ed) Borasky
<jona...@leto.net> wrote:
> Howdy,
>
> Ed, you are confusing issues. If you deploy Cloud Foundry, you get CF
> code deployed.
>
> If you deploy CloudFreeStyle, you get that code. Think of them as *BSD
> cousins. They might use some of the same things, but they are not the
> same.
>
> Maybe vmware should change the slogan to "NetBSD of the Cloud".
>
> Duke
Ah ... OK. It's Sunday ... I think I'll go for a walk in the woods or something.
Daniil Kulchenko
> I am of the opinion that we can fork for now, and when the time comes
> when there is real divergence, the names of repos will need to be
> changed and we can do a clean push then. This is the friendly thing to
> do and would please Github, since the repos we are talking about are
> huge.
+1, let's do a GH-fork and recreate the repo at the point where it no longer makes sense to call it a fork.
> My vote is for:
>
> vcap -> cloudfreestyle
> vmc -> cfs
+1 as well.
Daniil.
M. Edward (Ed) Borasky
> On Apr 14, 2012, at 10:10 PM, Jonathan Duke Leto wrote:
>
>> I am of the opinion that we can fork for now, and when the time comes
>> when there is real divergence, the names of repos will need to be
>> changed and we can do a clean push then. This is the friendly thing to
>> do and would please Github, since the repos we are talking about are
>> huge.
>
> +1, let's do a GH-fork and recreate the repo at the point where it no longer makes sense to call it a fork.
+1
>
>> My vote is for:
>>
>> vcap -> cloudfreestyle
>> vmc -> cfs
>
> +1 as well.
+1/2 I've spent the afternoon playing with Red Hat's OpenShift and the
"cfs" name is fine - three letters. But you're replacing a four-letter
name "vcap" with a 14-letter one. Nobody is going to type that! Why
not just "ccap" and "cmc"?
Ingy dot Net
done and done.
Daniil.
Ingy dot Net
On Sun, Apr 15, 2012 at 5:18 PM, Daniil Kulchenko <dan...@kulchenko.com> wrote:+1
> On Apr 14, 2012, at 10:10 PM, Jonathan Duke Leto wrote:
>
>> I am of the opinion that we can fork for now, and when the time comes
>> when there is real divergence, the names of repos will need to be
>> changed and we can do a clean push then. This is the friendly thing to
>> do and would please Github, since the repos we are talking about are
>> huge.
>
> +1, let's do a GH-fork and recreate the repo at the point where it no longer makes sense to call it a fork.
+1/2 I've spent the afternoon playing with Red Hat's OpenShift and the
>
>> My vote is for:
>>
>> vcap -> cloudfreestyle
>> vmc -> cfs
>
> +1 as well.
"cfs" name is fine - three letters. But you're replacing a four-letter
name "vcap" with a 14-letter one. Nobody is going to type that! Why
not just "ccap" and "cmc"?
Nobody needs to type 'cloudfreestyle'. it's not a command. It's just a name. And it's a nice name. vcap is a terrible name. :)
cfs is a command and a repo.
M. Edward (Ed) Borasky
Ah - OK. I'm looking at the github repo now. Suppose, just for the
sake of argument, I wanted to go through the cloudfreestyle
"README.md" and duplicate the "Getting Started" page, then edit all
the code so it points to "cloudfreestyle" instead of VMware's repo.
Would I fork the cloudfreestyle repo, do my testing / editing on that,
then send you a pull request?
I guess the first step would be for me to install "cfs" on my machine.
Having another name different from "vmc" and "rhc" is a distinct
advantage. ;-)
M. Edward (Ed) Borasky
https://github.com/znmeb/Computational-Journalism-Server to work with
either OpenShift (RHEL 6.2) or CloudFreeStyle (Ubuntu 10.04) as well
as openSUSE 12.1 (and 12.2 - I'm switching one of my machines to 12.2
milestone). For what I'm doing, the kernel isn't going to be a
bottleneck but the ancient R and PostgreSQL packages carried on those
platforms is. I don't know yet about GCC and whatever javac they
carry. OpenShift doesn't have Redis yet as far as I can tell, and
that's a show-stopper for some of the real-time Twitter things I want
to do.
Adron Hall
All +1s.
Will be jumping into the fray soon. =)
M. Edward (Ed) Borasky
> All +1s.
>
> Will be jumping into the fray soon. =)
It's going to be an interesting Monday for some of you, I rhink. ;-)
Any of you have any pointers to how "automatic scaling" / load
balancing works for Node.js on Cloud Foundry?
Jonathan "Duke" Leto
> It's going to be an interesting Monday for some of you, I rhink. ;-)
> Any of you have any pointers to how "automatic scaling" / load
> balancing works for Node.js on Cloud Foundry?
I am pretty sure that autoscaling has not been released. Here is a
sneak-peak of a demo:
https://twitter.com/#!/marklucovsky/media/slideshow?url=pic.twitter.com%2FNvrZCTuK
M. Edward (Ed) Borasky
<jona...@leto.net> wrote:
> Howdy,
>
>> It's going to be an interesting Monday for some of you, I rhink. ;-)
>> Any of you have any pointers to how "automatic scaling" / load
>> balancing works for Node.js on Cloud Foundry?
>
> I am pretty sure that autoscaling has not been released. Here is a
> sneak-peak of a demo:
>
> https://twitter.com/#!/marklucovsky/media/slideshow?url=pic.twitter.com%2FNvrZCTuK
>
> Duke
Hmmm ... OpenShift "claims" to have some kind of autoscaling. They
also have no stated business model / value proposition / price list /
Redis service and they aren't open source until later this month. ;-)
So I don't feel the slightest bit guilty about stripping out a bunch
of non-working stuff from my "will-be-a-PaaS-when-it-grows-up"
appliance.