Adopting Nautilus, wiki page created

[Bruno Girin]

On Wed, 2010-01-06 at 20:25 +0100, Sense Hofstede wrote:
> >> Bug descriptions are often incomplete and don't reflect the bug report
> >> properly. I also often don't extend the bug descriptions, even though
> >> it would be desirable. However, it is a lot of work to do this for all
> >> bug reports. We could mention it in the explanation of the first task,
> >> but I think that it is more something the Bug Squad as a whole should
> >> pay attention to. Furthermore I think that it would be better to spend
> >> our energy on triaging bug reports and making sure they are either
> >> marked as Invalid or are of use to the developers and packagers. We
> >> can't afford to do much else with so many bug reports.
> >
> > I'd say we can't afford not to improve the description. Once a bug is
> > triaged, it will end up with the developers. They then see the bug for
> > the first time and the first details they read will be the title and
> > description. As a (ex-)developer myself, I can guess what happens next:
> > if the description is vague or requires the developer to read through
> > dozens of additional comments, he will just ignore it and go to the next
> > bug report because he can't afford to lose time trying to understand the
> > bug. If the description is clear, he will just try out, have an "oh
> > yes!" moment and fix the bug before lunchtime.
> >
> > At the end of the day, the triaging process is the first phase of
> > getting a bug resolved. If bugs that come out of triaging are such that
> > the developers don't pick them up, we've failed. I agree with you that
> > we have a resource problem based on the number of bugs but I'd rather
> > triage 5 bugs and have all of them resolved than triage 25 and have 2
> > resolved.
> >
> > I think this is even more important for bugs that need forwarding
> > upstream because the person doing the forwarding may not be the same as
> > the person who did the original triage. Considering that the forwarder
> > will have to summarise the bug in the upstream system, the risk is that
> > the upstream summary is incorrect.
> >
> 
> I agree that the description is important. Really bad descriptions
> should indeed be
> improved and, if you've got the change, any description. However, I wouldn't
> improve bad/insufficient descriptions when the rest of the bug report makes the
> problem clear enough and the description isn't really hindering the developers.

To be done at the discretion of the triager then.

> 
> >>
> >> It is the task of the triager to determine whether the bug has to be
> >> forwarded upstream. The description, title and replies of/to the bug
> >> report should make this clear. Packaging errors are mostly Ubuntu
> >> bugs, unless the package was synced from Debian. In that case it
> >> should be forwarded to Debian.
> >> There is a separate task/subgroup for forwarding upstream because it
> >> is a disruption of your work when you have to leave Launchpad and not
> >> everyone is familiar with GNOME Bugzilla. I though it would be better
> >> to let people that focus on triaging bugs in Launchpad focus on
> >> triaging bugs in Launchpad. When a bug should be forwarded upstream
> >> they can open an empty task against the upstream project with the
> >> "Also affects project" button.
> >
> > That makes sense. I am comfortable with Bugzilla so am happy to do some
> > upstream forwarding for Nautilus. Having said that, is there a way to
> > see what bugs have been marked as needing forwarding but have not
> > actually been forwarded yet?
> >
> 
> When you open an empty task with the "Also affects project" button and
> not filling
> anything in the fields. You can search those with the Advanced Search
> functionality,
> or by copying parts of the URL of the wiki link to all bugs in Ubuntu
> with an empty
> upstream task[1].

I tried that but it returned only 7 bugs, which doesn't feel right. Then
again, going through a number of bugs today, it looks like most of them
have been forwarded upstream but they are still new in the upstream bug
tracker. I don't know if it means that upstream are not interested,
don't have the time or resources or if they actually resolve them but
don't update their bug tracker.


> >>
> >> Maybe it would indeed be wise to create a temporary focus group that
> >> goes to all bugs that were or weren't triaged and that are forgotten.
> >> It would be a lot of work to clean those bug reports, but it would be
> >> worth it. When it is done it is the task of the adoption group to make
> >> sure the adopted package stays in shape.
> >
> > One first step would be to identify all bugs that are in the Triaged
> > state but that haven't been forwarded upstream. That will give us an
> > idea of how big the problem is.
> >
> > Alternatively, we can just go through the bugs one by one with the
> > caveat that if the bug was reported against a previous version of
> > Ubuntu, we need to validate whether it still is an issue or if it has
> > been solved since then.
> >
> 
> Going through old bug reports will require to check whether they still
> apply to the current version of Nautilus. This (all combined) is indeed a lot
> of work, but it is something we'll have to do when we want to get Nautilus
> clean.

The earlier we start the earlier we finish then. However, how do we
coordinate that? For every bug that is now resolved, we can move it to
the "Invalid" state and take it off the list but what about bugs that
are still outstanding? How do each of us highlight what bugs he's
re-confirmed so that we don't duplicate effort? Use a specific tag?

And what should we do with bugs that we can't test for whatever reason?
Send a message to this list to ask for someone to have a look at it?

Regards,

Bruno