Graham Dumpleton wrote:
As Jim pointed out a while back, we need to get going on mod_python 3.3
before I fill up JIRA with another page of bug reports or suggestions.
I think you already *have* filled another page since I made that comment. ;)
That said, how do we want to proceed on this? Do we want to draw up an
initial list of things to do with priorities, discuss them to make sure
all are okay with the fix or what is proposed, possibly assign them to
individuals, and then get started? Or even before that, do we want to
state general aims about what we want to address in mod_python 3.3?
Do we want to focus only on addressing bugs again, or look at some new
features as well?
This is how I would set priorities:
Mark resolved bugs in JIRA as closed, just to clean things up.
Try and assign most of the issues to someone. This is a bit of PR spin,
but I think it looks bad when there are a large number of open issues
with no assignee. To the public it may look like the project is not
being actively maintained.
Fix the easy bugs first so we can backport to 3.2, and be ready for a
bugfix release. This does not include the various importer issues. I'd
say that there are not many things in this category, but we should
review JIRA to be sure.
Refactor the unit tests. If we are going to do this, we should do it
early in the development cycle so we have lots of time to test the test
suite.
Review JIRA and collect related issues.
Improve documentation.
New features.
Grand Unified Import Theory.
The order does not necessarily suggest the importance of the various
issues, and of course we can work in parallel on the last 3 items.
By then I might have got my SVN access sorted out. Have account, but
haven't as yet tried a check out using it.
BTW, I still don't have priviledges in JIRA to administer entries, ie.,
assign etc. Do I need/want that? How do I get that set up?
It's handy to be able to assign, close and resolve issues, so I would
say yes. I bevlieve Grisha can change your priviledges.
Jim
