[check] mid-term development plan + branch mess

Although we'll have to discuss that at our meeting next week (reminder: 
we have a meeting next week), I'm seriously planning to move on quickly 
with check version 0.6.5, by moving the target for the remaining bugs 
if necessary. The rationale for that being that the usability 
improvements justify the new beta, not to mention obviously that the 
actual release is overdue.

It is probably a good time to think of our release cycles (won't 
anybody think of the release cycles!), and I think one key to success 
in this area will be how and whether we manage to clean up the 
HEAD/branch mess.

Don't misunderstand my position though, I still think some branching 
was not such a bad idea, but the fact that 0.6 was *not* done after 
0.6.1 and that there was very little work on 0.7 for a long time made 
the HEAD rot while all work was made in the 0.6branch. Bad luck 
happens, but we must do better next time.

My requirements for any solution would be:
- The ability to commit unstable code without fear
- The ability to do some researchy code (modularization)
- The ability for people to download, install, test, have fun with the 
Markup validator
- The ability for people to install a stable, working version of the 
Markup validator
- The ability to do a very quick fix to the :80 (e.g broken links) 
without it being too big a burden

Thinking ahead, I don't think we'll have resource swarming toward us in 
the near future. IOW, developing a new modular codebase and fixing all 
the bugs in the monolithic one does not seem too reasonable. Thus we 
may have to decide between ditching all hopes of a new, clean 
generation in order to fix all the bugs in our current service, OR 
leave the service as is (reasonably - ahem - stable and bug-free) and 
develop a new generation.

Depending on which path we choose, I can see a few possibilities for 
our management of CVS:
1 - stay as things currently are
2 - invert... HEAD would be the current work (synced with 0.6branch - 
can we do that, technically? - or removing the 0.6 branch) and advanced 
development would be done in a specific branch
3 - no more branches.
4 - two branches, stable and unstable

My opinion is still fluctuating, and I'd like to discuss this seriously 
with all of you. So far I think we have reached the limits of our 
monolithic+openSP design, and tweaking it to death to fix XML related 
bugs may just take more effort than re-starting with a multi-parser 
design. I would then favour option 2, or option 1 (2 being more 
friendly to semi-clueless people wanting to get something slightly more 
*cutting edge* than the tarball).

[YOUR THOUGHTS HERE]
-- 
olivier