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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
