Just wanted to pipe in that Daniel's proposed harvesting system here 
looks quite good. It uses the existing infrastructure (with Bert's 
improvements) in such a way that we could get started with this right 
away.

Here's what I see as the advantages/disadvantages versus the previous 
swiki-table harvesting system...

Advantages:

- Harvesters don't need to edit bulky swiki tables (and get into swiki 
edit conflicts) anymore to add comments on submissions.

- The email message links in Bert's sqfixes archive can contain quite a 
bit of detail or even improved versions of submissions, simply by 
sending an email.  This was more of a hassle in the swiki tables, the 
result being that noone typically added links to improved versions, etc.

- The swiki tables needed to be generated manually, which tended to be 
done only once a month, which added a big delay in the process.  This 
makes a big difference in turnaround time.

- With the new system, anyone in the community can contribute by 
reviewing someone else's submission and sending an email with the 
appropriate tags.  (In theory this could have been done with the swiki 
tables, but then we really would have had swiki edit conflicts.)  A 
"harvester" will still be needed as the last step before a submission 
can be finally approved, but having some steps done by others will 
greatly increase the likelihood and speed of approval.


Disadvantages:

- This could increase traffic on squeak-dev by quite a bit.  But 
squeak-dev is already quite busy, so I don't think this will be a major 
problem.


So in summary, let's move ahead with this!

I'm still planning on working on a Squeak-based harvesting tool & a 
submission tool, which would eventually replace this system.  (Now that 
I have a little more free time, with 3.4 released and with the latest 
version of Whisker done, I should actually be able to get started on 
this.)

But Daniel has come up with what looks like a much better system than 
what we had before, which should last us at least a month or so, if not 
longer.  And the process improvements in his system can be carried 
forward into any future system, too.

- Doug Way


On Friday, March 7, 2003, at 09:52 AM, Daniel Vainsencher wrote:

> Hi everybody.
>
> We've been collectively thinking a lot lately about what to do in 3.5,
> whether this fix or that should be harvested into 3.4 right before the
> release, and generally, how do we all make Squeak better, faster.
>
> Well, the only way that Squeak (right now talking about the image) gets
> better is when all of you people do good things, and then we harvest
> them.
>
> I like to think about it like a sort of mix between a factory and a
> funnel. A factory, because between Joe submitting a fix, and us
> harvesting it, lots of things have to happen (most of them maybe a
> little mysterious?), and a funnel because while there're quite a lot of
> people in the community, there are quite few harvesters, and just one
> Doug, that has to actually get things into the update stream.
>
> Now, when a lot of the factory stages are mysterious to most people, 
> and
> submitters (understandabley) believe that their responsibilities end
> when they submit a fix, what happens is that great streams of raw,
> uncooked changesets get stuck in our tiny little narrow side of the
> funnel. And then we have harvesting backlogs months long, like now.
>
> How do we avoid this? well, obviously, we need to keep raw chunks out 
> of
> the funnels neck, and keep it busy with small, smooth, creamy change
> sets. How do we do that?
>
> Well, thanks to BertF, the new and improved squeak fixes archive
> (http://swiki.gsug.org:8080/sqfixes/) now shows people's comments on
> things that get archived, *if they are properly formatted*. See for
> example, my stupid mails in reply to Diego's [Fix]
> MethodReferenceHashFix. Note how my second (but not my first - the 
> "Re:"
> ruins it) reply is right there in the archive, together with Diego's
> change set.
>
> What does this have to do with you all? well, starting today (unless
> Doug or someone sees a good reason why not), we're harvesting things
> directly from the fixes archive. And being lazy, we will alway *prefer
> the fixes that have tags showing they'll be quick to process*.
>
> For example if I see -
> [Fix] Save the world!!
>  John Doe (2/3/4)
>
> and
> [Fix] Adjust the background to a paler shade of gray
>  Jane Doe (2/3/4)
>  Joe Shmoe (5/3/4) (et, er - it's beautiful)
>
> I will not even look at how John is saving the world, because that's
> only his opinion, and I also think all of my fixes are good, and look
> where that gets us ;-)
>
> (If those tags make you think I'm stuttering, read also my recent
> message "How to get your stuff harvested", appended at the end of this
> mail)
>
> The beauty of the system is this -
> * You have something you can actively do to get the fixes other people
> do that you like into the image. Add tags we can trust.
> * You have something you can do to get YOUR stuff in the image. Get
> people to add tags.
> * You already know WHY we won't add that important fix into the image.
> It doesn't yet have enough tags, so we're picking easier marks.
> * Since we'll be skimming off the top, only stuff that's easy to do, if
> something is important enough to have gotten all of your loving
> attention (and tags), we'll have time to deal with it.
>
> Well, you know what to do.
>
> Daniel
>
> ************************************************
> diegogomezdeck at consultar.com wrote:
>> I think MCP and KCP have to be included as soon as possible. Faster we
>> include them, faster we get bug reports, faster we fix them.
>> Diego Gomez Deck
>
> I want to start getting things in from the projects groups (and from
> everyone else) asap. What can you do? for each of the proposed change
> sets, give them as many as possible of the following QA tags -
> - (sm) small. Changesets should be under 10k.
> - (cd) changes documented (reasoning is given that explains every
> different change made)
> - (sl) SLint approved (you don't have to do what SLint says (sometimes
> it's wrong), but have a good reason why you didn't)
> - (er) - externally reviewed (design + code, by someone other than the
> author, quite knowledgable with whatever is changed, and whatever else
> it might affect)
> - (et) externally tested, as er above, also using cd, but generally
> making sure it doesn't break anything that uses it.
>
> It would be a good idea to have those marking right there with your
> changes. For the MCP/KCP, it should be on your page (see below). For
> people submitting stuff on the list, the QA tags should be appended to 
> the
> subject, in parenthesis.
>
> Something ready to become a changeset should look like this -
>
> On a project page -
> ******************
> #  MCP-0001-initialize-dgd.cs.gz (sm,sl - dgd; cd - dgd+efc; et - gm; 
> er
> - ar)
>     * refactor of #initialize methods
>     * added/implemented #defaultBounds, #defaultBorderColor,
> #defaultBorderWidth and #defaultColor
>     * some small methods categorization
> * remove of most direct asignation for color, bounds, borderColor and
> borderWidth variables
> ******************
>
> On a CS submitted to the list -
> [Fix] Morphs flip upside down when crossing the equator (sm - dgd)
> If you just did an external review, simply reply with your comments
> in the body, and in the subject, put your tag, as in
> [Fix] Morphs flip upside down when crossing the equator (er - dvf)
>
> Be careful not to change anything outside the parens, or your stuff
> will probably be missed when things are grouped by subject.
>
> If you do this, us harvesters really need to make only the kinds of
> decision we should be making - "is there a reason not to put this in
> right now? probably not. There it goes." I promise you that we'll do
> that much faster than we can harvest things now.
>
> Daniel