Awesome work, Bob!
I agree with all of your Trac settings except one. I suggest that you
have more than one setting for the components, that would initially
include:
- Webmail
- Address Book
- Skins
- Other (settings, etc.)
We can expand to include more as we need (plugins, notes, etc.).
What do you think?
On 10/11/05, B. Johannessen <bob(a)db.org> wrote:
> Time for a progress report on the Trac installation. After many, *many*
> hours, I've finally reached an agreement with Python. The agreement
> basically boils down to this; Python will put up with being installed in
> /usr/local/python (instead of in /usr or /usr/local), and I will put up
> with having to hack every Python "extension" in the known universe to
> get it to work. In practice this means everything will take about 10
> times as long, at least in the beginning. The only reason I haven't
> taken both Trac and Python out back and shot then both in the neck, is
> that certain people whose opinion i respect claims Python is actually an
> excellent idea.
>
> But, at the end of the day (or more precisely at the end of two days),
> I've succeeded. Trac and Python, and their combined cluster of
> dependencies finally fell into place. We now have a working Trac
> installation!
>
> This means it's time for me to start asking some questions. The ticket
> tracking system has a few settings we need to agree upon before we start
> using it. I'll present the issues in question, along with my suggested
> answers, and let you all battle it out for a few days before we make a
> final decision. I'll give Thomas final say, and assume he speaks on
> behalf of the current active developers.
>
> * Type:
> When you create a ticket, you also select a ticket type. The default
> list of available types include the following: 'defect', 'enhancement'
> and 'task'. My suggestion is that we substitute these 3 with the
> following 2: 'Bug' and 'Feature Request'. My motivation for both
> reducing and renaming is simplicity. When a first-time Trac user submits
> her first ticket, lets make sure it's as simple and self explanatory as
> can be.
>
> * Priority:
> A ticket is assigned a priority. The default Trac installation is set up
> with a total of 5 priorities; 'blocker', 'critical', 'major', 'minor'
> and 'trivial'. I suggest we reduce and rename to: 'High', 'Medium' and
> 'Low', for the reasons listed above.
>
> * Component:
> As far as I can tell, the RoundCube project only has one component so
> far. I suggest we name this 'RoundCube Core'.
>
> * Milestone:
> At what milestone is this bug fix or feature supposed to be available.
> To keep things simple in the beginning I suggest we define the following
> milestones: '0.1-beta', '0.1-final', '0.2-alpha' and '0.2-beta'. More
> milestones will of course be added later. If we agree to start with this
> list, I'll need a guesstimate from Thomas on when they'll be released.
>
> * Version:
> The version of RoundCube that this ticket pertains to. I see no point in
> adding any older versions to the system, so I think this list should
> initially include only 'v0.1-20051007'.
>
> The important thing to remember about the above lists is that non of
> this will be carved in stone. We'll surely make additions and
> alterations as we go. The goal here is just to make sure we start with
> some sane defaults.
>
> Then there's the question of the design. The current design looks
> fantastic, but doesn't lend itself easily to some of the thinks we'll be
> publishing. My suggestion is to just go live with the default design of
> Trac, a slightly modified design on the mailing list archive, and the
> main RoundCube site just like it looks today. Then, once everything is
> up and running I'll ask for some design help on the mailing list.
>
> Last, but not least; the question of CVS to SVN migration. It's a lot
> easier for me just to fetch the latest source from SourceForge CVS and
> import this into Subversion. If we want to import all the history as
> well, someone with a bit more CVS-foo then me will have to help me get
> my hands on a repository tar-ball. This is once again a decision for the
> developers. Is it acceptable to leave all the old history in SourceForge
> CVS? At the end of the day, I'll leave this decision to Thomas.
>
> I think that's about it for tonight.
>
>
> Bob
>
>
>