Challenges: Maintaining Morphic

What is the status of the morphic group now?

We've all been quiet for quite some time.

I've been doing what I do on mantis. Fixing bugs and
waiting for them to get included in 3dot9. The process
for this seems to have stalled.

It is my understanding:

1) Juan (and Marcus) have both  given up their
responsibilities.
 
Up til then, I've counted on them to harvest the
change sets and incorperate them into the Monticello
packages.

2) Stef has all the world on his shoulders and has not
focused his energy yet on harvesting morpic fixes.

3) He has asked others (myself included) to take over
the responsibility of gathering cs's into the mcz
packages.

4) I am too ignorant of Monticello's ins and outs to
take on a task of that magnitude.

5) I am now feeling uncomfortable with the delay of
getting the fixes into the image. It would be nice to
see the annoying green color buttons now turn
corrected. The changeset is there to do it. It just
needs to be taken to the next stage.

6) My curiosity has gotten me to study why I am
objecting to learning MC. And I am generating a list
of my concerns with the current process.

7) The summary is to me it does not seem "safe" to
learn. Here safe means learning should not "waste a
lot of productive time"

8) Part of the reason is due to my particular
circumstances. I work in a solitary fashion. Running
into a diffuculty  usually means putting that project
aside until such time as a clue pops up that allows
further progress. The clue can arrive in a matter of
days but it often takes months to overcome my
ignorance.

9) Part of the reason, in the context of maintaining
morphic, is the morphic packages are large relative to
what can be handled gracefully by Monticello.

10) So one of the useful tasks (for the morphic group)
would be to whittle them down by attrition. Identify
leaf Classes which don't have other classes depending
on them and move them to thier own Morphic subpackage
(assuming Monticello allows this)

Now this is probably not something that meshes with
the beta phase. Still it is the direction morphic
needs to go in if it is to become easy to maintain
with Monticello tools.

And it is the one part of the problem that deserse to
be considered by the followers of this list.

10a) How can we find out which Classes are leaf
classes?
10b) How can they be packaged and removed from morphic
or morphic extras?
10c) Are there more rational ways to split morphic
into maintainable pieces? In other words what is the
natural structure of morphic?




Well, that took longer to explain than I thought. I
realize this a lengthy post. I beiieve everything here
needs to be seen and considered together to make
sense.


Please feel free to pick any piece of it that
interests you an reply to that. Please modify the
"Subject:" to aid clarity.

Yours in service, --Jerome Peace











__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic

On 25 juin 06, at 03:58, Peace Jerome wrote:

They will not do it.
This is why I told you that if you want to help me producing
mcz file would help to harvest the changes.
But this is not complex and if you fail we can use CS.
I encourage you to try.
>
> 5) I am now feeling uncomfortable with the delay of
> getting the fixes into the image. It would be nice to
> see the annoying green color buttons now turn
> corrected. The changeset is there to do it. It just
> needs to be taken to the next stage.

Yes I know but I moved to france and they cut my network connection  
too early.
And marcus told me that in beta we should only focus on big really  
urgent fixes.
So I could harvest more than the urgent but the fixes should be simple.

>
> 6) My curiosity has gotten me to study why I am
> objecting to learning MC. And I am generating a list
> of my concerns with the current process.

:)
Good meta process.

> 7) The summary is to me it does not seem "safe" to
> learn. Here safe means learning should not "waste a
> lot of productive time"

Fun all the development of pier, magritte, smallwiki, seaside... is done
with MC and I think that they believe the inverse.
>
> 8) Part of the reason is due to my particular
> circumstances. I work in a solitary fashion. Running
> into a diffuculty  usually means putting that project
> aside until such time as a clue pops up that allows
> further progress. The clue can arrive in a matter of
> days but it often takes months to overcome my
> ignorance.

Sure me too. But the best is to ask in the mailing-list.
I'm sure MC user will be ready to help.

> 9) Part of the reason, in the context of maintaining
> morphic, is the morphic packages are large relative to
> what can be handled gracefully by Monticello.


We manage Squeak with MC. Of course this is not that easy
because something modifying morphic while it is running is a pain
(reordering cs by hand) and in addition MC does not hep for that.
But MC 2 will certainly

> 10) So one of the useful tasks (for the morphic group)
> would be to whittle them down by attrition. Identify
> leaf Classes which don't have other classes depending
> on them and move them to thier own Morphic subpackage
> (assuming Monticello allows this)

I would just create packages of classes that we can throw away and also
publish smaller packages.

Good question.
I suggest you to start reading the classes of category  and see if  
they make sense together.
The problem is not only with leaves but also with some bad quality  
(BookMorph and superclasses).

So I would start to build a map.


_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic

Hi Stef,

Thanks for replying to my post.


