bfiles bug tracker (was Re: Fog Creek sponsoring students for Mercurial development)
david.douard at logilab.fr
Thu Feb 4 10:56:19 CST 2010
Le Tuesday 02 February 2010 01:22:02 Greg Ward, vous avez écrit :
> On Mon, Feb 1, 2010 at 5:01 PM, Benjamin Pollack <benjamin at bitquabit.com>
> > 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
I can propose you to create a dedicated project on our forge
> 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.
I strongly approve. The thing that prevent me from easily use it for some of
my customers is the fact it's not distributed with Mercurial (in fact, with
Steve's TortoiseHG mercurial distribution).
Steve, would it be possible to include it in a future version of TortoiseHG
(even if it is not yet supported by the GUI tools)?
> 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
So to be honnest, #3 is also my favorite :-)
> 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...
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
David Douard LOGILAB, Paris (France), +33 1 45 32 03 12
Formations Python, Zope, Debian : http://www.logilab.fr/formations
Développement logiciel sur mesure : http://www.logilab.fr/services
Informatique scientifique : http://www.logilab.fr/science
More information about the Mercurial-devel