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