Re: Charm Store policy updates and refinement for 2.0

On Fri, Mar 18, 2016 at 1:28 PM, Charles Butler wrote: > Big +1 to the categories > > What i'd like to see is the policy document move to strong language where we > can build tooling around the automated checking of policy. > > Refactoring the MUSTS and SHOULDS give

Re: New feature for charmers - min-juju-version

On 20/03/16 20:21, roger peppe wrote: > If the released Juju 2.0 uses v5 of the charmstore API (which it will > soon hopefully anyway when my branch to support the new publishing > model lands), then there's a straightforward solution here, I think: > change v4 of the charmstore API to refuse to

Re: New feature for charmers - min-juju-version

If the released Juju 2.0 uses v5 of the charmstore API (which it will soon hopefully anyway when my branch to support the new publishing model lands), then there's a straightforward solution here, I think: change v4 of the charmstore API to refuse to serve min-juju-version charm archives to

Re: Planning for Juju 2.2 (16.10 timeframe)

On 16 March 2016 at 12:31, Kapil Thangavelu wrote: > > > On Tue, Mar 8, 2016 at 6:51 PM, Mark Shuttleworth wrote: >> >> Hi folks >> >> We're starting to think about the next development cycle, and gathering >> priorities and requests from users of Juju. I'm

Re: juju 2.0 beta3 push this week

Another feature which will be in the next beta is support for keystone 3 in Openstack. On 18/03/16 04:51, Rick Harding wrote: > tl;dr > Juju 2.0 beta3 will not be out this week. > > The team is fighting a backlog of getting work landed. Rather than get the > partial release out this week with

Re: Usability issues with status-history

> > ... > > > > I really think we want to be putting more status for machine pending > > progress. Now, as for 100 progress messages, it turns out the rate > limiting > > on status updates means we can drop some of them. (we always get 100 > events > > from LXD, but if we only update Juju with

Re: Usability issues with status-history

On 20/03/16 22:44, John Meinel wrote: >> >> ... >> >> For the second bug, where a downloading % spams the history, it seems like >> the easy answer is "don't do that". For resources, we specifically avoided >> putting download progress in status history for that very reason. In the >> future,

Re: Usability issues with status-history

> > ... > > For the second bug, where a downloading % spams the history, it seems like > the easy answer is "don't do that". For resources, we specifically avoided > putting download progress in status history for that very reason. In the > future, it seems like it could be useful to have some

Re: Usability issues with status-history

On Sun, Mar 20, 2016 at 2:51 AM, Andrew Wilkins < andrew.wilk...@canonical.com> wrote: > +1 on collapsing repeats. I'd also prefer to add more data to status so > that we can collapse entries, rather than dropping data so that we > don't/can't see it in history. > > What do we base "sensible

Re: Warning: test suite not actually isolated

John Thank you for discovering and working on this! This sounds like an awful can of worms and should be addressed in a dedicated manner. I'll add it to the tech debt board and bug squad board with a reference to your branch. I am not sure that anyone on core has a capacity to tackle it right

Re: Charm Store policy updates and refinement for 2.0

Bundles must only use charms which are already in the store, they cannot reference charms in personal namespaces. I assume this apples to only bundles that get promoted to recommended otherwise how would you enforce it? -- Director Meteorite.bi - Saiku Analytics Founder Tel: