Hi Daniel,

> > Please be clear about what you're trying to achieve with this step.
[snip]
> As I understand it, the desired benefit is to remove the latency that
> occurs between the moment an approver approves something, and the moment
> Doug send out updates. In the new scheme, approvers would be able to
> broadcast their update immediately (to the unstable stream). I think
> that if (using the conflict checker) approvers can be reasonably sure
> not to make a mess by the very act of publishing from multiple sources,
> then the way to address the stated concern is to do the same directly
> with the current stream.

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). 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.

> > > There were also a couple of other things discussed:
> > >
> > > - Enhancing BFAV to group posts by package and maybe by other
> > > groupings.  I think everyone agrees this is a good idea... I get sort
[snip]
> You're comparing BFAV and Mantis, and I must be missing something. As
> someone already mentioned, BFAV is for BugFixes (and enhancements). It
> currently does nothing, nor does our process, for bugs. While I agree we
> could benefit from adding the treatment of bugs to our tools (maybe by
> adopting Mantis) and to our process (such as tracking release critical
> bugs to image and packages and not releasing before they're fixed), I
> really don't understand how anyone can compare Mantis to BFAV, except
> under the (mistaken) assumption that the BFAV is supposed to deal with
> bugs somehow.

This may sound like a stupid but I'll have to ask it anyway: Have you ever
used a bugtracker like Mantis or Bugzilla? What they do is to manage the
evolution of bugs and by the end of the day that's what BFAV does, too. 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)
In other words, what we use BFAV for overlaps to 100% to what these
bug-tracking tools are.

> Actually, maybe this assumption is being spread by the fact that they
> show up there, and we could unmuddy the waters quickly by simply
> filtering them out in the client, right now (I think this was also
> proposed before, but ignored, so I'm just raising it again).

This actually isn't the point (at least not from my POV). One of the things
that I'd like to achieve with a "real bugtracker" is to distinguish a
"random" bug report from an "orderly" one. Meaning that if people expect
bugs to be fixed they do need to put in a little extra effort besides just
pressing "mail out bugreport" in the debugger. Just a *little* help (say,
doing an initial classification of the bug into a specific package) would go
a long, long way here.

Another reason for wanting to have "orderly bug reports" is that it actually
gives us a target when we're out of beta - namely when no more bugs for that
particular version of Squeak remain open. This doesn't mean they have to be
fixed btw - it is perfectly reasonable to resolve some bug by saying we
won't fix it in this version. But having that tracker (and using it for this
purpose!) ensures that all of the problems are being looked at and resolved
some way or another for a particular release.

> > Committing to an MC repository isn't the problem - synchronizing with it
is
> > (e.g., all of the dependency issues etc).
>
> What does this mean? assuming its a separate issue from what you raise
> below, I don't understand what you mean.

Yes, it's a different issue. Sorry for mixing this up.

Cheeers,
  - Andreas