Squeak Maintainence and Condensed Sources

Peace Jerome peace_the_dreamer at yahoo.com
Wed Jul 26 03:41:27 UTC 2006


> 
> So what do you suggest?
> 
> 
>      Marcus
> 

Hi Marcus,

Thanks for your replys. 

I had carefully crafted a reply to your first
response. 
Which your most recent reply may have invalidated.
Still it sums up my best thinking so far on this and
it answers the above question to here it is:

Squeak Maintainence and Condensed Sources

Hi Marcus, 

Thank you again for your response. I am feeling
reassured by what you say about the importance of code
history. And by the fact that YOU are saying it.

The ideal future is far away and uncertain.  So I hope
you will give some consideration to facilitating what
we can produce easily with the tools on hand. 

Please give consideration to the formula:
-Create a condensed source version for Squeak-6665
(either 3.8 final or 3.9a start).
-Provide the load scripts to produce 3.9final with all
changes from that source.
-And have that as a deliveralble for the squeak
maintenence folks.

It will help.

<Current note: So why is it impossible to do this? --
Jer>

Also it would probalbly be good to draw others into
the pieces of this project you don’t strictly have to
do yourself.  I suspect there are a good number of
squeakers who have enough expericence to condense
Squeak-6665. I don’t know how many can do what you and
stef do with the load scripts. This might be a good
excuse to think about how to transfer that knowledge.

I believe what I have suggested is possible. We need
to take care of what is needed for right now within
the present limitation. The question of what to do
about scalability can be postponed ‘til the future.

Yours in service, --Jerome Peace 



>Marcus Denker denker at iam.unibe.ch 
>Tue Jul 25 08:29:05 UTC 2006 replied: 

>To make one thing clear: I do understand that code
history
>is *extremely* important. And I do know that we need
>even more than a simple per-method history can do.
>
>At SCG, we actually do research into analyzing
history
>of code... so be assured that we understand why it's
needed,
>that it is needed, and that without a past there will
be no future.

>     Marcus

I expect you merely to do your best.
>

--- Marcus Denker <denker at iam.unibe.ch> wrote:

> 
> On 25.07.2006, at 06:15, Peace Jerome wrote:
> 
> > Squeak Maintainence and Condensed Sources
> >
> > Hi Marcus,
> >
> > Thank you for your first reply to
> > Condensed Sources vs. Squeak Maintainence
> >
> > To restate the essesnce of my concern:
> >
> > I believe a great deal of code will rot and squeak
> > will become a lot more fragile than it already is
> if
> > you compress sources now in the process of
> finalizing
> > 3.9.
> >
> > I understand your concern about the changes file
> going
> > over its limit.
> >
> 
> It is not a "concern". The changefile is 25MB in
> 7048, this
> is not a "concern", this is a fact. And the other
> fact is that
> the maximum size of the changes file is 32MB.
> 
> 
> >
> > First the task of getting a 3.10 with all changes
> from
> > 3.9 would start with '3.9a with all changes from
> 3.0'
> > that Doug Way (bless his heart) produced after I
> said
> > please three times in one post.
> >
> 
> This is technically not possible, as the changes
> file would
> go over it's maximum size.
> 
> > Second condensed sources should come at the
> beginning
> > of an alpha cycle not at an end.  So one
> alternative
> > is to condense sources with the first version of
> 3.9
> > alpha (or the 3.8 version just before that name
> > change.  And produce a 3.9 with all changes from
> 3.8
> > (condensed) source. That would not be as nice but
> it
> > would at least be acceptable.
> >
> 
> 3.9 is not reproducable from 3.8, so building it on
> top
> of some modified 3.8 is impossible, at least if we
> plan
> to ship it soon at all.

1) I am talking either 3.8 or 3.9a at 6665 point to
present. Is there some practical reason why 6665 would
not be the same beast if the changes were compressed.
Because in theory it should be the same thing with a
different changes and source. Or is it that the MC
load scripts can't reproduce the process of change?

2) I want the all changes version for its value in
finding the RIGHT fixes to future bug discoveries.
This is very valuable. And very important. It is not
as urgent as the finalization process. Which means if
you can find a way to do it. Or if you can find away
to even approximate it. It should be done. It doesn't
have to be done immediately. It has to be done
eventually. Preferably sooner than later. But even
later is valuable. 

3) I am speaking up about it now because this is the
time to think of the plan to see it happen. Before the
 bridges are burnt.

 
> 
> shiping 3.9 with a .changes file of >25MB is
> impossible, too.

Sigh. I'm a programmer, I am used to frustration. That
usually happens just before a solution appears. I am a
good programmer. I'm not used to defeat. There must be
a way to handle both concerns. Ron Teitelbaum has made
a suggestion. Does it have any merit?



> 
> So what do you suggest?
> 
> 
>      Marcus
>
As my first reply ended:

I expect you merely to do your best.


Yours in service, --Jerome Peace 

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



More information about the Squeak-dev mailing list