I've been feeling a bit guilty about spamming the list with all of 
these [update - 36xx] etc. messages, so I'm wondering if we should 
consider moving the BFAV traffic to a different list relatively soon.

Everything Brent mentions below sounds good, but perhaps we could move 
traffic off the list sooner by doing a few simple steps first:

1. Have Cees set up another mailing list called something like 
squeak-bugs or squeak-harvesting.  He's already set up a bunch of lists 
so I believe this is simple to do.  (It would need to accept posts from 
anyone whether subscribed or not, although perhaps it could reject spam 
by requiring a specific string to be present in the subject or body.)

2. Have Bert change the sqfixes (and possibly sqbugs) archive to read 
the new squeak-bugs list.  This would still not be a permanent 
solution... it would eventually be replaced with something like the Bug 
Fix Archive Server which Brent describes.  But it would be simple to 
switch right away.

3. Switch the "mail to list" feature in the image to post to 
squeak-bugs.  (I think we were also talking about figuring out which 
(if any) steps of the harvesting process should still be posted to 
squeak-dev... we may still want to have the initial [FIX]/[ENH] posts 
show up on both lists for example.)

(and 4. Switch the BFAV to also post to squeak-bugs of course)

I believe this is all we'd need to do.  These steps are all quite 
simple... should we try to do this soon, say, right near the beginning 
of 3.7alpha in a couple of weeks?

- Doug


On Thursday, July 24, 2003, at 10:06 AM, Brent Vukmer wrote:

> Guys, it's like you're reading my mind (or the BFAV Swiki pages... :) )
> Here's a fairly detailed response:
>
> [ BFAV noise on squeak-dev ]
>
> I really want to get the BFAV traffic onto a separate
> "bug-fixes-archive" list on squeakfoundation.org, soon! I need Goran's
> help setting that up on the squeakfoundation server.
>
> [ BFAV + bug reports + posting updates ]
>
> I really want to make the BFAV cover the whole process, from creating a
> bug report to posting an update to the FTP server.  The BFAV will have 
> a
> tabs for "unreviewed", "reviewed", "approved" and "updates" and users
> will be able to drag-and-drop posts from one tab to the next, with the
> appropriate side-effects.
>
> I have put the beginnings of bug-report creation functionality into the
> CommentNotePad.  I need to enhance the CommentNotePad so that a bug
> report has all the required info (VM version, image version, installed
> SM packages, etc.).  As far as viewing bugs goes, you should be able to
> point the BFAV at http://swiki.gsug.org/sqbugs right now.
>
> I'm not interested in building a web interface for creating bug 
> reports;
> volunteers are welcome!
>
> [ Bug Fixes Archive Server ]
>
> The BugFixArchive-Model package is very close to being able to do this,
> as Daniel pointed out.  I'm going to look at the code that Bert's image
> is using and include the functionality that I don't have yet.  The new
> Bug Fixes Archive server will parse the canonical .mbox file ( the one
> available for download from squeakfoundation.org ) into individual .txt
> files.  We will use Apache to serve up the static .txt files.  BTW, for
> the near term, I'm going to continue to use SMTP to populate the
> archive. I've thought seriously about using other means -- for example,
> doing an HTTP POST -- but mail is very simple and robust, and I think
> it's best to stick with it for now.
>
> I'm not interested in building a web interface to display the archive's
> contents a la http://swiki.gsug.org/sqfixes ; volunteers are welcome!
>
> [ Client-Server/Database ]
>
> I like keeping the queries local.  In a sense, the local BugFixArchive
> object *is* a database, in that it has fairly extensive 
> sorting/querying
> capabilities, and we can always add more.  I also really like that the
> BFAV creates a local repository with all of the .txt files.  If the Bug
> Fixes Archive server goes down, I still have my local repository to 
> work
> with.  I'm really interested to find out how much this off-line
> capability matters to other people...
>
> I've thought about using Magma, actually.  I'd want to keep the local
> repository synced with the server repository, for working offline, and 
> I
> would want the BFAV user to not have to any work to administer the 
> Magma
> database.
>
> [ Package-Specific Archive ]
>
> The BugFixArchive-Model package already supports this; you can point a
> BugFixArchive object at whatever update URL you choose.
> I need to do a little more work to support posting to a 
> package-specific
> archive.
>
>
>
>
>
>
>