[crossfire] CVS branches

[Mark Wedel]

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.