Hi Edgar -

On 4/5/2010 2:11 PM, Edgar J. De Cleene wrote:
> I consider myself in Ostracism, so no mails and no discuss.

Sorry, I've never heard the term, can you explain what it means?

> If people do not like warnings about broken code or different ways of doing,
> no point in bother you.

I don't think that's true. As far as I can tell reports about broken 
code generally have been responded to quickly and directly. Now is a 
particularly good time report any issues because we're trying to get 4.1 
done, so if you have any issues please report them!

> If I send mail here is about Squeak is more as one of us as individuals and
> more as the new SOB.
>
> I send some mails private about I was nominated Release Manager and several
> concerns I have.
>
> Repeat , I wish do the release.

I'm not sure how to respond to this without upsetting you but I'll try.

First of all, thank you for offering your help. I really do appreciate 
it. However, the commitment to be a release manager comes with some 
responsibilities, namely goals, milestones, and schedules. For 4.0 the 
goal was relicensing, for 4.1 it is to push out all the changes that 
happened during relicensing. The goals for 4.2 haven't been decided yet 
but there is a great opportunity right after 4.1 goes out to bring up 
some interesting ideas.

Unfortunately, after you announced your interest in being release 
manager nothing visible happened. Several weeks passed during which I 
had expected you to show some activity to move the next release forward 
- be that gathering a release team, or coming up with a set of tasks 
that need to be done, or providing even a rough time line. None of that 
happened.

I think that the lack of any visible progress was partly what led to the 
enthusiastic response of making a short, time-boxed 4.1 release instead 
of dragging on in an unclear time frame with unclear goals. I wrote my 
4.1 schedule proposal partly as an example for others to understand that 
a release needs goals, milestones, and schedules. In this very message I 
also asked you whether you'd like to manage the release under those 
circumstances and with such a short time line. That was 18 days ago.

As I'm sure you can imagine, it's impossible to make a release in four 
weeks if three of them are spent with waiting on an individual's 
response to the question of whether they'd like to manage the release. 
My expectation had been that if you wanted to manage that release you 
would come back within less than a week to clarify your position (even 
if that were only by disagreeing with the proposal). I understood your 
silence to be an expression of disinterest, and consequently started to 
move things forward.

Given how far ahead we are on the release track to 4.1 I think it's 
unwise to change the process in the middle. Assuming all goes as 
planned, we're two weeks away from 4.1 final and I think we should move 
on with the release as planned. Of course, your help in the release 
process is welcome.

One thing that would be really helpful is if you could formulate more of 
the goals you have with managing a release. I think you're trying to do 
a few things differently, but so far you haven't really told the 
community what you're planning to do and why. It would be good if you 
could formulate what you're trying to achieve.

In short, my take is that we should move 4.1 forward as planned with the 
goal to release it in about two weeks. Your help in this process is very 
welcome, there are plenty of tasks to help with, for example testing 
SqueakLight or any of your other projects with 4.1 and reporting back 
any issues. For 4.2 the discussion is wide open, and I'd encourage you 
to formulate which changes you'd like to see take place.

> Let 4.0 have 4.0.1 and feed 4.0.1 with all initial steps before Closures and
> freeze image here.

What we can do easily is to provide an update that puts you onto the 
"trunk path" so that anyone updating from 4.0 gets all the necessary 
stuff to load updates from the trunk. The process itself will not be 
free of some manual labor but we can simplify it by adding those few 
bits initially. Is that what you're asking for?

> 4.0 ends in 7159 .Say the step when Closures comes is 7200.
> At this points , the life of 4.0.1 ends and new sources and empty changes
> must be done.
>
> Again I beg let 4.1 have dual way of updates.
> Plain old real .cs in his updates folder as others forks like Cuis have.

I don't understand the value of providing change sets separately. Given 
that all the changes come in via Monticello why is using a change set an 
advantage? Monticello may not be perfect but in particular when merging 
distant ancestors Monticello is far superior than change sets.

Is there perhaps some other issue that you haven't mentioned and where 
you see change sets as a possible solution? If so, could you elaborate 
on that problem? There's a good chance that we may be able to come up 
with a solution to that problem that doesn't involve producing change 
sets from Monticello.

> May I do the release? Or must stick to my fork ?

These aren't your only options. You can contribute to the current 
release, and you can start the discussion about the next one. There 
isn't only black and white there are many shades of gray to choose from :-)

Cheers,
   - Andreas