OT: Distributed bug tracking?

[Marcin Kasperski]

> I don't see how a command line tool requiring people to download a
> bug database is going to capture bug reports from a wider
> audience. It seems to address mainly the tracking side for
> developers.

Of course. And at least for me this is exactly what is this tool
about - easy, light developer notepad. And be is good in this context,
compare the time you write

  be new "Misbehaviour in opera"
  (and write those 5 lines of description in spawned vi)

with opening bugzilla/trac/whatever, locating correct product,
submitting and saving the form.

The whole concept of wide audience does not mix well with distributed
bug tracking, which repository should such wide audience target...

> If someone did a web front end (like ikiwiki, but rather
> more polished, I guess), then maybe.

There is some preliminary web frontend in be, I have not take a look
at it, there are sophisticated web bugtrackers already available.


> And while we're at it, I think this
> should be extended to the wiki side as well. Being able to work
> offline on the wiki sounds good to me.

Well, you said ikiwiki...

> So in all, I currently think having the bugs in the source repo is not
> the way to go.

As I already said, I feel that there just are two sides of 'bug
maintanence'. be is not about maintaining community-submitted (or
user-submitted, or client-submitted) bugs of huge volume. It is about
replacing ToDo files, ToDo notes within sources etc. IMO. And does
this job fairly well, be commands are lightweight enough to be usable
in such a context.

And it could make sense to rewrap it as an extension, although
this is of course not crucial.


-- 
----------------------------------------------------------------------
| Marcin Kasperski   | You have the right to produce quality work
| http://mekk.waw.pl |          at all the times. (Beck)
|                    |
----------------------------------------------------------------------