On 2007.08.30, Rick Cobb <[EMAIL PROTECTED]> 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?
You're right, I wasn't very clear about this: None of the existing mechanisms (SourceForge tracker, etc.) are going to be affected. I just wanted to set up Trac and see how well it works. In the future, if Trac proves to be useful, then we can discuss migrating all of our information and assets into it and shutting existing stuff down in favor of it--but I viewed that as the "drastic" change. Right now, I'm just asking folks who are interested in playing with Trac to check it out, and provide some meaningful feedback, with regard to how it might fit in with our project. > 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? Of course, I would love to see this happen! I don't know if I will have the time to do this, and I know that I can't make anyone ELSE do it, so it probably won't get done. If someone wants to step up and volunteer their time to do it, I certainly wouldn't refuse it. The only database that contains issues (that I know of) is the SourceForge tracker. If folks are tracking issues elsewhere, please speak up so we can have a complete list. > 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? I personally feel a wiki is best when it is comprehensive, so I'm in favor of one single wiki. Again, if we all agree that Trac is the best direction moving forward, I would definitely script something that would export out of MediaWiki and into TracWiki. > * What are the new documentation standards, presuming anybody continues > to work on the API wiki entries? I say whoever cares most strongly about the standards should sit down and spend the time to write them up. That is, as you say, if anyone continues to work on them. > 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. And this is the single biggest reason why I (personally) want to use Trac. Once we get all the open issues in there, I can assign them to milestones based on might possibly be reasonable estimates and we can all finally have an idea as to what might be completed by when. Of course, this assumes that there will be anyone left to actually work on and close out tickets and contribute code. > 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?" The reason why I haven't worked on moving things out of CVS (given how slow SourceForge has been lately) is because I want to make sure I can properly preserve the revision history in whatever SCC system I import it into. I personally feel that if the entire revision history isn't preserved, it isn't being "done right." Others may feel it's less important to carry forward that old information, but especially in open source projects that audit trail is important, to know exactly who changed what. > Resource management: > * What bug fixes or features will be missed due to spending time on this > move? Good point--any time spent playing with Trac is time spent not doing something else. If people are going to contribute to the AOLserver project, it means taking time away from other activities and that can be hard to justify. Within the AOLserver project itself, folks working on Trac aren't working on the code. I don't know how I could quantify this. Given the low level of project activity right now, people working on anything project-related might be considered an improvement. Whether people will devote effort to it, taking away from their existing work ... I have no idea. I'm personally willing to put in 5, maybe 10 hours, in the next few days, to work on this. > * What documentation, visibility, or reliability gains are we looking > for from the move? My personal interest is to get all outstanding issues into a system that's easy to maintain, looks nice, makes release management easier, and possibly encourages people to participate more. > 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. Define quick--hours? Days? Weeks? If it takes me more than 10-15 hours to migrate everything into Trac, it's already too much work for me to commit to right now. It has to be something I can do a few hours each night or over a weekend. Is that quick enough for you? With respect to (b), I want everything in a single location, too. > Also, it's a lot better looking than Bugzilla :-). Bugzilla is overkill--too many data points collected for my taste. Rick, thanks for taking the time to assemble this list of questions. Hopefully it'll keep the discussion focused and positive and we can make some progress. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- 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.
