[SVN] Lighthouse setup for bundles?

[Thomas Aylott - subtleGradient]

On Apr 30, 2008, at 7:45 PM, Luke Daley wrote:
> 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.

That sounds extremely interesting, but I worry that it's overkill.
I find that the simplicity of Lighthouse and GitHib, among others,  
tends to get people contributing that might otherwise never bother  
with it.

Jira sounds extremely powerful and awesome, but since most bundles are  
so simple it might just be more trouble than it's worth.

It's not like we're working on a massive Java app with a million lines  
of code. Bundles are usually just collections of very short scripts.  
Plus the language syntax of course, which can get rather complex.

I would like to find a solution that everyone is happy with. It might  
be annoying to have some bundles under Lighthouse, some under Jira and  
some under Trac, etc...

This was one of my original purposes of creating BundleForge.com. To  
have a single source for reporting bugs for every bundle out there.
I guess I could still do that, even if they are managed by entirely  
different bug trackers. Just having links to each bug tracker project  
under the bundle name somewhere might be good enough.

Lighthouse does have a pretty good API, so we could link that into  
TextMate with a bugreporting bundle or something.

I just know if it's complex or takes too much time to learn or  
configure or non-cute or whatever, hardly anyone will actually use it.