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.