Towards 3.9.1 What's going on here?

If the release team of 3.10 is doing its job then why
are the changes Keith wants needing to be put in a
separate release?

During every release there are forces involved that
generate projects. Squeak is easily changeable and the
time frame for making those changes will always be
much shorter than the time frame for creating an
official release.

Also releases fall on the shoulders of one or two
people. Who will not reflect everyones taste. And will
not have time to test everyones contributions.

In other words. 
Problems create solutions in the form of code. 
The solutions create problems for the release team in
terms of time required for 
1) validation of the viability of the solution. 
2) the processing time to get the solution into a form
that can be incorperated into the release. 
3) more time if the solutiion proves to be invalid and
needs to be reverted. 
4) and more time for the communications that might
need to take place 'tween author and the release team.

So the pace is slow and the process rather formal and
bottlenecked. And not particularly designed to handle
on the fly changes.  And certainly not designed to
handle on the fly radical changes.

At the same time problems that directly affect the
process of releasing the image clamor for solutions. A
large section of Keith's plan is to change and improve
Monticello. How deep and extensive those changes are I
don't know because they are not done yet.
The page that descibes them on his wiki has not been
created yet.

The point is that those changes would not be
appropriate to include in a current release. And only
appropriate in a future release if they were done and
vetted before the end of the acceptance phase of the
release.

So all these good ideas and a chicken and egg problem
about their acceptance.

Questions:

1) Does the current release process have the right
sequence of steps? Or is the sequence cumbersome and
slowing the feedback cycle down?
2) Is there a simple and faster way to do release
steps?
3) Is there a better way to deal with the forces that
will always produce new code during a release cycle.
4) Is there a better way to communicate to the  coders
what deadlines and standards have to be met for
acceptance of code to a release?
5) Are there any other good ideas that address the
forces at work that I described above but have not
been able to see or pinpoint in this email?


Yours in curiosity and service, --Jerome Peace

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com