<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">I strongly support the idea of a consolidated bug triage methodology and process across all of the Juju projects.</span><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">I'm also happy to report that we have triaged all of the bugs in the juju project, and that there are twenty two bugs currently moved to the "fix commited" status which will be in our next Juju Core release. </div>
<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<a href="https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&field.status%3Alist=FIXCOMMITTED" target="_blank" style="color:rgb(17,85,204)">https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&field.status%3Alist=FIXCOMMITTED</a></div>
<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
We are working hard on getting lxc containers and a local provider in place, as well as creating API's for everything so that we can have agent level security, and can take on the project of managed major version upgrades of juju itself.  But I'm happy to say that lots of usability issues have been resolved along the way. </div>
<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
Please continue to go in and mark bugs that are impacting you as "affects me" and bring anything that is a blocker for progress in any of your deployments to the attention of this list.   It's exciting to see a growing collaboration between users and developers here on the list, and in the bug tracker.  So, much thanks to everybody that has worked on reporting bugs, triaging them, or fixing them.</div>
<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
This is the work required to make an open source project grow and thrive.   Thanks for doing it. </div><div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div>
<div style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">--Mark Ramm</div><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 4:23 AM, John Arbash Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
I really like the idea of using Critical for bugs which must be fixed<br>
ASAP. Given Juju isn't a live service, those probably fit ok for<br>
things which must be fixed for the next release. (Launchpad being a<br>
live service that rolls out daily has slightly different requirements.)<br>
<br>
I would like us to make the bug tracker actually useful, right now<br>
there are a fair number of bugs marked "high" that are >6months old,<br>
and a bunch of bugs that have been looked over, but don't have a<br>
status or importance update.<br>
<br>
I do think it is big enough that we actually need to make a team<br>
policy of whether we want to actively maintain the bug tracker or not.<br>
And then actually allocate resources (such as the on-call-reviewer) to<br>
maintaining it.<br>
<br>
John<br>
=:-><br>
<div><div class="h5"><br>
<br>
On 2013-06-07 18:57, Danilo Šegan wrote:<br>
> Hi all,<br>
><br>
> We are starting up with on-call reviewers doing bug triage as<br>
> well. I've done an initial round going over ~30 oldest open bugs<br>
> and 5 newest untriaged bugs.<br>
><br>
> I've also made an attempt at bug triaging guidelines:<br>
><br>
><br>
> <a href="https://docs.google.com/a/canonical.com/document/d/1_XMfxKpySqy3bzM7oK3pYFWYvsll-6kMN85AM4kOG-o/edit#heading=h.a685atm1ob" target="_blank">https://docs.google.com/a/canonical.com/document/d/1_XMfxKpySqy3bzM7oK3pYFWYvsll-6kMN85AM4kOG-o/edit#heading=h.a685atm1ob</a><br>

><br>
><br>
><br>
> Only now I see that I can't set the document to be publicly<br>
> viewable but editable by anyone in Canonical.  I plan to move it to<br>
> a wiki page soon (or anybody else can do that).<br>
><br>
><br>
> At this time, I am trying to define 'Critical' as something that<br>
> needs immediate attention (drop everything, solve this) and 'High'<br>
> as something that needs to be worked on asap (but does not require<br>
> you to drop anything in progress).<br>
><br>
> I am pretty sure that people will have different opinions on these<br>
> topics, but I wanted us to get started, and having some base<br>
> definitely helps.<br>
><br>
> In that vein, I've retriaged old bugs, and I suggest we keep doing<br>
> that: if everybody does 30 open bugs (and records their progress<br>
> towards the bottom of that google doc), we can get to a usable<br>
> 'High' pile in a week or so.  For instance, I've done all the bugs<br>
> that have their ID numbers in the six-digit territory (so, all bugs<br>
> < 1000000).<br>
><br>
> I haven't bothered defining other priorities, or restricting their<br>
> use like Launchpad team used to do.  I simply don't care enough<br>
> about non-Critical and non-High bugs, but feel that we've got the<br>
> bugs reasonably under control (or can get there easily) that we can<br>
> leave users with the option of using different scales of<br>
> non-importance :).<br>
><br>
><br>
> A couple of problems I've hit:<br>
><br>
> - juju-project is not very usable since it includes some, but not<br>
> all of our juju-core related projects; it also includes extras that<br>
> we do not necessarily care about right now - juju-core team does<br>
> not have sufficient permissions on at least goamz and goyaml<br>
> projects to set all the statuses, milestones and such - it would be<br>
> good to work towards a consolidated triage policies for all of the<br>
> juju teams - juju/juju-core bugs and triage: I am sure it's going<br>
> to be very confusing to our users for all the bugs that affect both<br>
> projects (I wonder if it makes sense to change at least the display<br>
> name for "juju" to "juju-python" or similar)<br>
><br>
> Thoughts, comments?<br>
><br>
> Cheers, Danilo<br>
><br>
><br>
><br>
<br>
</div></div>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.13 (Cygwin)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iEYEARECAAYFAlG1mygACgkQJdeBCYSNAAP2hgCfeYilCuXMuZtHNONSSw7O7rUY<br>
IAEAn0L9ajBLMF+0kfQGT0UGPLUWeuFj<br>
=stW7<br>
-----END PGP SIGNATURE-----<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a><br>
</div></div></blockquote></div><br>