>[Morphic] Challenges: Maintaining Morphic
>Stéphane Ducasse stephane.ducasse at univ-savoie.fr
>Tue Jun 27 10:14:31 UTC 2006 wrote:
>
>
>* Previous message: [Morphic] Challenges: Maintaining
Morphic
>* Messages sorted by: [ date ] [ thread ] [ subject ]
[ author ] and
>> waiting for them to get included in 3dot9. The
process
>> for this seems to have stalled.
>>
>> It is my understanding:
>>
>> 1) Juan (and Marcus) have both given up their
>> responsibilities.
>>
>> Up til then, I've counted on them to harvest the
>> change sets and incorperate them into the
Monticello
>> packages.
>
>They will not do it.

Yes. That was my understanding.

As they have had the most experience with this
process, I wonder if they quit because it is too much
trouble?  My perception is that morphic is a
particularly bad candidate for MC maintainence. At the
present state of the packaging of morphic. And the
present stage of development of MC. MC2 may be another
story.

>This is why I told you that if you want to help me
producing
>mcz file would help to harvest the changes.

As I have said my ignorance of the ins and outs of MC
prevent doing this on any large scale project.  It’s
too easy to wash away large amounts of time for too
little gain.

I am learning MC by maintaining small packages.
KaleidoStar is only two classes and some extentions.
It is ok to maintain in MC and I am doing so.

The decision to use MC to maintain squeak was 3dot9’s.
I believe it was not a wise choice. Too few are ready
or able to come forward and help you with this means
of maintainence. I am sorry all the work falls on you.
You brought that situation on yourself with the
decision to use new and still developing tools.  



 

>>
>> 2) Stef has all the world on his shoulders and has
not
>> focused his energy yet on harvesting morpic fixes.
>>
>> 3) He has asked others (myself included) to take
over
>> the responsibility of gathering cs's into the mcz
>> packages.
>>
>> 4) I am too ignorant of Monticello's ins and outs
to
>> take on a task of that magnitude.
>
>But this is not complex and if you fail we can use
CS.
>I encourage you to try.

It is not a good statagy to learn anything in large
projects. Small projects protect you from the
concequences of your errors.  One of my objections to
MC is it does not allow for the graceful learning from
mistakes. Its punishments are too harsh.

I am a firm believer in McCready’s Gossamer Condor and
its construction methods. It is absolutely necessary
to have the shortest test-modify-test cycle.
Especially for iterating and developing elegant code.


>>
>> 5) I am now feeling uncomfortable with the delay of
>> getting the fixes into the image. It would be nice
to
>> see the annoying green color buttons now turn
>> corrected. The changeset is there to do it. It just
>> needs to be taken to the next stage.
>
>Yes I know but I moved to france and they cut my
network connection  
>too early.
>And marcus told me that in beta we should only focus
on big really  
>urgent fixes.
>So I could harvest more than the urgent but the fixes
should be simple.

That’s fine.  You should do as you see fit.  The green
button fix I would make “urgent” because it is very
noticable and many people have and will complain about
it. The fix will stop the stream of complaints.  Which
will save time.

I broke it. I fixed what I broke. I’ll leave it to you
to decide when to harvest it.


>
>>
>> 6) My curiosity has gotten me to study why I am
>> objecting to learning MC. And I am generating a
list seaside... is done
>with MC and I think that they believe the inverse.

- MC works better on leaf projects. Morphic is a
Maintenence project with lots of legacy code.
Different beast entirely.

- They have a different knowledge base than I.  Some
of them are co-developers of MC so if something
bothers them they fix it in MC and if it doesn’t they
don’t.

- My thesis is that MC and changesets and other
fileouts should be able to interoperate easily. The
fact that they don’t is why we are having this
discussion.  MC locks you out of developing with
change sets and it shouldn’t.  


>>
>> 8) Part of the reason is due to my particular
>> circumstances. I work in a solitary fashion.
Running
>> into a diffuculty  usually means putting that
project
>> aside until such time as a clue pops up that allows
>> further progress. The clue can arrive in a matter
of
>> days but it often takes months to overcome my
>> ignorance.
>
>Sure me too. But the best is to ask in the
mailing-list.
>I'm sure MC user will be ready to help.

When I can formulate a question I do that.  Usually
Andreas get there first. I just read answers to his
posts.
>
>> 9) Part of the reason, in the context of
maintaining
>> morphic, is the morphic packages are large relative
to
>> what can be handled gracefully by Monticello.
>
>
>We manage Squeak with MC. Of course this is not that
easy
>because something modifying morphic while it is
running is a pain
>(reordering cs by hand) and in addition MC does not
hep for that.
>But MC 2 will certainly

