Hi Doug,

Some thoughts:

> 1. Start up the separate "internal" update stream as Michael suggested.

Please be clear about what you're trying to achieve with this step. All I'm
reading under point 1. is techno-babble about the mechanics but no reason
*why* we want to have that update stream[*]. And making an extra update
stream for the update stream's sake will only increase perceived "latency"
of getting fixes out. If there isn't a reason for having an extra update
stream then please don't do it for bureaucratic reasons only.

[*] Understand that what I'm asking for here is some public acknowledgement
that "we are introducing the extra update stream because ... and the extra
update stream addresses this by ..." (for whatever values of ... you'd like)

> 2. (This one is my suggestion.)  If we have this unstable update
> stream, posting updates to this stream doesn't have to be as
> coordinated as with the regular stream.  So, we could allow harvesters
> who [approve] an item in the BFAV to also immediately "broadcast" that
> item as an update to the unstable stream.  (The broadcasting mechanism
> to do this is also already there from the SqC days, but needs some
> fixing.)

In which way do we expect this to address what issue(s)?

[...some more technicalities deleted...]

> 3. Let some harvesters/guides have direct "commit"/broadcast ability,
> without going through the BFAV approval process, as some have
> suggested.  However, I think this should be limited to only certain
> types of updates, probably just fixes and smallish refactorings/cleanups.
> New enhancements or major redesigns would still need to go through
> the approval process.

To what extend do the above restrictions model what is currently practice in
any of the "external" packages? ("external" in quotes simply because they
are "official" and as such I believe pretty much the same rules apply to
them as to the updates) As far as I can tell, there have never been any
discussion about decisions made by any of the "official" package
maintainers. Is the goal here to restrict (and more conservatively manage)
changes that are "in-image" compared to changes that are "ex-package"? (this
is NOT a trick question btw)

> So... how do these ideas sound?

Somewhat half-baked, if you ask me ;-) It depends on where we want to steer.
The above proposal(s) seem not directly to address any of the issues that
have been raised (or if they do I couldn't find the relation).

> #2 and #3 would hopefully remove me as the bottleneck at the update
> stream, which would be a bit of a relief at this point... ;)

Well, if that's your reason to propose them why not put it forward that
way - I think everyone will agree that it's useful to ease your (really
good) work.

> 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
> of annoyed seeing all of the posts in BFAV which are for the SM
> package, or the VM, or Balloon3D... these posts can never proceed to
> Approved/Update.  I'm not sure exactly how this should be done, and I
> probably won't have time to work on this, but I wanted to offer support
> to the idea.

And I want to offer support for the idea of "why not take what's out there
already". I've been using Mantis for a while now and all I can say is that
it addresses precisely the issues that you'd expect a bug-tracker to
address. In short, why do we have to reinvent the wheel if there are plenty
of solutions present? Solutions which (sorry if I have to say that but it's
the plain truth) address my needs and likely that of the Squeak community
ten times better than BFAV currently does.

> - Committing directly to a Monticello repository for the base image,
> instead of using updates.  This seems like more of a long-term goal,
> not really something which can be achieved during 3.8.  Actually, I'm
> not sure there's any point in doing this until the base image is staked
> out into packages (and stored on SM, with dependencies?)  But perhaps
> the goal was to stake out these areas relatively soon, even if many of
> the packages are "co-dependent" in the dependency scheme.  But in any
> case, I think this is all less urgent as far as speeding up the
> harvesting process goes.  (Although I think we should still add
> Monticello to Basic Squeak in 3.8 as discussed earlier... it is really
> an add-on which should change existing behavior.)

Committing to an MC repository isn't the problem - synchronizing with it is
(e.g., all of the dependency issues etc). There is one thing though that
bothers me endlessly after having worked with MC for a while - it's the loss
of all of the history information. That is one portion of information that
(until MC) I never noticed how important it is for me....

Cheers,
  - Andreas