Towards 3.9.1 What's going on here?

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 

I am new to squeak and certainly do not have the neccessary insights into the
release cycles and development models yet.

But I wonder if tools like Jira[1] and Confluence[2] could be useful enhancing
the communication in the community and help with release management. I know
them from apache and several other opensource communities - they have proofed
to be very good tools for managing such projects.

There are free licenses available from atlassian. However, I do not know for
sure if squeak does qualify for such an opensource license.

Just my 0.02 EUR ;-)

[1] http://www.atlassian.com/software/jira/
[2] http://www.atlassian.com/software/confluence/

El 5/6/07 4:18 PM, "Jerome Peace" <[hidden email]> escribió:

> A
> large section of Keith's plan is to change and improve
> Monticello.

I tell he what Monticello have owners.
Very good Squeakers.
And as I tell in separate mail, Monticello 2 is ready for doing a release
with ?

>2) Is there a simple and faster way to do release steps?
I always said what old style change sets, but is not what we agree use on
3.10.
Steph said what is the only way what all could discover shortcomings in
Monticello.

One more time, in Mantis I have fixes/enhancements what could go into 3.10
via cs but no via Monticello.

No need of a complete release for solve this.
Only what need is take 3.10, modify Installer mantis createRBforBug: 6089

When have a .mcz with the change what 3.10 could load via Monticello
Browser, I do a motion for give a medal to winner.

Edgar

>> A
>> large section of Keith's plan is to change and improve
>> Monticello.
>
> I tell he what Monticello have owners.
> Very good Squeakers.
> And as I tell in separate mail, Monticello 2 is ready for doing a  
> release
> with ?

no

what are the problems you encounter?

El 5/7/07 3:57 AM, "stephane ducasse" <[hidden email]> escribió:

> what are the problems you encounter?
Image blows.
I tell that many times. But some still don't know.

And today I discover what Mantis 0006089: TTF Cache Speedup also blows the
3.9 final

Not the 3.10 , but I can't have how load a .mcz or .mcz with this .cs into
image.

Same for Klaus
 0006336: Unicode membership test reduced to String #= (String
#compare:caseSensitive:) ?


Same for Martin Loewis
0006348: [FIX] Improve performance of weak key dictionaries

Last time what I said this.

Monticello don't manage all cases.
Old Cs style yes.

Monticello have me working hours and having all kind of headaches.
Old Cs style no.

Wish we move ?
What is more important , a better image or wait until some could do this
"Monticello way" ?

Edgar

2007/5/7, Edgar J. De Cleene <[hidden email]>: I heard this before, from the 3.9 team.

Cheers
Philippe

> Edgar
>
>
>
>

Why are you tied to monticello?  Lots of these things sound like they are
part of the "core" anyway (which can't really be a montello package can it?)


_________________________________________________________________
Now you can see trouble…before he arrives
http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_protection_0507