Yes but MC2 is not ready yet.  And relying on it runs
you into rule 33.
>
>> 10) So one of the useful tasks (for the morphic
group)
>> would be to whittle them down by attrition.
Identify
>> leaf Classes which don't have other classes
depending
>> on them and move them to thier own Morphic
subpackage
>> (assuming Monticello allows this)
>
>I would just create packages of classes that we can
throw away and also
>publish smaller packages.

I don’t understand.  How do you distinguish these
classes? How do you identify the smaller packages?
>
>> Now this is probably not something that meshes with
>> the beta phase. Still it is the direction morphic
>> needs to go in if it is to become easy to maintain
>> with Monticello tools.
>>
>> And it is the one part of the problem that deserse
to
>> be considered by the followers of this list.
>>
>> 10a) How can we find out which Classes are leaf
>> classes?
>> 10b) How can they be packaged and removed from
morphic
>> or morphic extras?
>> 10c) Are there more rational ways to split morphic
>> into maintainable pieces? In other words what is
the
>> natural structure of morphic?
>
>Good question.
>I suggest you to start reading the classes of
category  and see if  
>they make sense together.

 Again, I don’t understand. What do you mean by the
classes of catagory?

>The problem is not only with leaves but also with
some bad quality  
>(BookMorph and superclasses).

The leaves are not a problem they are a path to the
solution.

Package them and what is left are the problem classes.

Detangle and refactor those.
Package the new leaf classes.
Iterate till done.

Nothing has to be done all at once.  Small steps and
steady improvement.

What I don’t know right now is if a myriad of packages
is easier to maintain than a large package. I would
guess yes.
If the facts prove me wrong then we take the small
packages and combine them till they are just the right
size.  Goldilock’s style.

>
>So I would start to build a map.

Yes. How?


Yours in service, -- Jerome Peace

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic

Hi Jerome.

You are right: I'm not maintining the Morphic packages anymore. Why?
Well, I didn't like what Morphic became, although I always loved how it
was when young. So I decided to help clean it. This was the start of
MorphicSplitters and later the Morphic team. I did a first stage of
splitting Morphic in packages, as you can see in 3.9. But the second
stage proved too much work for me. It would take me many years.
Literally. So, I lost my faith on that path. I'm rewriting a small
Morphic kernel outside the official image (as you know). I lost my main
reason for managing the official Morphic packages.

You seem to be pretty interested in fixing and enhancing the official
Morphic. In fact, you are the guy who worked more than anyone else in
Morphic this year. I find quite natural that you build the Morphic
packages. I would be very happy with that.

WRT MC, all I can say is that right now you have more knowledge and
experience with it than I had when the Morphic team was formed.

Cheers,
Juan


Peace Jerome escribió:
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic

>Date: Thu, 29 Jun 2006 08:56:05 -0300
>From: Juan Vuletich  wrote:
>Subject:

>
>Hi Jerome.
>
>You are right: I'm not maintining the Morphic
packages anymore. Why?
>Well, I didn't like what Morphic became, although I
always loved how it
>was when young. So I decided to help clean it. This
was the start of
>MorphicSplitters and later the Morphic team. I did a
first stage of
>splitting Morphic in packages, as you can see in 3.9.
But the second
>stage proved too much work for me. It would take me
many years.
>Literally. So, I lost my faith on that path. I'm
rewriting a small
>Morphic kernel outside the official image (as you
know).

>I lost my main reason for managing the official
Morphic packages.

I just want to say I appreciate all the help you gave
in getting my stuff into 3dot9. I know it was a lot of
time and work and  appreciate the responsibility you
took for the Morphic group and how you carried it out.


>You seem to be pretty interested in fixing and
enhancing the official
>Morphic. In fact, you are the guy who worked more
than anyone else in
>Morphic this year. I find quite natural that you
build the Morphic
>packages. I would be very happy with that.

It is not something my heart tells me to take on.  I
like what I am doing now. Focusing on the small and
the doable and the problems that are interesting to my
curiosity.  The morphic packages are right now too big
to maintain.  As I wrote in my follow up note to Stef,
I believe they can be whittled down over time and the
task made more doable.

It will take more hearts and hands than mine if it is
to happen. Which is one reason for starting this
thread.  Your response and Stef’s passes the first
test.  If I got ignored it would have meant something
different.  Now to see if there is enough energy out
there to take this group in a useful direction.

>
>WRT MC, all I can say is that right now you have more
knowledge and
>experience with it than I had when the Morphic team
was formed.

Different sets of knowledge.  I took small pieces and
delved into them till I understood them.  I did not
look at the overall shape of morphic.  So we have
brought different sets of knowledge to bear.

Thanks for your help and encouragement.

Yours in service, -- Jerome Peace
 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
Morphic mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic