[Nix-dev] An interview to the fossil creator about fossil

[Evgeny Egorochkin]

On Sunday 08 August 2010 11:30:09 Michael Raskin wrote:
> On 08/08/2010 03:22 AM, Evgeny Egorochkin wrote:
> >>> So missing things are: ui for distributed bugtracker, "distributed"
> >>> links between projects, bugs, wikis and commits...
> >> 
> >> Well, it looks like veracity has a bugtracker in it (with actual web UI)
> >> in addition to a VCS.
> > 
> > If this is it, then it's not terribly impressive:
> > http://www.ericsink.com/entries/veracity_early.html
> 
> Let's be honest - neither it is terribly complete. Their field-based
> merge seems quite extensible, though.

To be honest, I didn't really look into but because many items on the linked 
pages triggered my bullshit detector such as:

 * Apache License Version 2.0 and care towards ogranizations which may 
hesitate using standalone gpl apps
 * Cross-Platform C -- again because some org might "hesitate" to use g++ ?
 * Enterprise everywhere

Alternatively, this may be a bunch of excuses to heavily commercialize it... 
this may end up nasty or just fine who knows, since only gpl-like licenses 
force companies to not discriminate users(eg a bugfix  or a new version 
available to one customer is legally availale to everyone else).

> >> Of course, just using parts of fossil is not out
> >> of question. There is a way to use ikiwiki as a bug tracker...
> >> Possibilities are numerous.
> > 
> > ikiwiki makes for a crappy bug tracker, they admit it. We probably want
> > as much metadata explicitly stored as possible.
> > http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/
> 
> Frankly, looking at our JIRA usage (it offers a lot; do we use it
> much?), I start doubting your claims. Maybe tags are enough for us.

It seems to be due to the workflow:
 * everyone works in their private branches and commits only stuff that works
 * issues that pop up are mostly minor and are fixed by responsible people in a 
matter of hours

Essentially, this means that our bug tracker is memory+IRC+ML. If we suddenly 
discover this is doesn't scale(very likely) bug tracker will come handy.

> > Basically it's all about devising a storage format that's dvcs-friendly
> > and making a web interface for it...
> 
> There is no such thing as a format that is dvcs-friendly, because things
> that can be automated with issue tracking merge are not expressible in
> the DVCS terms. I don't know, when merging two forks of the same issue,
> severity can be assumed to be maximum of two branches.

Not at all: somone files a high-priority bug, you fork, someone changes the 
priority in master to low, you merge

But you do have a point that it would be advantageous to have structured data 
and different merge strategies for different data types and file types...

> Veracity is going two support this with template merge - and parts of it
> are currently implemented there. Maybe adding more fields and hacking a
> web UI out of its shipped one will give us what we need.
> 
> BTW, I packaged veracity in NixPkgs for easier evaluation.

Noted.

-- 
Evgeny