Observing a dialogue between hex and Dom yesterday on #openguides has set me thinking.
We need to get our house in order. Kake predicted this a year ago, see http://openguides.org/mail/openguides-dev/2004-October/thread.html#575
I agree with Dominic that changes to 0.50 have been coming in too fast and furious to manage them effectively.
Anyway, I have some practical suggestions and ideas:
1. Subversion has a good branching mechanism that works, let's use it!
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.
3. For someone hosting a guide running different software from the latest release, it would be useful if this was in a branch. This would make bug reporting much easier.
4. Create separate branches for each chunk of work. The RT ticket number provides a good central reference point for this.
5. Post comments to RT indicating progress on each change. Every change should be tied back to an RT number.
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.
7. Changes need airing. If you can either present the change on a guide you are hosting (mirrors help here :)), or if you can persuade someone else to patch a guide they are hosting, it would be desirable to expose the change to people in the OG community for rigourous exercising. We need more beta sites for this. I will be hosting such in the near future - watch this space.
8. Even if you don't have commit access to the master OpenGuides repository, you can always run a local repository. In fact, I recommend mirroring the repository even if you do have commit access. svk is your friend here :). clkao++ svk rocks! see http://svk.elixus.org/
These are my thoughts on change management; the list is probably not complete, but enough ideas to make a start.
Ivor.
On Thu, Nov 03, 2005 at 08:38:33AM +0000, IvorW wrote:
Observing a dialogue between hex and Dom yesterday on #openguides has 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.
- 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 manager.
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: http://urchin.earth.li/mailman/listinfo/openguides-commits If you are interested in this project, please subscribe to this mailing list, unless you have a local.)
- 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 mentioned before is planned).
- 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. https://rt.cpan.org/NoAuth/Bugs.html?Dist=OpenGuides )
- 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.
- 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!
-- Earle
On Fri, Nov 04, 2005 at 10:21:30AM +0000, Earle Martin wrote:
If you are interested in this project, please subscribe to this mailing list, unless you have a local.)
Sorry. A local... svn checkout. In which case you are probably aware of changes already (svn log).
openguides-dev@lists.openguides.org
-
Earle Martin -
IvorW