Permalink
Browse files

Start working on bug tracker limitations, scenario and possible solut…

…ions.
  • Loading branch information...
1 parent f77766f commit 883241ff2463f45bf7654433d6deb7833442f4f6 @cournape cournape committed Feb 27, 2009
Showing with 155 additions and 0 deletions.
  1. +155 −0 doc/neps/newbugtracker.rst
View
@@ -0,0 +1,155 @@
+Some release managers of both numpy and scipy are becoming more and more
+disatisfied with the current development workflow, in particular for bug
+tracking. This document is a tentative to explain some problematic scenario,
+current trac limitations, and what can be done about it.
+
+Scenario
+========
+
+new release
+-----------
+
+The workflow for a release is roughly as follows:
+
+ * find all known regressions from last release, and fix them
+
+ * get an idea of all bugs reported since last release
+
+ * triage bugs in regressions/blocker issues/etc..., and assign them in
+ the according roadmap, subpackage and maintainers
+
+ * pinging subpackage maintainers
+
+Most of those tasks are quite inefficient in the current trac as used on scipy:
+
+ * it is hard to keep track of issues. In particular, everytime one goes
+ to trac, we don't really know what's new from what's not. If you
+ think of issues as emails, the current situation would be like not
+ having read/unread feature.
+
+ * Batch handling of issues: changing characteristics of several issues
+ at the same time is difficult, because the only available UI is
+ web-based. Command-line based UI are much more efficient for this
+ kind of scenario
+
+More generally, making useful reports is very awkward with the currently
+deployed trac. Trac 0.11 may solve of those problems, but it has to be much
+better than the actually deployed version on scipy website. Finding issues with
+patches, old patches, etc... and making reports has to be much more streamlined
+that it is now.
+
+subcomponent maintainer
+-----------------------
+
+Say you are the maintainer of scipy.foo, then you are mostly interested in
+getting bugs concerning scipy.foo only. But it should be easy for the general
+team to follow your work - it should also be easy for casual users (e.g. not
+developers) to follow some new features development pace.
+
+Review, newcoming code
+----------------------
+
+The goal is simple: make the bar as low as possible, and make sure people know
+what to do at every step to contribute to numpy or scipy:
+
+ * Right now, patches languish for too long in trac. Of course, lack of
+ time is one big reason; but the process of following new contributes
+ could be made much simpler
+
+ * It should be possible to be pinged only for reviews one a subset of
+ numpy/scipy.
+
+ * It should be possible for people interested in the patches to follow
+ its progression. Comments, but also 'mini' timelines could be useful,
+ particularly for massive issues (massive from a coding POV).
+
+Current trac limitation
+=======================
+
+Note: by trac, we mean the currently deployed one. Some more recent versions
+may solve some of the issues.
+
+ * Multi-project support: we have three trac instances, one for scipy,
+ one for numpy, one for scikits. Creating accounts, maintaining and
+ updating each of them is a maintainance burden. Nobody likes to do
+ this kind of work, so anything which can reduce the burden is a plus.
+ Also, it happens quite frequently that a bug against numpy is filled
+ on scipy trac and vice and versa. You have to handle this manually,
+ currently.
+
+ * Clients not based on the web-ui. This can be made through the xmlrpc
+ plugin + some clients. In particular, something like
+ http://tracexplorer.devjavu.com/ can be interesting for people who
+ like IDE. At least one person expressed his desire to have as much
+ integration as possible with Eclipse.
+
+ * Powerful queries: it should be possible to quickly find issues
+ between two releases, the new issues from a given date, issues with
+ patch, issues waiting for reviews, etc... The issues data have to be
+ customizable, because most bug-tracker do not support things like
+ review, etc... so we need to handle this ourselves (through tags,
+ etc...)
+
+ * Marking issues as read/unread. It should also be possible for any
+ user to 'mask' issues to ignore them.
+
+ * ticket dependency. This is quite helpful in my experience for big
+ features which can be split into several issues. Roadmap can only be
+ created by trac admin, and they are kind of heavy-weight.
+
+Possible candidates
+===================
+
+Updated trac + plugins
+----------------------
+
+Pros:
+
+ * Same system
+
+ * In python, so we can hack it if we want
+
+Cons:
+
+ * Trac is aimed at being basic, and extended with plugins. But most
+ plugins are broken, or not up to date. The information on which
+ plugins are mature is not easily available.
+
+ * At least the scipy.org trac was slow, and needed to be restarted
+ constantly. This is simply not acceptable.
+
+Redmine
+-------
+
+Pros:
+
+ * Support most features (except xmlrpc ?). Multi-project, etc...
+
+ * (subjective): I (cdavid) find the out-of-the-box experience with
+ redmine much more enjoyable. More informations are available easily,
+ less clicks, more streamlined. See
+ http://www.redmine.org/wiki/redmine/TheyAreUsingRedmine for examples
+
+ * Conversion scripts from trac (no experience with it yet for numpy/scipy).
+
+ * Community seems friendly and gets a lof of features done
+
+Cons:
+
+ * new system, less mature ?
+
+ * in Ruby: since we are a python project, most of dev are familiar with
+ python.
+
+ * Wiki integration, etc... ?
+
+Unknown:
+
+ * xmlrpc API
+ * performances
+ * maintenance cost
+
+Roundup
+-------
+
+TODO

0 comments on commit 883241f

Please sign in to comment.