tchize wrote:
Joining thread a bit late, trolling a bit perhaps :)
I personnaly would enjoy a branch policy on crossfire cvs (whatever it is, a
bad decision is always better than no decision).
I don't think we need branching at each release (unless we
want to keep a few weeks after release a bugfixing branch while
devels can develop addons in main branch).
I think the rule on this is that branching at release time will only be done
if there is some fix that needs to go in for the release but the latest version
of that file can not be used.
For example, at time of release candidate, player.c is 1.20
a few days later, someone commits some changes (new features) that result in
player.c be 1.21
A bug is discovered and fixed in 1.22. That fix is desired for release, so a
branch from 1.20 is done with that bug fix.
So in general, I'd expect branches to be uncommon.
But perhaps, we need more of a release and development policy. I may be the
only one to think this, but isn't developpement here a bit too democratic
(without much obligation, other than discussing big changes in ML). Coders
put add-ons they like and which meet some players need. This is great. But
maybe, to have a good release policy, devels should make once a year or alike
their 'development plan' (what and when add-ons could be done) and submit it.
Then a few reviewer amonst us would analyze all given plan and provide a
yearly timeline on when we will release and what should be in for each
release.
that could be convenient. But as said before, given a volunteer effort, it is
always hard to drive those things.
People probably have enough deadlines to keep at work and school, and don't
really want one for something they do for 'fun'.
It's also hard to get volunteer people to do something they don't want to do.
So while statements like 'code xyz need to be cleaned up', can be hard to
convince someone to do that.
That said, certainly deciding release schedule based a expected features makes
sense. If nothing but a few bugfixes, might not be a reason to do a release.
the problem is that can then lead into the current case - long time between
releases because it is hard to discern when there are enough notable changes to
warrant a release.
that said, doing a release tonight, one thing I found is that aspects of the
make dist were broken - more frequent releases should probably keep that more up
to date (or at least not as many broken pieces)
Currently, If we go on quarterly releases, i have no idea what is forseen to
be on following release! And am sure am not the only one. Lots of other open
source projects have a clear idea of what is to be done for when. Even if the
delays are not to be followed strictly (some project releases years after
forseen date :) ) this give a clear view to users and also to developers.
I think it would certainly be nicer to have a clearer idea of what people are
working on and when they expect to complete it. If nothing else, it provides
some visibility of what everyone is doing - maybe a wiki someplace? Or maybe
something like Leaf maintains for the maps?
Only actual projects/features need to be tracked - if your fixing bugs, don't
need to document that - if your writing hundreds of lines of new code, that
should probably be tracked.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
