1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
.. _NEP06:
===================================================
NEP 6 — Replacing Trac with a different bug tracker
===================================================
:Author: David Cournapeau, Stefan van der Walt
:Status: Deferred
Some release managers of both numpy and scipy are becoming more and more
dissatisfied 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, every time 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 maintenance 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 information is 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
|
