"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Hi Doug,
> > 1. Start up the separate "internal" update stream as Michael suggested.
> > 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.)
> 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.

Unless I'm missing some benefit of the extra stream. Note that once an
approver approves a posting, it would by default make it to the regular
stream in any case. Doug?

If we want to prevent a lot of people from seeing the few problem
updates we do release (now too), we could have a preference that says
"get all updates/get week (or more) old updates". (this is another
proposal, BTW).

Having multiple publishers to the regular stream is a significant
change, in that it would remove the role Doug is playing during the
alpha stage. Doug, what responsibilities exactly would this devolve unto
the approvers? alternately, if we go for two streams, what do you think
should happen between the approver publishing a fix to the unstable
stream, and you releasing the updates to the main stream?

Another question is what happens during beta/gamma. Until now, approvers
would simply continue their work, and Doug could implicitly ignore
"too-alpha" approved changes until the next cycle begins. Maybe the
approvers should have both options "approve"/"approve and publish", and
would simply refrain from publishing non-fixes during beta/gamma.

> > 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)
AFAIU - when a package is made external, it becomes controlled by its
maintainer, and its development (quite naturally) subject to whatever
process he chooses, instead of the BFAV. Some community control is
retained, but it is "external" to the packages developement - the
community chooses when to update the image with new releases of the
package. If some package suddenly became unacceptable due to changes by
its maintainer, a fork might happen. These are sufficient checks on
developement of packages that are external, IMO. 

This is the big difference between updates to packages and updates to
the image - where does the final decision about inclusion in the
complete system happen? Proposal 3 means removing the checks on changes
to the image, and asking the approvers to go around them only for
trivial changes. I'm not sure what this accomplishes - approver can
already "self approve". They aren't "supposed to", and they know it, but
they can and do when they think its appropriate (and then get a bit more
embarrassment than usual if they approved bugs). So I'm not sure what
this proposal achieves.

> 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.
I agree, and I think to consider the proposal about direct broadcasting
and extra streams, we need to understand well what kinds of things you
do. Other parts of the process we know well because many people
participate, and we discuss them. Your part of the process is one that
generally "just works", so if it seems like above I was ignoring half
the checks/things you do, it is not lack of appreciation, it is merely
because I don't know exactly what you do...
 
> > 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.
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.

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).
 
> > - 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). 
What does this mean? assuming its a separate issue from what you raise
below, I don't understand what you mean.

Daniel Vainsencher