bfiles bug tracker (was Re: Fog Creek sponsoring students for Mercurial development)

[Greg Ward]

On Mon, Feb 1, 2010 at 5:01 PM, Benjamin Pollack <benjamin at bitquabit.com> wrote:
> In addition to general bug fixes, one of the primary things that we really want both internally and for Kiln are extensions that make Mercurial suitable for projects that involve large binaries.  To that end, a big focus this semester is going to be on exploring Greg Ward's bfiles extension as a possible way to address some of Mercurial's current shortcomings in that area.

...which reminds me, I really need to setup a public bug tracker for
bfiles.  A todo.txt in the source tree can only get you so far.
Problem: I'm not a huge fan of bitbucket's bug tracker.  (The editing
interface is too slow and JavaScript-dependent.)  I rather like
Roundup.

In addition, I would eventually like to see bfiles included with
Mercurial.  I think it's useful enough and seems to be quietly
gathering a user base.  That day is still a ways off, but I think it
should happen eventually.

As I see it, I could:

  1) suck it up and create a bitbucket bug tracker for bfiles
  2) kindly ask whoever has root on mercurial.selenic.com to create a
second Roundup instance with the same user database (is that
possible?) so that anyone who can report bugs in Mercurial can also
report bugs in bfiles, but with independent bug IDs
  3) ask if it's OK to just use Mercurial's own tracker and throw
bfiles bugs in there with Mercurial bugs
  4) setup my own Roundup instance on my own web server

I really don't want #4, for all the obvious reasons (separate user
database, admin overhead for me, security exposure and load for my
poxy little xen server).  #3 is attractive because it's minimal work
and will make sense when/if bfiles is rolled into Mercurial.

Opinions?  I don't want to start a religious war on bug trackers, so
please email me privately and I'll summarize.

Thanks and sorry for the semi-OT post...

Greg