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.
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/mailman/listinfo/textmate-dev
