osx client

[Brandon Holtsclaw]

I'm down for whatever, but one thing to keep in mind too is that its in the
format that it is so `Brew` will see it

Brew works kinda like the charm store in that it looks for branches of a
certain name and format on github for "brew install juju" to work

-- 
Brandon Holtsclaw
Web http://brandonholtsclaw.com
Voice/SMS Tel:816-974-6106



On Mon, May 14, 2012 at 2:35 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> On Mon, May 14, 2012 at 4:29 PM, Mark Mims <mark.mims at canonical.com>
> wrote:
> > On 05/14/2012 01:08 PM, Gustavo Niemeyer wrote:
> >>
> >> On Mon, May 14, 2012 at 3:33 PM, Mark Mims<mark.mims at canonical.com>
> >>  wrote:
> >>>
> >>> imbrandon added a github project ( http://jujutools.github.com/ from
> >>> http://github.com/jujutools) for homebrew-juju, the osx juju cli
> >>> packages.
> >>>
> >>> correction this repo is just a packaging formula... it pulls the juju
> cli
> >>> itself from lp:juju but the remaining arguments still apply
> >>
> >> What's the problem we're trying to solve, more precisely?  Brandon has
> >> been doing a great job on the MacOS front, and I'm concerned about
> >> arbitrating anything around it that could disrupt the good flow that
> >> is happening. I'd prefer to hear from him what he'd like from us to
> >> support his efforts.
> >
> > excellent point... thanks for the great work Brandon!
> >
> > I'm just asking this now because I'm concerned about too many things
> living
> > in too many places for us to maintain properly.  The pull request
> > notifications and bugs for the brew packages come through a separate
> channel
> > from even the mp notifications and bugs for the similar lp build recipes.
> >
> > We start adding up juju distro, juju ppa, juju build recipes,
> > github.com/jujutools, lp:charm-tools, lp:juju-jitsu, lp:charms,
> > github.com/charms, and we have to start building custom views on top of
> all
> > this to just get the current state of the ecosystem.
> >
> > Do existing projects, such as openstack, have tools we can use to help
> with
> > this problem?
>
> I don't have visibility on most of those spin offs. My suggestion is
> that there should be only two projects: core juju, and a single
> project handling community supporting tools. There should also be some
> flow of functionality from the latter to the former as we perceive
> that certain things are better put in the core.
>
> I'm sure people will have other tools and wrappers, of course. That
> doesn't mean we should be supporting these ourselves, though,
> otherwise as you point out it becomes hard to do a good job at them
> all.
>
>
>
> gustavo @ http://niemeyer.net
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20120514/f6c8d1f6/attachment.html>