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
B. Johannessen 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!
Nice to hear. Thanks so far!
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.
Agree with 'Bug' and 'Feature Request'. We could also think about using tickets for support later on. But for now, the mailing list and the Wiki should be good for support requests.
- 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.
Actually, I like the default selection.
- Component:
As far as I can tell, the RoundCube project only has one component so far. I suggest we name this 'RoundCube Core'.
I would add 'Skins', 'Webmail', 'Address Book, and 'Plugins' (as suggested by Praneet)
- 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.
Good suggestions. Not shure about the release date for those milestones but we'll see.
- 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'.
Agree.
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.
No problem. If we can at least add the Logo, it would be OK to start with. I know one screen designer who would probably take care of this.
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 guess we can get help from Slaanesh or better known as Olivier to migrate from CVS to SVN. If not, development will go on without the history (which is not very comprehensive, to be honest)
I think that's about it for tonight.
Bob
Again, thanks a lot for your effort to set it up!
Thomas
Le Mardi 11 Octobre 2005 23:48, thomas bruederli a écrit :
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 guess we can get help from Slaanesh or better known as Olivier to migrate from CVS to SVN. If not, development will go on without the history (which is not very comprehensive, to be honest)
Again no problem for the migration as far as we get the rcs files. Then it will be very easy.
Olivier
-
B. Johannessen -
Slaanesh -
thomas bruederli