On 22.10.2005, at 15:17, Cees De Groot wrote:

> On 10/22/05, Marcus Denker <denker at iam.unibe.ch> wrote:
>
>> Because we have a problem with making real ones...
>>
>
> Still - it begs the question: what is a 'real' image?
>

An image build in a way that we don't need to replace in in the  
future, and
build by taking the last one "load updates" and be done.

One of the problems right now is that the image is around 20MB large
after loading the latest from the repostory...

> I'm saying that I think it's a goal we should strive for. Note that
> I'm not saying this for the first time. And we've got some build-up of
> enthousiasm and the teams, I would hate to lose that because their
> work doesn't make a round trip quick enough to keep them
> enthousiastic..
>

Yes, I understand that. The problem is that there is suddenly comming
everything at once: The problems with actually putting out a new image,
having the traits guys looking at hundrets of methods one-by-one by  
hand,
and the tools Tools-Plus changes... (I gave up on integrating the  
changes
for method annotation and  the new compiler for now till the dust  
settles)

>
>> Another problem: I directly sent you a mail that it will take a while
>> to integrate your changes.
>>
>
> That's another issue the 39a team needs to work on, yes. Stef asked
> specifically to integrate this work. I spend half a day to do it, and
> then receive back from you a mail that it will take a while to
> integrate the work.
>

Sorry.

>
>> Andrian and Daniel spend *weeks* on that stuff, with "first come
>> first serverd" changes like these will never make it.
>>
>>
> Sure they will. At least, that's how I always did this sort of stuff
> (and I worked in some *very* complex environments, think supporting a
> matrix of 15 operating systems, 10 databases, and at least three
> branches of development): you branch for a big integration, and
> constantly feed back smaller patches from the trunk. In that way, you
> never wander off too far, nor lock the trunk because everyone has to
> wait for a big change (which seems to be the case now?).
>
> We tried the 'lock the trunk for a big change' approach a while, but
> it pissed off the developers. Now, in this corporate setting we could
> hold out for a while by just telling them to stop whining and go back
> to work, but somehow I think that in a volunteer setting this approach
> would be even less succesful :)
>

I am not up to speed with harvesting, so I everything need to be taken
a bit with a "I need to check that". But the problem with Traits is that
it changes the system in a way that can't be merged with Monticello.

I really need to check that...

>
>> it's not my day-job, so there is no way that I can
>> provide a 24h service.
>>
>>
> Fine with me. And I'm not saying we must provide 24h response
> overnight, just that I think for psychological reasons that 24-48h is
> something to strive for.
>

Ok. Back when harvesting was done with changesets and nobody cared
too much, we had a good reaction time in some cases... but mostly,  
reaction
time was *months* even for stuff like typos in class comments.

> And, I repeat - with your being busy, is there anything I can do? The
> last time I asked, I got the ToolBuilder/PlusTools stuff thrown at me,
> but that clearly wasn't the right thing to spend my (very precious)
> spare time on...

Sorry. The timing was just very unfortunate.

       Marcus