On Thu, Nov 03, 2005 at 08:38:33AM +0000, IvorW wrote:
Observing a dialogue between hex and Dom yesterday on
set me thinking.
For those who don't do IRC, "hex" is me.
I agree with Dominic that changes to 0.50 have been
coming in too fast
and furious to manage them effectively.
Seeing as 99% of everything in 0.48 and onwards was added by me*, it seems
appropriate that I should respond to this mail.
* Many of which were not my ideas. I've had a lot of comments and
suggestions from Jo, Ivor and others; I try to get everyone to file things
in RT (see point 5, below) so I can report on progress.
2. The trunk is for releases. Don't check things
in here unless they are
ready for release. In fact, Dom or whoever is release managing, should
be the only one touching the trunk.
I don't check things into the trunk unless all tests pass and I consider
them ready for release - I.E., after consequent checking by the release
Talking of checkins, there is a mailing list for commits. (You people didn't
know? It's been listed on the Subversion page of the dev wiki for a long
time. [You /do/ read the dev wiki, right?] Look, here:
If you are interested in this project, please subscribe to this mailing
list, unless you have a local.)
4. Create separate branches for each chunk of work.
The RT ticket number
provides a good central reference point for this.
This seems like overkill for a small project like ours, unless it's
something major like renaming "Categories" to "Tags" (as I've
before is planned).
5. Post comments to RT indicating progress on each
change. Every change
should be tied back to an RT number.
I try to keep RT updated when I'm responding to tickets. I haven't been
mentioning RT numbers in svn change comments; I'll do that in future.
("RT? What is this RT?" People, we have a bug-tracking system. Add it to
your bookmarks. Read it. Use it. Otherwise it's precisely useless.
6. Changes need tests. I've been as guilty as
anyone for negleting this.
Each RT branch should include either new tests or modifications to
existing tests that would fail if run before applying the change.
It's true, I should write more tests. I'm not good at tests.
7. Changes need airing.
I will posting a separate mail to this list in a moment regarding 0.51.
We need more beta sites for this.
My code is generally running at http://openguides.org/testing/
On a different note, Dom said on IRC:
I think we really need to get some decent layout/CSS
folded back into the
distribution. There's a lot of good design work going on (plus things
like adding inline google maps) but it's not generally available.
Please, please, please!