"Andreas Raab" <andreas.raab at gmx.de> wrote:
> > > Please be clear about what you're trying to achieve with this step.
> [snip]
> > As I understand it, the desired benefit is ... [lowering a specific latency]
> Thanks. It's good to have an understandment about this (I actually thought
> this was designed to give some people "direct access" to the unstable
> stream). 
Just a reminder, this is my understanding, might not be Dougs intention.

Andreas, 
I put the part where we bicker around semantics at the end, and the meat
in the beginning ;-)

[A bug tracking system would encourage good bug reports]
Agreed.

[A bug tracking system would help manage beta stages usefully]
Agreed! I think installing some such could be useful. 
Ideas on how we can more or less painlessly move the existing bug
reports to some such? of course this cannot really be mechanized,
because a lot of classification and description would need to be added.
Something that stuffs our current bug reports with their missing
information into a real bug report system would simply fill it with
useless garbage.

Maybe the mail-bug-to-list could become "post new bug to BTS", adding
the information it scrapes from the debugger to the record.

Anyone volunteer to install something like that with an initial
configuration (I assume we need to create categories, versions and so
forth) somewhere we can play with it? 


<semantics>

>OTOH, let me point out that (as has been earlier mentioned) there
> is really no intrinsic reason why we have to be as conservative as we are
> with the "main" stream. Not in my experience anyway.
This statement is so general as to be useless. I agree specific
requirements might be replaced with others, and be more effective, but
unless we discuss things specifically, I don't even know if the
"conservative"ness you refer to is really in the process, or just in
your impression of it. What are you talking about? make a proposal.


[Why compare BFAV/mantis]
> This may sound like a stupid but I'll have to ask it anyway: Have you ever
> used a bugtracker like Mantis or Bugzilla? 
Yes, but not much.

> What they do is to manage the
> evolution of bugs and ...
granted.

> ... by the end of the day that's what BFAV does, too. 
This is false, it doesn't do that. Maybe it should in your opinion (and
I do agree we should perform this activity), but the BFAV never was
intended to do so (*) and it isn't being used that way by its users.

(*) see for example, the following mail whose header is below, which was
part of the original "spec" for the BFAV:
*********************
Date: Wed, 07 May 2003 19:30:30 +0200
From: Daniel Vainsencher <danielv at netvision.net.il>
Subject: Re: Convincing a harvester (was on SqF list)
To: The general-purpose Squeak developers list
<squeak-dev at lists.squeakfoundation.org>

[snip]
Bug fixes archive makes finding stuff easier. It still takes time for
every changeset you want to check out to
- choose it
- download it
- open a clean image
before you can test.

So -
Write a small app that shows a list of changesets, html-scrapted off bug
fixes, and when you choose one, uses OSProcess to activate another
Squeak on a clean image, and load the changeset in question into that
image.

The process becomes - look at a sorted list, click your favorite,
review/test the code, go to your favorite mail client to write the
review. Next!

Daniel
*********************
It clearly shows that the BFAV was intended as a tool for making it
easier to harvest FIXes and ENHes. Neither Guides nor anyone else I know
of every commited to or intended to track bugs and their evolution. Just
harvest the communities contributions. Just for the record. 

> We
> use it to describe the status of bugs (or features, aka [ENH], which are
> supported in most bug tracking tools) from
> a) reporting them ([BUG] post in BFAV; creation of bug in a bug-tracker)
> b) discussing them (follow-ups in BFAV; bug-notes and similar in
> bug-tracker)
> c) resolving them ([BUG][FIX] post in BFAV; resolution of bug in tracker)
> d) closing them ([approve][close] or whatever in BFAV; one or the othe ways
> of closing the bug in the bug tracker)

If you actually look at how people are using the BFAV, nothing
interesting is actually happening with bugs. My point is that the BFAV
is helping us with the mechanics of dealing with code that wants to get
into the image, and from that perspective, not with bugs or the
perspective that someone has requirements that aren't met by the system
(bug/issue tracking software as you describe it). IOW, the BFAV and any
bug tracking software are quite likely to complement each other nicely,
and don't really compete for the same space. 

> In other words, what we use BFAV for overlaps to 100% to what these
> bug-tracking tools are.
I really doubt that any external bug tracking program can ever make it
as easy as the BFAV does to open a proposed fix, view it, file it in,
test it. These are two different kinds of tools.

Daniel Vainsencher