[SVN] Lighthouse setup for bundles?

[Luke Daley]

On 01/05/2008, at 12:53 AM, Thomas Aylott - subtleGradient wrote:

> The Lighthouse[1] bug tracker just upgraded to 2.0 and is now free  
> for open source projects.
>
> I'm planning on using it for all my projects soon, but wondered  
> about how the project setup should be.
> Should we do a project for each bundle? Or a single large project  
> that covers all bundles?
>
> If we have a single large project for everything you could use tags  
> to define what bundle you're talking about. But will people  
> actually use tags? And would they actually choose the right project  
> in the first place?
>
> Obviously some bundles like Git and ROR2 bundles aren't very  
> Macromates centric, so they would likely be their own separate  
> project, probly on a completely different domain even.
>
> Let me know what you guys think. I'd like to get something up and  
> running pretty soon.

I have been speaking with Allan about an issue tracking solution. I  
have applied for (on behalf of Macromates) Open Source licenses for  
the following Atlassian products:

FishEye <http://www.atlassian.com/software/fisheye/> : Repository  
Introspection
Crucible <http://www.atlassian.com/software/crucible/> : Code Reviews
Jira <http://www.atlassian.com/software/jira/> : Issue Tracking

Jira is really the meat here. It's quite an impressive tool. The best  
feature being that it's workflow is extremely customisable and I  
don't there is anything we wouldn't be able to get it to do that we  
needed.

The integration here is important to. For example, a user can submit  
a patch into Crucible for review with a Jira ticket number. The two  
are then instantly linked. If the review passes (with our without  
modification), then the patch can be committed with the ticket number.

At this point, the ticket in Jira is linked against the original  
review and all it's meta data (such as modifications and to and fros  
between moderator and author) and the actual changeset in svn  
(courtesy of fisheye). As far as seeing the rational behind a change,  
it doesn't get much better than that.

But, the real complication comes from TM not storing it's data in the  
format that we actually work with it. I don't see how Infin can be  
expected to review patches in xml plist format. I am talking to  
Atlassian about the ability to process the source in both fisheye and  
crucible to allow us to work with the ascii format that we use, I am  
not that hopeful though.

LD.