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"

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

> 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.

Reply via email to