Defining the damn 3.9 process! (was Re: SqueakFoundation money)

[stéphane ducasse]

> On 12/8/05, goran at krampe.se <goran at krampe.se> wrote:
>> Now, *how* do we "feed" you guys? Do we throw them in your inbox  
>> *and*
>> send a corresponding mandatory email to the v3.9 list (seems
>> reasonable)?
>
> I think that a daily build of an alpha release should:
> - Grab latest versions of everything from inbox


Really!
You are joking :)
Have you looked recently at the inbox?

> - Copy them to v39a repository
I would not to that that way. We should not add broken stuff to v39a.

> - Update the image with them and spit out an updater which is  
> subsequently
>   pushed to the update stream;

Cees how many borken scripts have been issues for one working?
So we have to test it before. We cannot push that in the update  
stream without testing.

You will be able to do everything you want with it but after 3.9. We  
took the responsibility
of 3.9 ( I guess that after I will quit and suggest marcus to do the  
same because of his PhD ).

> - Run all unit tests and post the results to a webpage (a la
> Tinderbox, let's call it SqueakFire ;-)).
>
> And this done every night. It will be excruciatingly painful first,
> but my experience at Soops where they do this all the time has shown
> that once it settles down (like: actually runs most nights ;-)), it is
> of tremendous help.

I believe also in automated processes but if this would be that  
simple...
Imagine the integration of the ToolPlusBuilder.
Now I'm not against trying something but
	- I do not have the time to code it.
	- I do not want that we pollute 39a
	- I do not want that we pollute the update stream

>> And if this is a good process - when you decide to muck
>> about in our package :) how do you handle *us*?
>
> Not, in principle. Scenario: tewards team pushes package in inbox.
>
> Possibility A: XNext day, SqueakFire doesn't show your package - hey,
> it didn't load. Team can fix.
>
> Possibility B:  Next day, SqueakFire shows broken tests for new
> package - grab the latest image and go fix'em.
>
> Possibility C: Next day, SqueakFire shows all green for new package.
> Steward team goes out and parties.
>
> I want this to be an automated process. So badly, in fact, that it
> provided the proverbial last drop in the bucket for me renting a
> second private box at Hetzner whose abundant CPU power (Sempron64
> 3000+) will be available to host this stuff - at least until we know
> what the load etcetera is so we can move it to box2. And I hereby
> promise to blog less, spit out less mini packages, and put some
> serious effort into this iff this is a process we can agree on.

Sure blog less and let you build the process and we will follow it  
(if it works).

BTW I asked a student to build a test server for squeak.

> Where does this leave the team?
> - The team decides on what packages are in and not (and hunt down  
> Stewards);
> - The team should at least manage/drive harvesting of patches for
> packages that aren't Stewarded yet;
> - The team decides when it is time to 'slow down' and go into beta,
> where the process will stay roughly the same but the criteria for
> uploading to inbox may become stricter and a build is now and then
> taken from the 'daily build stream' which gets more rigorous testing
> so that it might be labeled as a public beta.
>
> That's my 2 cents ;-)

But without someone building it we will get what we have now.
And even with this process we need some times where some changes have  
the full control
since there are subtle dependencies. So what you describe works well  
for certain kind of changes
but not all of them.

Stef