Launchpad bug statuses

[Scott Kitterman]

On Thursday 04 October 2007 03:00, Jordan Mantha wrote:
> On 10/3/07, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > On Thursday 04 October 2007 01:00, Emmet Hikory wrote:
> > >    ... The parallel case of rejecting bugs
> > > for which nothing is happening is already established as a manual
> > > workflow (at least for Ubuntu), and so does not become worse through
> > > automation (regardless of any perceived benefits or detriments to
> > > users, reporters, triagers, contributors, developers, etc.).
> >
> > I pretty strongly disagree with this.
> >
> > Different teams and projects have different standards for how long is
> > long enough.  In Ubuntu Backports we don't (until LP took away the
> > choice) close bugs that have been incomplete as they are usually
> > incomplete due to lack of sufficient testing.  This testing, depending on
> > the package in question, may take quite some time.
> >
> > My perception is that LP developers have a "right" way to use LP in mind
> > and do not appear to be very open to alternate visions.  As an Ubuntu
> > developer, LP is a tool to work on Ubuntu and so the end state of the
> > distro at release and through updates is what matters, not the purity of
> > the bug database.
>
> Well, obviously LP developers have a "right" way to use LP in mind,
> they designed it. They have reasons for doing things they do, which
> are not always apparent to us because they have bigger plans/goals.
> The fact that LP developers regularly discuss design with users in
> public (on #launchpad, launchpad-users, and in bug reports) and often
> change implementations depending on our needs would, IMO, contradict
> your perception.

Sure, but the answer to the "LP is proprietary" complaint is that we should 
think of it as a service, not software.  Generally, service oriented 
organizations seek out customer needs/desires and try to meet them.  It is my 
impression in this thread that the LP developers view it the opposite way.  
They know how our workflow should work and it's up to us to understand it.

> I think it's clear that more discussion needs to take place. This
> thread is evidence of that. What we need is to be on the same page so
> that we understand how the LP developers designed LP to be used and
> they understand how we are using LP. I'd like to thank Christian for
> digging into this issue as it seems to me that it's the source of
> quite a bit of friction.

If we (Ubuntu) are LP's customer, then I think their view of how LP is to be 
used is interesting for what process/workflow improvements Ubuntu might find 
from it, but I if they want their proprietary system to be useful to their 
customers, I think that the onus is on them to go understand their customer's 
needs.

> In interest of trying to get something productive out of this thread
> I'd like to throw out a few ideas:
>
>   - maybe LP devs can do an "observation" day in #ubuntu-bugs during a
> HUG Day to see how the Ubuntu Bug Squad is using LP.

I think this would be good.  It would be worthwhile, I think, for LP devs (at 
least some of them) to invest some time in doing both triaging and bug fixing 
work in Ubuntu.  I don't think they'll really understand how thing are being 
used without actually doing it.

>   - is it worth documenting the bug work flow that LP developers have
> in mind when they are designing new features for LP? Also getting
> common use cases for contributors, MOTUs, and Core Devs may help?

It'd be interesting, but unless I'm trying to figure out how to make MOTU work 
better, I'm personally unlikely to be greatly interested.  As I said above, I 
think the tool/service should support the work flow, not drive it.

>   - better post-rollout support. Having a bunch of changes hit on a
> Friday as developers are trying to prepare a release can be quite
> frustrating, especially since Canonical employees tend to disappear on
> the weekend (understandably so).

Based on the last release, I think better pre-rollout testing is essential 
too.  As I've said elsewhere, I think the automatic bug expiration idea is a 
bad one, but I think it is particularly concerning that it touched so many 
bugs that it wasn't supposed to.

Trying to recover from both the planned and unplanned affects of the last 
release took virtually all of two days of the volunteer Ubuntu development 
time I have.  I think we'd all be a lot better off if there were fewer, well 
thought through, well tested changes in each release.

>  - better pre-rollout announcement/discussion. Obviously catching
> problems *before* they get rolled out is better than trying to clean
> up the mess afterwards. We've seen that sending an "this is what we
> just released" announcement email doesn't sufficiently inform Ubuntu
> developers. It would be nice to have a "these are changes we are
> planning to do for the next rollout that will affect how you work"
> around a week beforehand (even if some get retargeted at the last
> minute) to ubuntu-devel-announce.

Agreed.  Additionally, I think that Ubuntu is an important enough customer 
that LP ought to deconflict it's release schedule from major Ubuntu 
development milestones.

> These are just some random thoughts.

Thanks for that.  

Scott K