[OPEN-ILS-DEV] Bug Wrangling

[James Fournie]

Hi Jason, I was unable to make the meeting yesterday, but I'm happy to
help in the triaging if people find it helpful.  I ran into a point
where most of the bugs left to deal with were bugs that we at SITKA
reported, and I was hesitant to do anything with those so as not to
bias our bugs which we would obviously think are important.

I did exactly what you are doing with a lot of old 1.6 tickets, so the
state of those shouldn't be too bad.  I can help you with the 1.6 side
of things, at least until we switch to 2.0.  Have we set an EOL date
on 1.6?  I'd suggest we confirm that and use that as a point at which
we say "ok to solve this bug you need to upgrade to 2.0".  In my
experience so far, there's still a lot of 1.6 bugs that affect 2.0 as
well.

To answer a question in the IRC logs, I marked a bug "triaged"
essentially if I looked at the bug and it was not urgent.  I marked a
big "confirmed" if I could replicate the behaviour or another person
had the same problem.

With respect to milestones, I would think that the target milesones
would be up tor whoever is solving the bug to set.

In addition to a "bug-stomping day", which I think is a great idea,
I'd like to suggest that (one day) we have something akin to Ubuntu's
"One Hundred Papercuts", I think there are still a lot of usability
and visual things that could be identified and improved, and although
they're by no means urgent, they mean a lot to front-line staff and
patrons.

I just wanted to say to the developers, thanks for all your hard work
on the 2.0 release logistics, this is a vast improvement over previous
major releases, it's wonderful :)

~James Fournie
BC SITKA

On Tue, Nov 30, 2010 at 7:55 AM, Jason Stephenson <jstephenson at mvlc.org> wrote:
> Hi, all.
>
> During the Developers' IRC Meeting yesterday, I volunteered to change all
> those bugs with "fix committed" status to "fix released" status where
> appropriate.
>
> While it seems relatively straightforward, I thought that I would share the
> methodology that I plan to use to make that determination in the interest of
> transparency.
>
> I plan to go through each of these bugs, read the descriptions and notes,
> and check the commit messages from SVN to see when the code was committed.
> If the commit appears in a released version of Evergreen (1.4.0.7, 1.6.0.10,
> 1.6.1.4, or 2.0.0 beta 3), then I will change the status to "fix released."
> If the commit is only in trunk or in a branch revision appearing after one
> of the listed releases, I will not change the status to "fix committed."
>
> I am also willing to set target milestones for other open bugs, but I would
> need some guidance on what other developers would think are appropriate bugs
> to target for rel 2.0 and 2.1. I also don't have any real experience with a
> 1.6 system, so would not be of any use triaging bugs that only affect 1.6
> but are gone from rel_2_0 or trunk.
>
> If anyone has any suggestions or comments on the above, I'm certainly open
> to your ideas.
>
> Cheers,
> Jason Stephenson
> Merrimack Valley Library Consortium
>