Maybe the first thing to note is that 'trac' is python code running on Apache!
And 'trac' does not appear to be a service provider like sourceforge, all setup, maintenance, upgrade, backup is the responsibility of the user. Use of 'trac' virtually requires subversion, which must run on the same machine as 'trac'. So the whole damn thing is on one machine, does everyone feel comfortable with that? Hell, I'm not too comfortable keeping my own software on my servers and they have mirrored disks and live in a building with 2 weeks of diesel fuel and batteries for power outages. Problem is, recovery from failure would still be painful, I might take a vacation or keel over dead. Btw, I love subversion and hate sourceforge, but I know what I'm getting. Sometimes you can hate the best solution. tcl/tk use sourceforge even with major sponsors, OpenACS seems to be able to coordinate cvs, bugtracking, forums and everything else, and it is built upon AOLserver and Tcl. Maybe support our own instead of moving to python and Apache. tom jackson On Thursday 30 August 2007 23:13, Rick Cobb wrote: > Well, here's my take on it: > > This is a major change. The community should get at least 24 hours to > react before we start seeing implementation notices. And Tom's right; > I'd feel more respected if you'd mentioned _why_ you wanted to do this? > > In terms of an implementation plan, there are a number of questions I'd > ask if this were a project I was trying to be sure was succesful. Since > I'd like it to be successful: > > Bugs/Issues: > * Are all the bugs in the current databases going to be issues in trac? > Which databases will they be culled from? > * Will the history of bug fixes be translated to trac? > > Wiki: > * Will the whole wiki move, or will there be an "information" wiki > (presumably where the current one is) and a "management"/"issue" wiki? > * What belongs in which wiki? > * What are the new documentation standards, presuming anybody continues > to work on the API wiki entries? > > Management: > * We've had no visibility into planned milestones or assignments before. > Are you planning on providing some? That'd be the biggest community > benefit I can see. > > Revision Control: > * Given you've also suggested a move to SVN, similar questions should be > asked: will the revision histories be moved, or just the tip revision? > How much archeology will be required to find out that "Adam Zell > submitted this patch in 2002?" > > Resource management: > * What bug fixes or features will be missed due to spending time on this > move? > * What documentation, visibility, or reliability gains are we looking > for from the move? > > I'm actually in favor of the move if it's (a) quick, and (b) the > 'archeology' questions have answers that don't involve four databases on > four sites. I'm in favor because my examination of trac-based projects > shows more process & milestone visibility than I've seen in this > project, and gaining that visibility is something I know we'd all like. > > Also, it's a lot better looking than Bugzilla :-). > > -- ReC > > > -----Original Message----- > From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On Behalf > Of Dossy Shiobara > Sent: Thursday, August 30, 2007 10:09 PM > To: AOLSERVER@LISTSERV.AOL.COM > Subject: Re: [AOLSERVER] Switching to Trac to manage the AOLserver > project? > > On 2007.08.30, Tom Jackson <[EMAIL PROTECTED]> wrote: > > Not a single word about benefits, pros and cons, what is the point of > > asking about strong feelings? > > Sorry, I assumed that folks were familiar with Trac and those who > weren't would read up on it, as I even provided the URL. > > -- Dossy -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
