> -----Original Message-----
> From: Max Bowsher [mailto:maxb1@ukf.net]
>
> These days, the dev@ list is a very busy place. It takes a
> truly dedicated person to attempt to read everything that
> goes on there. I regularly find myself discarding some
> threads, in order to reserve enough time to participate
> effectively in others. In particular, I am concerned about
> people posting patches which slip past our collective radar
> and are lost in oblivion. For this reason, I wonder if we
> have done wrong in trying to direct patches to email and
> never issue-tracking.
Interesting topic, but I don't agree with your solution to 'reconsider the
buddy system' so do you mind I take the opportunity to look a bit more at
the problem? I already read the other replies from Karl, Michael and Justin
so in some parts of my mail I'm also commenting on their suggestions.
When a user has a question she thinks might be a bug in Subversion, she is
asked to:
1) reread the FAQ and the book
2) search through the existing issues
3) find a buddy (on users, dev, irc...) to report a new issue
While I think this approach can work pretty good, our implementation has
some problems:
1) The book isn't uptodate with svn 1.3
2) Nobody reads FAQ's
3) Not all issues have meaningful summaries
4) The issue tracker is also used for patch tracking. While I think this is
OK, a PATCH is now implemented as a separate issue type which makes it more
difficult the see what the patch is for or to estimate its priority and
impact.
5) The existing issue report only shows the open issues, not the ones that
are already fixed but not yet included in a release (same for searching
through summaries). Leads to: 'yeah, that's issue #1234' mails on users@.
6) While there are a lot of issues (defect, task, patch, feature) in the
database, a lot of the fixes made in the code are not reported in the issue
tracker. Leads to: 'yeah, we fixed that on trunk in r12345' mails on dev@.
This problem also triggers other problems outside the issue tracking domain:
- it takes a long time to create the changelist,
- it's equally difficult to make sure all issues/changes included in a
release are covered by regression tests,
- while evaluating the impact of an upgrade, a Subversion admin has to look
through the logs of trunk to see in more detail what has changed in a new
release.
Possible solutions:
1) Alter the standard issue tracker report to also show issues resolved on
trunk. Ideally a user can select her current Subversion version, so the
report would include all open issues and the ones solved in a release newer
then the one she's using.
2) Whenever a change in functionality or an issue that can be encountered by
users is committed on trunk, report the change in the issue tracker. Or,
even better, use the Test Driven Development approach: report an
issue/feature including the acceptance criteria, write an
acceptance(//regression) test, fix the issue. I've been working with Eric on
the 'merge eol propchanges' issue (I wrote the tests -> Eric wrote the code
in a few iterations) and it has worked pretty good.
3) Add a separate comment to an issue with specifics on how a functional
change is implemented, so it becomes easier to update the documentation.
4) Remove the PATCH issue type and define a patch keyword. Re-categorize all
existing PATCH entries to issue, feature, enhancement or task and add the
patch keyword. Or instead of a new keyword patch we can define a new state
'patch available'? I'm undecided on this one.
Solution 2 and 3 can only work if someone is prepared to dedicate some time
to the issue tracker. So I'm also +1 on defining an Issue(Bug?) Manager
role, separate from the current Patch Manager role.
I have my doubts on what you mean with 'triaging issues', so I'll define
what I think a Issue Manager can do:
-> follow up the usage of the issue tracker: identify duplicates, contact
the reporter when the issue is unclear, fix summaries, reproduce the
issue...
-> initial prioritization of issues
-> trigger discussion on severe issues
-> summarize and report regularely (delta issues since last release, issues
to be fixed for next release ...)
-> agree on goals for next release (e.g. no P1's anymore, all devs fix one
issue, hold a bug squashing party ...)
-> create umbrella patches where helpful
-> motivate non-committers to submit patches for bugs or regression tests
(bite-sized keywords)
In a corporate environment I'd put 'assign issues to an iteration/milestone'
as a task for the Issue Manager, but I'm a bit sceptical on how that will
work in the Subversion project. Example: in the issue tracker there are now
4 unresolved P1 issues, opened somewhere in 2004/2005. Since these are P1's,
the Issue Manager would assign them to the next (fix) release. But, because
the I.M. lacks any formal authority, those issues will only get fixed when
developers volunteer to work on them.
That's why I think triaging is a task for the whole developer group.
Concerning who does what, some of the tasks of an Issue Manager are already
done now by any developer or tester with some time to spare. If devs agree
(atleast partly) with the things I propose, then I'm volunteering to take on
the Issue Manager role for atleast the next 6 months. That'll give me some
time to try some approaches and at the same time you'll find out pretty soon
if I don't have time/interest to continue doing this.
regards,
Lieven.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 9 01:35:15 2006