On Sat, 2004-08-07 at 12:56, Doug Way wrote:

> Actually, I've needed the same capability for moving an [approved] item 
> back to Review status.  There are several groups under Approved right 
> now (at the bottom of the list) that have some issue and should go back 
> to Review.  We could probably also handle this with a [reopened] tag.

Maybe we should just implement a set of tags that re-categorize a
group.  're-reviewed', 're-approved', 're-update', 're-unreviewed'? 
That might be going overboard but you get the idea.

> I guess support for a new [reopened] tag also needs to be added to the 
> BFAV server.  (I'm not quite sure why the BFAV server has to know about 
> all the tags... I guess this is for performance reasons?)

The BFAV server knows about the tag so that the text processing work has
to only be done once.  This was a large part of the speed improvement
between BFAV and BFAV2.  It doesn't of course have to know what the tags
mean, it just has to know what category the tag is and what bitmask it
maps to.  A few minutes work basically.

> 
> Another BFAV improvement which is really needed is some sort of website 
> which shows the current status of all fixes/enhancements for the last 
> month, similar to Bert's old sqfixes site, so everyone has a quick/easy 
> place to check what the status of something is.  I already emailed 
> about that privately... I wanted to work on this after 3.7 is released 
> if no one else gets to it.

I would be willing to look into this.  However I've been burned rather
badly in a couple of cases in the last couple of years putting in a lot
of time on projects to then get no reaction, good, bad, or otherwise.  I
would only really be willing to do this if I'm presented with a clear
design that the community in some fashion agrees will provide the
desired functionality.

> 
> Merging groups together would be more difficult with the current 
> system... I know Ken has talked about eventually replacing the 
> emailed-based server with something more robust.

I spent quite a bit of time a few months ago looking into this.  But I
hit a wall on security.  Its amazing really how much safety is built
into the current system just due to the fact that it is an 'append-only'
system.  There's never any case in which information can be lost or
overwritten.  Implementing anything as safe in an object database model
looked to be difficult.  That wasn't the only reason I stopped, but it
certainly slowed me down.

Again I would be willing to look at this again if the community as a
whole could come to some sort of a consensus as to what they would
really want out of such a system.

However the more I've thought about it I'm coming around to the idea of
breaking the bug tracking and harvesting systems apart.  There are many
many open source bug tracking systems available, it really should be
possible to make use of one of these.  On the harvesting issue I found
Michael's reminder of the dual update stream interesting.

I've recently been spending the bulk of my freetime working with Brian
Rice and Lee Salzman and company on Slate.  Clearly this is a much
smaller and simpler (thank goodness) system than Squeak.  But it has
been amazingly refreshing to email a patch to the mailing list and have
Lee or Brian harvest it within a couple of hours and that be the end of
the issue.

I'm wondering if we can't find some sort of compromise between that and
the current system for Squeak.  Have two seperate streams: a stable
stream that only the harvest master can modify (maybe multiple harvest
masters) and an unstable stream that either any harvester, or better yet
a larger body of developers, can modify.  Each developer can then choose
to subscribe to either stream for an image.  For those on the stable
stream life would continue as it is.  For those on the unstable stream
it would be understood that catastrope is just an update away and that
you ALWAYS save before loading updates, maybe a couple of copies. 
Better yet the system offers to let you stop updating after each update
and verify the state of your system.  Whatever.  The point here is to be
more optimistic about updates in which case I believe we will have more
eyeballs and people react much more strongly to problems than to
reviewing.

Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040807/52cff76b/attachment.pgp