[Morphic] Challenges: Maintaining Morphic

[Peace Jerome]

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 ] 
>
>------------------------------------------------------------------------
>
>
>On 25 juin 06, at 03:58, Peace Jerome wrote:
>
>> 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.
>
>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
>> 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.

- 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