UDS is fast approaching, lets get the ball rolling on some pre-UDS discussions

[Clint Byrum]

With UDS in Copenhagen just around the corner, I'd like to start some
conversations regarding various topics we will be discussing there. We
should aim at boiling these down to a few (4 - 6) blueprints to be
discussed in the usual UDS format.

I'll propose my list below. Please reply to each one in individual emails
so that we can have different sub-threads for each discussion.

One topic carries over from last time as all work was deferred:

* Resource map - I went ahead and moved the previous BP forward to R
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-juju-resource-map

I don't think we need to revisit the discussion on that one, but perhaps
some would like to. I think its just a matter of doing it.

* Transition from python to go
We've discussed at various times that we will probably need to be able
to install both versions of juju at the same time as long as there
are features in the python version that do not exist in Go. We need to
discuss this and make sure we are doing things "the right way".

* juju-jitsu's future
juju-jitsu is an important project, but it has some big weaknesses in the
near term future. Since it hooks directly into the python code, a few of
its commands simply won't work with Go. We should go through all of the
commands and decide where they should live (in juju core, in jitsu, etc.)

* Stacks
I'd like for the discussion of how these should work to start well before
we all sit down for 55 minutes in a room in Copenhagen. Lets come to
the table with ideas and sticking points, so it doesn't turn into a 55
minute bikeshedding session.

* Placement
#1 requested feature in juju is allowing deploying services together in
the same machine. Seems like a good next thing to work on. Like stacks,
we should come with as many facts as possible and maybe even commission
a spike to prove what is possible before making any decisions.

* Charm Store Security Policies
There are two parts to this.
 - how to audit an incoming charm for problems
 - how to protect the integrity of the charm store

* Generic Charms
This is dependent on the discussion around Stacks. After we figure out
a plan for that, we need to talk about the plan for generic charms that
are shared between multiple actual charms going forward.

* Juju Bug Hunt
As of this writing:
98 New bugs
297 Open bugs
20 In-progress bugs
9 Critical bugs
51 High importance bugs

297 is a lot, and we should come up with a plan to go through these and
decide what to do. As part of this discussion, we should decide on how
best to resolve the fact that most development around juju is happening
at lp:juju-core, but all of these bugs are in lp:juju. My suggestion
for a working plan is to mark them *all* as affecting juju-core, and
then go through and triage them all and decide "Won't Fix", "Invalid",
or an appropriate status that suggests this is a thing juju-core should
address.

* Apport Juju Integration
It would increase community involvement and help with stability if every
juju deployed host had a 'juju-bug' command for juju users to run to
report a bug in juju itself.