FROM Stéphane:
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.
Oh, I didn't mean that. I mean things like improving the network/internet play, and other ideas I've seen floating in the mail list. Many of them have not been able to be done because of massive code rewrites needed. This is where the new system would come into place. A stable Globulation while the development might be broken for months. I'm not saying some maintainer cant add what they can to the CVS, but it would be wise not to (and instead submit to the new rewritten code in a couple of months.
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. Thats exactly that. New featuires in CVS stop, all bugs fixed, then code exported and imported into a new source tracker.
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. SVN is far easier for many developers. Many project, if not all, that I keep track of have moved to SVN. For example BZFlag moved to SVN not more than 1 month ago. They saw the benefits, and so should we.
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. I'm not using trac as the website. We would have the current wiki which would be for releases, and player information like the nmaual. TRAC would simply take out all developing information in thew wiki, to tidy it up, but to also improve organisation. It would be a central place for all developer stuff (and even better than both the wiki and SVN are linked with TRAC) rather than using a rather crammed and outdated wiki for some "proposed changes". By moving to TRAC, these ideas could be worked on further and easily linked to source code changes to show progress.
In which aspect the integration is better than now? Is it because of a
single username/password? That and as noted above, the information will be in one central place, thus improving organisation.
In your transfer suggestion, we would loose all cvs history?
Yes and No. CVS would still be used for all 0.8.x bug fixes made and the history there would still be availble. For example, it could go as high as 0.8.50 in three years time, but it would only be bug fixes (creating a stable version) until 0.9.0 is finished and thus ready for lots of testing and bug fixing to get that stable. So CVS wouldn't vanish or be dorment, but it woulnd't be the primary source tracker anymore. The import to SVN would loose the histroy, but import will only be done when currently developing features are finished and bug fixes are made. So loosing the history on a semi stable release shouldn't be a major downfall, consdiering when its imported, most stuff will break from development anyway.
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. Well, thats the point. I'm doing all the wiki moving. I'm doing all the setting up. I'll even do the SVN import and have it ready for people to start developing. The only work on you part will be fixing the bugs in the tracker (clear all of them) and telling me when the release is done (no more major new features will be added, mostly bug fixes) so I can export CVS, remove .cvs and import it into
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. Well, the idea of nightly source tarballs would work well here instead then. That way people can download each night (if they can't get into CVS/SVN) and see if bugs are fixed. That way no work from people would be needed to release the source for testing. Result: More bug reports, stabler product each day.
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. I havn't heard of Doxygen, but if it has anything to do with documenting inside code, then that would be a great idea, That along with the tarbals would keep everyone up to date. No problems (and provided someone has a linux computer online 24/7, it should be easy to run a cron script at midnight which makes the tarballs and updates doxygen).
Please please try to convince us with factual arguments not trust. Trust
is a bad project managment oracle. Well, hopefully the comments above have helped convince you even one ounce.
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. I agree, changing from CVS to SVN alone isn't helpful. But when combined with an in built bug tracker and wiki, the system is perfect for developers. They can keep everything 0.9.0 related in one simple to navigate place and not have to rely apon a seperate bug trackler, seperate wiki, and seperate source tracker.
But of course, that's my opinion and I'm not the maintainer.
Oh, you are no longer the maintainer? That I hadn't read about yet. Did someone like Kyle or Bradley take over? FROM Kai:
We already can have subversion on savannah, but it is in beta status. And
I don't trust nondistributed source code managemant system in beta status. When something goes wrong in distributed system every one still got correct repositories. With svn we're lost. DevjaVu is beta too. I don't know how long it will stay alive. I have hosted a project with DevjaVu for almost 4 months now and not once have a gone there to find the site down. Its been pretty good. Besides, if you are worried, when you commit, don't delete off your computer (that way, if it goes down and you want to switch, which I'm hoping will never happen, its a good service) you just commit to the old CVS system (which IMO would be a bad idea, but hey, we got to keep development alive :P) and work from there.
I'm very confident with our wiki. Why should we dumb it, even if we would
start to use devjavu? Again, the TRAC is for dev stuff. Everything else remains with mediawiki.
As I understand, we need cygwin or mingw to install glob2 on windows. In
this case we should use git, which is already available on savannah as well and is distributed (so no risks of loosing something, and much more advantages concidering merging, branching and convenience). Also it has less dependency. Beside being better than svn, it has the feature of one-to-one convertability with mercurial and darcs supports (local) git repositories. So you are against moving to TRAC/SVN? Remember the point of moving to SVN was also for the documentation and organization of all developing information in one central place. CVS or Git on Savannah provide no such service. Keep thinking about it. I've started moving wiki pages over to TRAC (which atm are incompatible, but I WILL fix within 2-3 days if all things go well) and blanking the old ones. Dont worry, I've kept revisions, so if it doesn't work out, I'll just go back to the old copies. It should be ready for use in less than a week. -- Kieran.P http://qlwiki.linuxsolutions.co.nz/
_______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
