Hi Curt et al., Well, I guess that most has been said already, but let me weight in with just a few additional points. I also believe that it is time to move the repositories over to a higher capacity and professionally maintained infra structure. My experiences with google code are generally very positive, so I have no objection there. My impression is that the majority of developers prefer git over SVN, so I believe that that should be the control system of choice.
Currently, the base package is growing rapidly, and I believe that for the next release, we should make an effort to bring it back to a size as small as possible. Moving the base package repository over to a new server might be the most excellent opportunity to split it into several smaller (optional packages). FWIW, I would prefer to provide only 1 aircraft (the cessna), and no AI stuff with the base package. That would bring the download size down considerably. Aircraft could be provided as separate downloads, not only from the website, but preferably also as a separate SVN/GIT checkout. The same would be true for AI. Whatever else should we be able to split off and provide separately.? Finally, regardless of where we migrate to, This is also an excellent opportunity to think about how we provide the infrastructure for new releases and were we put the final download packages. Ideally, releases should be build on the server. During the last versions, that wasn't possible, because I didn't have shell access to the host, resulting in building it at home, and uploading it through a very slow wireless connection, with many problems as a result. if google code were to allow me to do all those things remotely they'd get my vote. Cheers Durk On Wednesday 02 September 2009 17:55:07 Curtis Olson wrote: > Source code control systems are close to religious topics for many people > so I want to avoid potential panic here. I understand that due to the > diversity of opinions within our developer community, it will be impossible > to reach any kind of consensus for any action. Even the default of no > action is controversial. :-) My goal here is to not debate the final > solution, but hopefully find some agreement so we can move a step forward, > and from that new position, we will be in a better position to discuss > future options. > > So to start out, I think most of us agree that CVS is old and clunky and > there are a variety of better options available. > > In addition, I am self hosting our master CVS repository which means that > if my machine breaks, I personally am on the hook to drop everything else > and do whatever it takes (ranging from hardware, to OS, to security, to > whatever ...) to find and fix the problem before we can get our repository > back online. What if I happen to be on vacation or on a work trip or get > hit by the proverbial beer truck and then a problem develops with the > server? To add new developers, I personally need to manually create > accounts, adjust group membership, etc. again if I'm out of town or in the > midst of some crazy work deadline, there could be substantial delays. In > addition, I have a remote backup system in place for our CVS server, but > that is another self managed system and earlier this summer the backup > system failed and all the backup data was completely lost, leaving us with > just a single primary copy of the main repository until I could get the > backup system back up and running again (which it is now.) These are all > things that could be improved on and streamlined. > > >From my perspective, these administrative issues are of equal importance > > to > > discussing which specific version control system we might step to. All of > these things need to be considered together when determining a route > forward. > > What I propose is that we migrate our self hosted CVS repository to > code.google.com and in the process convert to SVN. > > 1. This gives us "professional" management of the servers, regular > professional backups, and an automatec access control system for adding new > developers. Google has a tremendous amount of bandwidth and compute power > behind their systems, way more than I could ever offer on any self hosted > system. When something breaks on a google server, there is a pool of > people available and qualified to fix the problem. On any self hosted > system (no matter how well run) there is usually only one person who could > jump in and fix a potential problem. > > 2. We need to move away from CVS somehow. SVN is a big improvement (but > yes, I realize many of our developers think that going direct to some other > system will be an even bigger improvement.) Let me just offer that this > doesn't have to be the final destination. It may just be a step forward in > our journey. Please, please don't panic! I suspect that building a > gateway between SVN and other systems should be easier and more transparent > than a gateway between CVS and the other system given that SVN has more > capabilities than CVS. > > 3. I have prototyped the migration system with the SimGear repository and I > think it went pretty smoothly. Here is the link: > > http://code.google.com/p/simgear/ > > 4. code.google.com also offers a bug tracking system that we could begin to > use. > > 5. SourceForge offers many of these same things, however, it is awfully > slow. Google seems to be so much leaner and faster to do everything. > After navigating the google site for a while, it's really tough to go back > and try to plow through sourceforge which seems so much slower and clunkier > in comparison. > > I think that when balancing both the administrative and technical aspects > of the issues, code.google.com offers a pretty good step forward and > enables us to cleanly step away from the old CVS-based, self-hosted system, > so that is what I would like to do. > > It would be great if some of our developers could look through the simgear > projects site on code.google.com: > > http://code.google.com/p/simgear/ > > Run through the process of checking out the code. Browse the changes, > browse the repository tree layout, browse the revision history etc. Does > the conversion process look like it worked well? Is everything there? > > The one thing I don't yet have is support for a changelog mailing list, but > I suspect there are easy hooks for setting this up, and in addition, google > provides several RSS feeds for monitoring changes to different aspects of > the project (including source code changes.) > > I think this will be a good step forward for our project. I think once the > transition is complete we'll be in a more solid position to be able to > debate possible further moves forward at that time. I do expect a > diversity of responses to this, but there's nothing wrong with diversity, > right? :-) > > Thanks, > > Curt ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
