[SVN] Lighthouse setup for bundles?

[Luke Daley]

On 02/05/2008, at 10:54 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.

I agree with all of that. One appealing quality of Jira is that it  
can be cut back to bare essentials. I have no doubt we could  
configure it to be extremely easy for end users to use, and it's  
extensive API means we could have bug reporting from within TM, just  
like Lighthouse.

If we can make it work, I think crucible is the real win here though.  
It would basically formalise a lot of the existing processes that  
Infin goes through with new stuff, but make it much more trackable.  
And of course tieing in the problem (ticket) with the patch evolution  
(crucible review) and the actual commit and being able to see all of  
that from the ticket in Jira is pretty appealing to me at least.

But for sure, that could be overkill for most if we don't get it right.

LD.