bsag, [EMAIL PROTECTED] wrote on 2008/06/14 21:03: > OK, I should probably explain my thinking about this. > 1. As Tracks has grown a truly wonderful community, I've felt a > responsibility to make sure that all of the resources are in the hands > of the community, rather than in mine alone. That way, if I > disappeared without warning one day, other people could pick up the > reins and it would carry on as before. Not that I'm planning on > disappearing, but you never know when you might be squashed by a > bus ;-). That was part of the motivation for moving to GitHub: it's > hosted by a third party, but also, the distributed nature of git means > that everyone who forks or clones the repository has a copy of the > entire repository and its history. So everyone holds the source and > the history of the project, unlike checking out a subversion > repository. So it was the hosted nature of Lighthouse that appealed to > me, even though it is closed. >
Though it's _possible_ to set up shared hosting for an OSS group, with the core team having server passwords (been there, done that) it's also generally a PITA: #1 sounds persuasive to me... > 2. I have gradually diminishing amounts of time to commit to Tracks, > as will have been clear from my infrequent svn commits, and the > decreasing rate of posting on my blog. Trac is a bit of a beast to > administer, and I'd much rather spend my limited time actually writing > code for Tracks rather than up to my elbows in trac-admin. I just want > something that works, rather than having to spend a lot of time > hacking something else or doing admin. > ... as does #2 > 3. I want to make the barriers to contributing to Tracks much lower. > Again, that was behind the wish to move to GitHub, because forking, > merging and patching is so easy. Well, I think that's probably more to do with Git, and would apply to a self-hosted git repo, rubyforge git, gitorious etc. The advantage of GitHub is that it's great for the "community" tools. > After I got loads of Trac spam and > had to lock things down a bit, I have to manually add named accounts > (which is a real chore), so it is restricted to frequent contributors > and committers (same with svn commit permissions). Everyone else has > to submit tickets as 'guest', which is awkward and doesn't let people > take ownership of their own tickets. Lighthouse would allow that, as > well as giving other convenient ways of interacting with tickets (by > email, for e.g.). And it interfaces nicely with GitHub > And Lighthouse has buzz -- and that may result in greater exposure amongst Rails devs than if you used gitorious+ditz or some other combo. Sometimes :technically_best != :best ... > Having said all that, I'm in no way set on using Lighthouse at all > costs, particularly if people in the community have reservations. If > no-one is objecting to GitHub, I'll go ahead and move the repository, > but leave moving from Trac for now. I'll look into Retrospectiva, > Redmine and even ditz :-) and see if that would ease the admin burden > and make it easier for people to create tickets. > > cheers, > bsag > > Great. FYI: $ ditz add Title: Select a ticketing tool Description (ctrl-d, ., or /stop to stop, /edit to edit, /reset to reset): > Look at Retrospectiva, RedMine, Lighthouse, ditz, todotxt. > Criteria: simplicity for day-to-day use, minimal admin, basic reporting, OSS status, avoid vendor lock-in. > . Is this a (b)ugfix, a (f)eature, or a (t)ask? t Assign to a release now? (y/n): n Issue creator (enter for "Thomas Nichols <[EMAIL PROTECTED]>"): Comments (ctrl-d, ., or /stop to stop, /edit to edit, /reset to reset): > Retro and RedMine do basically the same thing, retro seems rather lighter weight; ditz is **much** easier for developers to keep up to date (cmdline driven). ToDoTxt (on googlecode) is fun too :-) > Does Lighthouse allow export of all tickets? > . Added issue elk-3. You may have to inform your SCM that the following files have been added: bugs/issue-d37c24fb575218d39c53b0f13b7ea9666f02261a.yaml $ git add bugs $ git commit -m "New bug" So apart from the (optional) HTML reporting, ditz needs no extra admin -- it's just bugs/*.yaml in git. Happy hunting! -- Thomas. _______________________________________________ Tracks-discuss mailing list [email protected] http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
