Re: [glob2-devel] Hello, I'm back, and lots of comments....

[Stéphane Magnenat]

Hello,

Some remarks,

> --------------------------------------------------------------------
>  Alpha 22 and further
> --------------------------------------------------------------------
> The way I see it, Alpha 22 is about as far as you can go without rewriting
> major portions of the game. For this reason, I suggest we name the new
> development 0.9.0. This version would incorporate major rewrites and could
> take several months to make. Because of this, 3 things must happen.

I do not agree, there is still room for improvements based on 0.8.22. For 
instance, we could fix the bugs, do more graphics and usability improvements. 
Of course, at some point we will have to do more radical changes, but it 
would be nice to have a stable release lying around when doing this.

> First, we must leave CVS and Wiki development theme. CVS is very limited.
> Extremely so. It no longer serves Globulation justice. For this reason, I
> have signed up for a free TRAC and SVN hosting. Subversion offers many
> options that CVS does not, is easier to use IMO, and the TRAC system will
> allow us to separate the Wiki from the Development by moving the pages
> relating to Glob2 to this new TRAC system. The system (located at
> http://globulation2.devjavu.com/) is all set to go. You should be able to
> sign up (and after some activation) be able to change pages, submit code,
> and viola. I wont take no for an answer.
>
> Secondly, the old CVS will cease being used, except for issuing minor
> patches to the current 0.8.22 and releasing old bug fix versions. No major
> code rewrites are to be done on the old CVS, only the new SVN.
>
> Lastly, the bug tracker should be elimination. TRAC offers a new system
> (ticket based) that will provide more integration. So all bugs in the
> current Savannah tracker must be fixed, closed, or marked as no longer
> valid. When this is empty, we simply do not touch Savannah anymore (except
> for this mailing list).
>
> So, what to do now:
> * Submit any final work to CVS (do not start anything new)
> * Fix all bugs on the bug tracker, and empty it (if a bug is old, close it
> as not fixed)
> * When done (bugs must be fixed), export CVS, remove all .cvs folders, and
> import into the new TRAC system
> * Transfer development pages from the old wiki to the new TRAC system
> * Begin working on 0.9.0 using the new TRAC system
>
> Should be easy enough. I'd do the last 3 now myself but there may be work
> atm someone is doing and lots of bugs. So get those done first.
>
> Result:
> * Old CVS server with stable code used for minor bug fixes
> * New TRAC system with development code (major rewrites)
> * Separated development documentation from community documentation
>
> All things well, TRAC could be used in 3 days. So lets get working. Submit
> those patches now ;) Any questions?

- If we do a radical switch, why subversion and not something more 
distributed ? I know it is always the same questions, but while better, 
subversion does not fundamentally solve cvs's problems.
- Why changing the wiki as the acutal one works fine and already took some 
time to theme and organise? Can we do this sort af theming with TRAC ? A nice 
website is important for a game imho.
- In which aspect the integration is better than now? Is it because of a 
single username/password?
- In your transfer suggestion, we would loose all cvs history?

Sorry for being conservative, and I'm not fundamentally against changing our 
infrastructure ; but I think we should have a clear idea of what it implies 
and I'm not ready to happily switch form something that works to something 
that might be better but is missing 50% of actual features. Furthermore, we 
are lacking workforce and I think it is better spent hunting bugs than moving 
wikis.

> --------------------------------------------------------------------
> Release schedule
> --------------------------------------------------------------------
> I love the wiki's release schedule. Once every 3 months, and then on big
> fix no more than 1 week after a version release. This means a stable, more
> enjoyable experience, than waiting for months to fix the bugs. I think we
> should adopt such a release schedule come 0.9.0. This type of thing should
> increase players, and perhaps draw new developers.

Holding a release schedule for a project like glob2 with people having 
external constraints such as school or work is a bit of an illusion, but you 
are right in the sense we should release more often with release candidates.

> --------------------------------------------------------------------
> New code
> --------------------------------------------------------------------
> Once we have successfully migrated to the new TRAC system, documentation on
> new features (like Bradley's new engine system) should be made using the
> trac wiki. The details should be well worked out before even starting to
> code it, else you'll find half way through, that you missed something, and
> you'll use a patch instead of rewriting it again. So every detail of files
> and code should be in TRAC. Once a system is worked out, then more than one
> person can help make it (speeding up development), as apposed to one person
> who only knows what they are doing.

A system focusing too much on enforcing documentation before writing code is 
bad because lot's of geeks (including myself) think in real time the details 
of the implementation (although we have a general idea before). For 
documentation, I think doygen is fine. A script regenerating doxygen each day 
from HEAD would be great. We can also add additional pages to doxygen 
explaining the design. We should use it more.

> --------------------------------------------------------------------
> Windows Packages
> --------------------------------------------------------------------
> Yes, now that I'm back I'll probably help with the Windows packages again
> (once I remember login details for things). However, I've lost the script
> so I'll have to write it all over again. Not to worry. I will get done
> eventually.
>
>
> Right, thats about all the comments I have for now. Please, please adopt
> SVN and Trac. It will work!!!

Please please try to convince us with factual arguments not trust. Trust is a 
bad project managment oracle.

Sorry to be so negative in my answer, but in general I tend to misstrust 
solutions than want to solve problems by reorganisation when the problem is 
lack of raw work force. And also I think there is really something to improve 
with cvs, I don't think svn will this much.

But of course, that's my opinion and I'm not the maintainer.

Steph

-- 
http://nct.ysagoon.com