[00:08] <SpamapS> zirpu: awesome
[03:32] <_mup_> Bug #1017792 was filed: running relation-get with no client id gives misleading error <juju:New> < https://launchpad.net/bugs/1017792 >
[03:48] <lifeless> is this expected? :  charm proof .
[03:48] <lifeless> E: could not find metadata file for .
[03:48] <lifeless> E: revision file in root of charm is required
[03:48] <lifeless> but
[03:48] <lifeless> charm proof $(pwd)
[03:48] <lifeless> works fine
[04:20] <_mup_> Bug #1017801 was filed: juju tries to delete in-use security groups <juju:New> < https://launchpad.net/bugs/1017801 >
[04:21] <snihalani> Hi guys
[04:21] <snihalani> I have a question
[04:21] <snihalani> Where do I get layman definition of what juju does for me?
[04:22] <lifeless> it deploys software for you, into cloud environments like amazon ec2, rackspace, and so on.
[04:22] <snihalani> so, applications from my dev environment into EC2, cloudfoundry etc?
[04:22] <lifeless> juju manages all the connections between different services, like getting your webserver behind haproxy, or setting up new hbase cluster nodes.
[04:22] <lifeless> yes, that sort of thing
[04:23] <lifeless> there is in fact a charm to deploy cloudfoundry itself.
[04:23] <snihalani> define charm? Sorry, I am a noob
[04:25] <lifeless> a charm is the rules for deploying a specific piece of software
[04:25] <MarkDude> imbrandon, pingy
[04:25] <lifeless> foine.
[04:56] <imbrandon> MarkDude: heya man
[04:56]  * MarkDude needs those links again
[04:56] <imbrandon> about to crash :) cool one sec
[04:56] <MarkDude> making the Fedora juju page now
[04:57] <MarkDude> Have some folks willing to test
[04:57] <imbrandon> btw i plan on making some new ones in the next day or so ( juju is about to do a minor release )
[04:57] <imbrandon> and i'll refresh them at the same time
[04:57] <imbrandon> kk links, brb
[04:57] <MarkDude> we have a few Fedora Ambaassadors that are also Ubuntu Memebers
[04:57] <imbrandon> nice
[04:57] <imbrandon> let em know they are more than willing to hang out
[04:58] <imbrandon> and if we get tooo  off topic we'll make a #juju-fedora chan
[04:58] <imbrandon> :)
[04:58] <imbrandon> or #juju-ports , actually not a bad idea
[04:58] <imbrandon> hrm
[04:58] <imbrandon> ok
[04:58] <imbrandon> http://jujutools.github.com/rpm-juju
[04:59] <imbrandon> btw i made a page about them for the offical docs
[04:59] <imbrandon> but the docs have a build issue atm, soon as thats worked out ( today hopes ) then there will be links to it in the official docs too
[04:59] <imbrandon> etc
[04:59] <imbrandon> MarkDude: ^^
[05:00] <imbrandon> docs are linked at http://juju.ubuntu.com btw, pretty sure that was obvious tho
[05:00] <imbrandon> but just in case
[05:00] <imbrandon> but yea, sometime in the next 24hrs i'd say maybe 48 tops there will be a minor version refresh
[05:01] <imbrandon> so it will be perfect timing for their feedback and i might be able to slip stuff in if its not a core bug
[05:01] <imbrandon> etc
[05:01] <imbrandon> right away in those cases
[05:02] <MarkDude> Sorry, but the page you were trying to view does not exist.
[05:02] <imbrandon> oh and you saw my "Download for Ubuntu" JS/CSS button thing ? I made one for Fedora and OSX too, might for SuSE as well if i get bored
[05:02] <imbrandon> i'll link ya up
[05:02] <imbrandon> bah
[05:03] <imbrandon> let me go look
[05:03] <imbrandon> i did that from memory
[05:03] <imbrandon> heh
[05:03] <imbrandon> https://github.com/jujutools/rpm-juju
[05:03] <imbrandon> there we go
[05:03] <imbrandon> sorry bout that
[05:04] <imbrandon> anyhow like i said i got a little bit of docs and such creeping in tho todayish so that will help them too
[05:09] <imbrandon> okies man, i'm about to crash, been a long day, hit me up anytime at imbrandon@ubuntu.com too if you dont catch me on IRC
[05:10] <imbrandon> MarkDude: and there is a bug tracker on linked on that RPM page too "Issues" if anyone ways to report something
[05:11] <MarkDude> Cool- I will include your email on the page to
[05:11] <MarkDude> thx imbrandon
[05:11] <imbrandon> i'll do the leg work and figure out if its a rpm specific issue or core one and file them in LP on their behalf if its core so they wont have a escuse not to report it :)
[05:12] <imbrandon> cool cool, where ya posting this btw ?
[05:14] <MarkDude> https://fedoraproject.org/wiki/Juju
[05:19] <imbrandon> rockin, ok i'm off to bed man, take it easy
[05:19] <imbrandon> sorry to run on ya :)
[11:04] <jml> I'm working on my charm again. Getting rid of the sqlite kludge so I can aim it at postgresql. Exciting times.
[11:27] <jamespage> jml: enjoyed your blog posts BTW
[11:27] <jml> jamespage: thanks :)
[11:27] <jamespage> agree that its quiet here in the mornings....
[11:28] <jml> yeah
[11:29] <jml> juju is the first command-line tool I've used in a long time that makes me think "this should have a GUI"
[11:36] <jml> uhh, how do you get the port from the postgres charm?
[11:39] <jml> is it correct to just assume the standard port?
[11:52] <jml> I'm writing a script to call juju for my users. Is there a way to get the public address of the only deployed unit? (Would prefer the exposed service URL, tbh.)
[11:59] <jml> why are stacks any more difficult than, say, a .dot file?
[12:05] <jml> what I want is something that looks at my local charm, detects whether there are any changes between it and the last deployed charm, and if there is, add --upgrade to my deploy call.
[12:05] <jml> what I want is something that looks at my local charm, detects whether there are any changes between it and the last deployed charm, and if there is, add --upgrade to my deploy call.
[12:05] <jml> i.e. I want 'make'
[12:05] <jml> (sorry for double entry. keyboard error.)
[12:40] <jamespage> jml, hmm
[12:40] <jamespage> jml, the postgresql does assume default port
[12:40] <jamespage> charm that is
[12:41] <jamespage> jml, the only way I know to get it to automatically update charms is to bump the version number in the revision file manually before doing a deploy
[12:41] <jamespage> but I often forget todo that - and have to use --upgrade anyway
[12:42] <jml> well, the real question is how do I detect that the version number needs bumping
[12:43] <jml> the environment has a copy of the charm stored somewhere, presumably
[12:44] <jml> if I could get that, it would be easy to ask "do your copy and my copy differ? if so, bump my version. if not, great."
[12:45] <jamespage> jml, it does
[13:57] <surgemcgee> Quick question, one of my web sites uses a node.js server. It is suppossed to open port 8080 which does not happen. What is the best way to open this port, including it in the charm?
[14:11] <marcoceppi> surgemcgee: You can include it in the charm if the charm requires the node.js server etc. If you need to just ad-hoc open it you can do that with juju-jitsu
[14:11] <marcoceppi> Ideally if the charm users it/needs it it should expose it
[14:23] <jaustinpage> Im trying to debug some problems I am having with the swift charms. anyone else working on these, or using them?
[14:47] <SpamapS> adam_g: ^^ jaustinpage needs help w/ swift
[14:47] <SpamapS> jaustinpage: adam_g wrote them
[15:21] <jaustinpage> SpamapS: thanks for the info
[15:38] <SpamapS> japage: curious, what issues are you having w/ swift?
[15:43] <cheez0r> japage: I'm working with the swift charms, what are you seeing?
[15:47] <cheez0r> juju folks; I've got 11 nodes in my MaaS cluster, and 11 machines created, with 11 total services on them. When I attempt to add a unit to one of the services, it adds a 12th machine in state pending, assigns the unit to that machine, and nothing ever happens. Is there a way to make juju use an existing machine to host the unit, or what?
[15:48] <cheez0r> So far the behavior seems to be one service unit per machine.
[15:52] <japage> cheez0r - I seem to be seeing some sort of error when i try to create the connection between swift-storage and swift-proxy
[15:53] <japage> It is like the swift-relation-changed function is not able to add the storage nodes for some reason
[15:54] <japage> cheezor: i dont think you can push more than 1 service out to a node
[15:55] <cheez0r> that's awfully strange.
[15:55] <cheez0r> I should be able to, for instance, run nova-compute and swift-storage on the same node.
[15:55] <japage> cheez0r: I agree
[15:56] <japage> cheez0r: have you been able to deploy swift to 4 or more machines, and get the relationship between swift-proxy and swift-storage working/
[15:56] <cheez0r> no.
[15:56] <japage> *?
[15:56] <cheez0r> I have not pursued the relationship at all
[15:56] <japage> hmm, ok
[15:57] <cheez0r> I'm right now working on getting swift-storage on multiple nodes- but I'm out of nodes
[15:57] <japage> im cheating, im using vm's to test, so I can create more nodes as needed.....
[15:57] <cheez0r> nice.
[15:57] <cheez0r> I've been trying to deploy a whole MaaS/Juju/OpenStack cluster on HP Blade hardware.
[15:58] <cheez0r> for about a month.
[15:58] <SpamapS> cheez0r: everybody has asked for the ability to run two things on one machine
[15:58] <japage> a month? the rest of the openstack charms seem to be working well, at least for me.
[15:58] <SpamapS> cheez0r: but as yet, that feature is not implemented in juju
[15:59] <SpamapS> cheez0r: part of the reason being that juju was envisioned first as "apt-get for the cloud" not "openstack deployment tool"
[15:59] <cheez0r> japage: I've had many issues that have roadblocked me
[16:00] <SpamapS> cheez0r: so, with the cloud, you just size your VMs right
[16:00] <cheez0r> SpamapS: yeah, si comprende
[16:00] <cheez0r> The more I work with juju + openstack the less I think they're a good pairing
[16:00] <SpamapS> cheez0r: but w/ real hardware, you get what you get
[16:00] <cheez0r> but perhaps that's going to improve as juju evolves
[16:00] <SpamapS> cheez0r: Its the #1 feature request
[16:01] <SpamapS> cheez0r: I think it will land as the first feature after the go port is done.
[16:01] <japage> I've been "accidently" using juju/maas exactly as intended...
[16:03] <jamespage> SpamapS, hey - you appear to be chair for our team meeting today!
[16:03] <jamespage> still OK for that or do you want to slide to me?
[16:04] <cheez0r> SpamapS: thanks for the info man, very helpful.
[16:14] <negronjl> 'morning all
[16:36] <SpamapS> negronjl: are you stalking the halls of Velocity as well?
[16:44] <negronjl> SpamapS: I may go back there tomorrow but, not today
[16:44] <negronjl> SpamapS: Did enough stalking yesterday :)
[16:49] <hazmat> SpamapS, trying to upload a branch for co-location, but network here is choppy, going to hit up the speaker lounge and hardline it post plenaries
[16:49] <hazmat> re jitsu
[17:02] <SpamapS> hazmat: sweet
[17:06] <koolhead17> hello all
[18:39] <lifeless> morning y'all
[18:41] <SpamapS> lifeless: howdy
[18:43] <lifeless> SpamapS: o/
[18:43] <lifeless> hey, so did you see my query about proof?
[18:43] <lifeless> 15:48 < lifeless> is this expected? :  charm proof .
[18:43] <lifeless> 15:48 < lifeless> E: could not find metadata file for .
[18:43] <lifeless> 15:48 < lifeless> E: revision file in root of charm is required
[18:43] <lifeless> 15:48 < lifeless> but
[18:43] <lifeless> 15:48 < lifeless> charm proof $(pwd)
[18:43] <lifeless> 15:48 < lifeless> works fine
[18:44] <SpamapS> lifeless: that does not make much sense.
[18:44] <_mup_> Bug #1018059 was filed: Disable fsync on zk to speed tests. <juju:In Progress by hazmat> < https://launchpad.net/bugs/1018059 >
[18:44] <lifeless> indeed.
[18:45] <_mup_> Bug #1018061 was filed: Disable fsync on zk to speed tests. <juju:In Progress by hazmat> < https://launchpad.net/bugs/1018061 >
[18:45] <lifeless> would you like a bug, and if so where
[18:45] <SpamapS> lifeless: if args.charm_name: charm_name = args.charm_name
[18:45] <SpamapS> else: charm_name = os.getcwd()
[18:45] <_mup_> Bug #1018062 was filed: teminate-machine should provide and option to '--force' <juju:New> < https://launchpad.net/bugs/1018062 >
[18:46] <lifeless>  charm proof
[18:46] <lifeless> usage: proof [ charm_name | path/to/charm ]
[18:46] <SpamapS> lifeless: charm proof . works for me in all my charms
[18:47] <SpamapS> as does no argument, which assumes .
[18:47] <lifeless> http://paste.ubuntu.com/1061284/
[18:47] <lifeless> SpamapS: I'm running precise.
[18:47] <lifeless> SpamapS: does that make a difference?
[18:47] <SpamapS> no, I am too
[18:48] <SpamapS> tho I might have a more current charm-tools
[18:48] <SpamapS> the one in precise is pretty old by now
[18:56] <SpamapS> lifeless: I think that bug is fixed in trunk basically.
[18:57] <lifeless> hokay
[18:57]  * lifeless suggests more SRU is in order
[18:58] <hazmat> lifeless, http://paste.ubuntu.com/1061301/
[18:58] <hazmat> should fix it
[18:59]  * hazmat submits a branch
[18:59] <hazmat> actually this easier to cowboy ... SpamapS, m_3, jimbaker` any objections to the one liner above
[19:02] <jimbaker`> hazmat, +1
[19:02] <SpamapS> hazmat: if you think that corrects the problem (a problem I don't have or see) then yes, just commit and push
[19:02] <SpamapS> hazmat: please run 'make check' too
[19:02] <SpamapS> hazmat: charm-tools has tests
[19:02] <SpamapS> hazmat: consider maybe adding a test for this :)
[19:04] <cheez0r> hey juju guys, I just want to confirm that I understand this: Juju does not support specifying which node a charm is to be deployed to, right? It just pulls a node from what's available?
[19:04] <cheez0r> All of the reading I've done on this topic has left me with that understanding; I'm just trying to confirm I'm right.
[19:04] <SpamapS> cheez0r: yes thats correct
[19:04] <cheez0r> Thanks SpamapS!
[19:04] <hazmat> cheez0r, yes at the moment, re jitsu extensions that capability is coming soon
[19:04] <jimbaker`> hazmat, my only objection to this code is that charm_name and charm_path are rather conflated here
[19:04] <jimbaker`> but that's the existing case
[19:04] <hazmat> jimbaker`, that's the entire script
[19:05] <jimbaker`> indeed
[19:05] <hazmat> jimbaker`, feel free to rewrite
[19:05] <jimbaker`> hazmat, i'm sure there will be some opportunity :)
[19:06] <SpamapS> I believe we have a lot of refactoring to do in charm proof
[19:07] <SpamapS> I'd even be open to changing the name to something else, since proof was a play on 'principia mathematica'
[19:13] <hazmat> SpamapS, is trunk open?
[19:16] <SpamapS> hazmat: tonight
[19:17] <hazmat> SpamapS, ack, i just closed out the galapagos milestone
[19:17] <SpamapS> hazmat: actually, screw that
[19:17] <SpamapS> closed?
[19:17] <hazmat> SpamapS, if you have a separate branch, why are we gating trunk
[19:17] <SpamapS> I mean to creat an actual release
[19:17] <SpamapS> I have no branch
[19:17] <SpamapS> Its a psychological freeze
[19:17] <hazmat> SpamapS, the distro branch?
[19:17] <SpamapS> meant to get you guys to *test* it
[19:17] <SpamapS> hazmat: right, the distro package is a quilt stream. ;)
[19:17] <SpamapS> hazmat: anyway, lets just open trunk, I'm going to tag 0.5.1 as trunk
[19:18] <hazmat> SpamapS, ack
[19:18] <SpamapS> hazmat: I meant to create a release from the galapagos milestone
[19:18] <SpamapS> err, I'm going to tag r544 as trunk
[19:18] <hazmat> SpamapS, i just did, its just a label though no tarball attached
[19:18] <hazmat> https://launchpad.net/juju/+milestone/galapagos
[19:18] <SpamapS> I'll do tarballs if somebody requests it
[19:18] <SpamapS> but I don't really see a need
[19:19] <SpamapS> tag is fine
[19:19] <SpamapS> hazmat: I was going to bump the version in setup.py too
[19:19] <hazmat> SpamapS, sounds good
[19:19] <SpamapS> hmm wait, natty and oneiric still FTBFS
[19:21] <SpamapS> hazmat: can you hold just a bit longer on lp:juju ? I want to make sure natty/oneiric build
[19:21] <SpamapS> pretty sure this is buildds being slow, not a real problem
[19:21] <SpamapS> hazmat: heh, tho your fsync change might be a solution for that
[19:22] <hazmat> SpamapS, sure, just want to greenlight the sub port change and the fsync stuff in
[19:22] <hazmat> SpamapS, perhaps.. some of the status setup tests need exorcism
[19:22] <hazmat> they setup the world and examine a fraction
[19:22] <hazmat> and worse they get used by other tests as a base
[19:22] <SpamapS> hazmat: I'm tempted to just make a branch for 0.5, and do any fixes in there
[19:23] <hazmat> SpamapS, hmm
[19:23] <SpamapS> which is probably what we should do, but I liked the idea of taking a week to actually use/test the release
[19:23] <hazmat> SpamapS, branch for stable or branch for features, either sounds reasonable
[19:23] <hazmat> SpamapS, afaik the next major incompatible feature is upgrade support
[19:24] <SpamapS> hazmat: I was thinking we should start honolulu by adding a feature which which makes arbitrary PPA selection possible so we can add PPA's and keep ppa:juju/pkgs stable
[19:25] <hazmat> SpamapS, effectively the upgrade stuff has support for things ... like that
[19:25] <SpamapS> I was hoping you'd say that
[19:25] <hazmat> ie. arbitrary release url support
[19:25] <hazmat> you can point it to any directory of releases
[19:26] <SpamapS> https://code.launchpad.net/~juju/+archive/pkgs/+build/3600404 .. once that builds.. I'll commit the 0.5 -> 0.5.1 change and release that as 0.5.1...
[19:26] <SpamapS> Then I was thinking I'd alter the PPA build recipe to pull from a stable series, and create a new PPA for trunk
[19:26]  * hazmat needs an osd notify for website changes
[19:26] <hazmat> SpamapS, +1
[19:27] <SpamapS> hazmat: what would you say to shortening honolulu to just 3 weeks? Basically just merge everything that is approved already, and wrap up the zk acl work?
[19:27] <hazmat> SpamapS, why?
[19:27] <SpamapS> hazmat: so we can get the zk acl work out faster. :)
[19:27] <hazmat> SpamapS, your setting what feels like arbitrary deadlines
[19:28] <hazmat> doesn't make anything go faster
[19:28] <SpamapS> hazmat: no, this would get us back on the 6 week cadence.
[19:28] <SpamapS> since we're 3+ weeks late
[19:28] <hazmat> SpamapS, but why are we late?
[19:28] <SpamapS> Because nobody cares about releases except me
[19:28] <SpamapS> and I've been busy/distracted/etc.
[19:29] <hazmat> SpamapS, i think its more about the num of developers assigned to py juju atm
[19:29] <SpamapS> well we didn't delay it for want of features/bug fixes
[19:29] <SpamapS> just.. time to organize the release
[19:30] <SpamapS> the whole point of having a cadence is to just ship what we have when the day arrives.
[19:30] <SpamapS> that way people don't feel rushed to push things that aren't ready, because they know they will see a release in 6 weeks
[19:30] <SpamapS> but yeah
[19:30] <SpamapS> w/o developers this is a bit moot :)
[19:31] <hazmat> jimbaker`, hows the sec group rework coming?
[19:32] <SpamapS> https://launchpadlibrarian.net/108722045/buildlog_ubuntu-natty-i386.juju_0.5%2Bbzr544-1juju5~natty1_FAILEDTOBUILD.txt.gz
[19:33] <hazmat> jimbaker`, ^
[19:33] <hazmat> new format bug
[19:33] <SpamapS> that has failed 3 times in a row
[19:33] <SpamapS> works fine on precise and quantal
[19:36] <SpamapS> hazmat: I'm tempted to just merge in your no fsync change and see if that solves it
[19:53] <jimbaker`> hazmat, i'm currently sick, so not so much progress yet
[20:01] <hazmat> m_3, your in au?
[20:01] <hazmat> jimbaker`, ack, thanks for the update
[20:04] <hazmat> SpamapS,  that failure is odd if its rel specific, its the same py version, and same major libyaml
[20:04] <hazmat> SpamapS, do we even care about pre oneiric?
[20:04] <SpamapS> hazmat: not much no, but oneiric fails too
[20:05] <SpamapS> hazmat: its more that I want to know why, not that I want to care about oneiric/natty
[20:07] <SpamapS> ok appt time
[20:07] <SpamapS> hazmat: bbiab.. I'd be fine w/ pushing the fsync change into trunk.. if that solves it, we'll ship it with 0.5.1. :)
[20:16] <hazmat> bcsaller, do you have time to debug ^
[20:18] <bcsaller> hazmat: you mean the libzk deadlock thing still?
[20:18] <bcsaller> I have looked at it but didn't finish it yet, I can poke at it again today
[20:18] <hazmat> bcsaller, no the test failure on oneiric
[20:19] <bcsaller> looks like natty
[20:19] <hazmat> bcsaller, the libzk deadlock with security isn't critical, the test failure (see build failure link above ) is the problem
[20:20] <hazmat> bcsaller, SpamapS mentioned it also exhibits under oneiric
[20:33] <bcsaller> hazmat: it looks like the default json module would have to fail for this to break, but I'm spinning up an instance
[21:12] <jml> what I think of when I think of juju & puppet: http://tinyurl.com/yfn5wn9
[21:31] <sidnei> jml, why?
[21:55] <jml> sidnei: puppet. juju. think about it. (I guess it might not translate well.)
[22:06] <lifeless> jml: bad man :P
[22:32] <SpamapS> jml: Hahahah thats fantastic
[23:21] <imbrandon> ahhh finally .... it lives !! http://bholtsclaw.github.com/showdown/
[23:23] <JoseeAntonioR> imbrandon: ping, question, do you have a mailman charm?
[23:23] <imbrandon> i do not, there MIGHT be one
[23:23] <imbrandon> but i would need to look hadent seen one around yet
[23:23] <JoseeAntonioR> that was what I was asking, not you, in general :P
[23:23] <JoseeAntonioR> if you see one, let me know
[23:24] <imbrandon> you can check on the store
[23:24] <imbrandon> it shows all of them
[23:24] <imbrandon> and the ones in-porogresss
[23:24] <imbrandon> as well
[23:24] <imbrandon> progress*
[23:24] <imbrandon> one sec i'll get you the exact link
[23:24] <JoseeAntonioR> it's not there, so I assume there's no mailman charm
[23:25] <imbrandon> yea if there isnt one there and you dont see it in the ~queue the other place to look is a bug against juju charms
[23:25] <imbrandon> but i think those show in the in comming queue
[23:25] <imbrandon> ( maybe not without a branch , not sure )
[23:25] <imbrandon> but yea
[23:26] <imbrandon> if its not there then nope and its fair game, if it is there but no one worked on it in 30 days
[23:26] <imbrandon> then it is also fair game but still probably nice to ping the other party if its practial to do so
[23:26] <imbrandon> but thats just "best" really
[23:27] <imbrandon> SpamapS: i guess no word from RT ? unfortunate :(
[23:28] <JoseeAntonioR> I'll see, I may write one if I have time
[23:29] <imbrandon> even if your doing it shelfishly and then push what you have to your own branch on LP like ~lpip/charms/precise/mailman
[23:29] <imbrandon> then someone else has a start on it when they go to finish etc
[23:29] <JoseeAntonioR> great
[23:29] <JoseeAntonioR> mental note taken
[23:29] <imbrandon> so even partial charms are nice to keep on LP in your name too even if not ready for the store for whatever reason
[23:30] <imbrandon> and if you push to a branch named like that me or anyone can install your version of the charm too like
[23:30] <imbrandon> juju deploy cs:~lpid/precise/charmname
[23:31] <imbrandon> :)
[23:31] <JoseeAntonioR> that's great, JoseeAntonioR didn't know that
[23:31] <imbrandon> yup yup. thje docs are actually prettu good on the basics
[23:32] <imbrandon> some things and adv stuff a little dated
[23:32] <imbrandon> but for most projects i've been on ours are fantasic compared
[23:32] <imbrandon> even though we;re actually trying to make them even better still
[23:32] <imbrandon> :)
[23:33] <imbrandon> http://www.jujucharms.com/docs
[23:34] <imbrandon> anyone that is in charm-contributors can commit or do a merge preposal too so alot of ppl can help like a wiki but cleaner
[23:34] <imbrandon> and easier to manage :)
[23:34]  * imbrandon gets back to his charm for now, havent actually done any juju stuff at all today yet
[23:36] <JoseeAntonioR> :P
[23:36] <JoseeAntonioR> go for it
[23:42] <imbrandon> SpamapS / m_3 ( and everyone ) I almsot forgot to mention it since i've been not in #juju most of today, there is now a #juju-ports ( with pointers to here if all are afk ) for OSX and Fedora Peeps ( and others as more come ) to collab and get support and not clutter here if not needed
[23:43] <imbrandon> its on the irc teams radar too as part of the official juju- namespace etc, and Markdue put the word out over there and we already have a few ilders
[23:43] <imbrandon> ( like 3 )
[23:43] <imbrandon> just kinda FYI