Future release process (was: [Squeakfoundation]3.5 release timing)

[Daniel Vainsencher]

Doug Way <dway at riskmetrics.com> wrote:
> Not really.  I'm not sure that the Visibility argument is that 
> compelling, though.  
No, no no - misunderstanding. These are not arguments I am giving for
making more releases! They are desirable properties of our process,
which are affected by releases, but which I think we can better improve
by other means.

> Okay, perhaps by Visibility you also mean the fact that a newbie's bug 
> report might get fixed and released into a stable version sooner with 
> frequent releases than it would have otherwise.
For a start, a newbies bug should not be irrelevant - "Already fixed in
the 3.7 alpha".

But I think it's even more important to focus on visibility for
non-newbies. When something is in beta/gamma stages, right now,
everything that people develop for the image basically stops getting
feedback, because nobody is trying to harvest it.

Even worse, even in alpha, harvesting is going too slowly, so that work
and feedback is often separated by months. This means people don't SEE
what they are doing. It's like driving with your eyes closed, based on
reports from the person in the other seat, except he's reading a book
most of the time.

Making release faster could bring this does from six months to two. What
we need, really, is for this to work in a framework of days or weeks.
Which means making things alot more distributed.

An official policy allows people to give themselves feedback. If the
policy specifies tools like SLint, they can even get some objective
feedback. And project groups like MCP and KCP allow people to get
feedback from a group of focused experts. Both are not tied too the
release cycle.

> In the meantime, I will try to outline a brief harvesting process (say, 
> tomorrow), at least, that we could debate very briefly and then use to 
> harvest things, by hand at first, and then use that process as a basis 
> for the tool.
I think we can speed up harvesting in a simple way. Specify these
"goodness criteria"-
- Has gone through indepedent review
- Has been independently tested
- Has been passed through SLint, with every finding inspected (and the
relevant ones fixed)
- Has a detailed documentation of the rationale for every change
- Is small (<10k)
These aren't absolute requirements. Instead, they determine priority.
The more of these properties you fix has, the sooner it'll happen. We
can do this by simply sorting the list accordingly.

Then, if people care about a specific fix, they'll review it, test it,
SLint it, document it, and make sure it is in small pieces. That will
surely improve speed up the bottleneck process of evaluation. Fixes that
don't recieve this attention, might not (yet) deserve ours.

Daniel