Replying to the list, as this might be of general interest.
Daniel A. Steffen wrote:
> The Trac setup looks great, thanks for working on that, I see you have
> added the code review module we talked about, I think that makes it
> equivalent to my fisheye+crucible setup, so I withdraw my suggestion
> that we use that for the core-related projects, and suggest instead that
> we recommend to the students of those projects to use your Trac (just to
> have everything in one place as much as possible to ease mentoring
>> Also, in case you want direct access to the svn repositories, just say
> yes please, I will definitely want to be able to track the code and
> build it on an ongoing basis.
A few words about this svn/trac setup at dev.lrem.net, that I'm willing
to give to Tcl GSoC:
- Each student gets his own svn repository and his own trac environment,
he's the TRAC_ADMIN and so on.
- The repository can be readable for annonymous users via svnserve (at a
nonstandard port), for commit rights I prefer svn+ssh setup (best with
key based authentication), trac is run with tracd (so don't ask me for
.htaccess or other weirdnesses).
- Everyone's free to register and get TICKET_CREATE and TICKET_APPEND
permissions (which basically gives him the power to give student more
work and comment on previous tickets).
- Mentors get WIKI_CREATE, WIKI_MODIFY, CODE_REVIEW_MGR, TICKET_CHGPROP,
REPORT_CREATE, REPORT_MODIFY, REPORT_DELETE (that's a lot of power,
scream if I missed something).
- It's free to the student to alter any of the permissions (and to tell
me which people should have commit rights on the repo).
- All of this is physically kept in a rack down at my ISP server room,
where I'm the admin (the boss has nothing against this), with hardware
raid mirroring and lots of UPS. Still, bear in mind that it's yours
responsibility to keep a backup of every bit that you want to preserve!
> In terms of general procedure during the summer, I think it would be a
> good idea to have a weekly written status report, delivered e.g. every
> Monday at lunch, maybe on the Trac wiki, or via email. This does not
> need to be very long, just a few lines detailing what has been done in
> the past week, what plans didn't work out, and what the goals are for
> the upcoming week. This will help everyone involved to stay focused on
> where the project is at and where it is going.
And few words about suggested trac usage:
- At least from my experience, the best workflow is:
1) Create ticket just when something looking like a worthy task pops
out. This way you never forget anything that should be done.
2) Optionally accept the ticket to show that you started working on it.
Or just set it to wontfix and forget right away ;)
3) Resolve just when you think you're finished with it. You can always
reopen if it turns out you were wrong.
- This gives you these cool progress bars for a quick overview of how
far you're with each milestone.
- Furthermore, this brings down the weekly reports to copy-pasting an
auto-generated report and adding occasional few words of explanation.
- Trac is flexible, you can probably think of much more cool usages.
Remember, that there's the central RSS with which you can syndicate all
progress of the project within one click.
I've copy-pasted a few lines from an email from Daniel A. Steffen to
quickly demonstrate how things look like. The tickets:
As you can see, I've theoretically started reading the docs. And now
it's time to get back to that tomorrow mid-term :/