release team proposal

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On
> Behalf Of Ralph Johnson
> Sent: Thursday, November 23, 2006 10:06 AM
> To: The general-purpose Squeak developers list
> Subject: release team proposal
>
> Here is the proposal I sent to the Squeak board.
> ----------------
> The Squeak 3.10 release team is going to focus on developing
> a simple, visible and reliable process for creating new releases.
>
> The alpha 3.10 release will have an image and a set of core packages.
> Each will have a test suite, and all tests in the test suites
> will pass when any subset of the packages is loaded into the
> image.  Each subsequent version will continue to keep the
> existing packages working.
>
> We expect the alpha release and all later releases to be
> usable.  We want people to feel comfortable using the latest
> version so that 3.10 will be heavily used long before the
> final version and most bugs will be discovered.
>
> Our plan is to have the alpha release by the end of January
> and to accept major changes  for the next three months, i.e.
> til the end of April.  "Major changes" will include moving
> code from the image into packages and making new core
> packages.  We are not expecting any major new features in the
> image.  The last month will be only bug fixes, and a final
> version of 3.10 will be the end of May.
>
> The main focus will be on developing a good process for
> creating releases.  So, we expect to experiment with the
> process.  Ideally, the final process would be so easy to
> follow that it would be easy to be in charge of producing a release.
>
> The current process plan is that all requests for change
> would go through Mantis.  Each bug fix would have a test that
> shows the bug and that shows that it is fixed.  The release
> team would periodically (once or twice a week, perhaps every
> day) go through Mantis, test each change to make sure it
> doesn't break anything, and commit them to the current release.
>
> The releases would be distributed in several ways.
> There will be a "package universe" of all the core packages,
> and perhaps one of non-core packages, as well. There will be
> an update server so that people do not have to load new
> images to stay up to date.  There will be a Montecello  
> repository of all the changes so that everything we do will
> be repeatable.
> We will try to make it easy for people to use the release
> that is under active development.
>
> Current members of the release team are Ralph Johnson and
> Edgar J. De Cleeene.
> --------------
> Reading it again, I can think of some comments.
>
> The main one is that this is explaining what the Squeak team
> will do, which is to develop a process for making releases
> and shrinking the image.  Part of the process is making it
> easy for other people to fix bugs and add features.  I am not
> opposed to adding features!
> You could think that from this proposal. I just think that
> adding features should be what everybody does, not just the
> release team.
>
> As part of fixing the process, a large part of my job will be
> getting people to participate.  I expect that the social
> engineering will be more work than the software engineering.  
> The software engineering is, in my opinion, very standard and
> routine, though I am sure I will get some argument about
> that.  The social engineering will require more creativity.
>
> -Ralph
>

>From: "Ralph Johnson" <[hidden email]>
>Reply-To: The general-purpose Squeak developers
>list<[hidden email]>
>To: "The general-purpose Squeak developers
>list"<[hidden email]>
>Subject: release team proposal
>Date: Thu, 23 Nov 2006 06:06:00 -0600
>
>Here is the proposal I sent to the Squeak board.
>----------------
>The Squeak 3.10 release team is going to focus on developing a simple,
>visible and reliable process for creating new releases.
>
>The alpha 3.10 release will have an image and a set of core packages.
>Each will have a test suite, and all tests in the test suites will
>pass when any subset of the packages is loaded into the image.  Each
>subsequent version will continue to keep the existing packages
>working.
>
>We expect the alpha release and all later releases to be usable.  We
>want people to feel comfortable using the latest version so that 3.10
>will be heavily used long before the final version and most bugs will
>be discovered.
>
>Our plan is to have the alpha release by the end of January and to
>accept major changes  for the next three months, i.e. til the end of
>April.  "Major changes" will include moving code from the image into
>packages and making new core packages.  We are not expecting
>any major new features in the image.  The last month will be only bug
>fixes, and a final version of 3.10 will be the end of May.
>
>The main focus will be on developing a good process for creating
>releases.  So, we expect to experiment with the process.  Ideally, the
>final process would be so easy to follow that it would be easy to be
>in charge of producing a release.
>
>The current process plan is that all requests for change would go
>through Mantis.  Each bug fix would have a test that shows the bug
>and that shows that it is fixed.  The release team would periodically
>(once or twice a week, perhaps every day) go through Mantis,
>test each change to make sure it doesn't break anything, and commit
>them to the current release.
>
>The releases would be distributed in several ways.
>There will be a "package universe" of all the core packages,
>and perhaps one of non-core packages, as well. There will be
>an update server so that people do not have to load new images
>to stay up to date.  There will be a Montecello  repository of all
>the changes so that everything we do will be repeatable.
>We will try to make it easy for people to use the
>release that is under active development.
>
>Current members of the release team are Ralph Johnson and
>Edgar J. De Cleeene.
>--------------
>Reading it again, I can think of some comments.
>
>The main one is that this is explaining what the Squeak team will do,
>which is to develop a process for making releases and shrinking the
>image.  Part of the process is making it easy for other people to
>fix bugs and add features.  I am not opposed to adding features!
>You could think that from this proposal. I just think that adding
>features should be what everybody does, not just the release team.
>
>As part of fixing the process, a large part of my job will be getting
>people to participate.  I expect that the social engineering will be
>more work than the software engineering.  The software engineering
>is, in my opinion, very standard and routine, though I am sure I will
>get some argument about that.  The social engineering will require
>more creativity.
>
>-Ralph
>

> On 11/23/06, Klaus D. Witzel <[hidden email]> wrote:
>> I appreciate your initiative and would like to know more about what you
>> consider to be a core package and, what is the resulting image when you
>> subtract all the core packages. Do I have to understand this being based
>> on a kernel image and, what about Pavel's kernel image?
>
> Are you asking "what are we going to subtract"?  I do not know.  I
> would like to see anything subtracted that can then be added back in.
> Lots of people are interested in splitting eToys into a separate
> package.  I don't think anybody will argue with this as long as it can
> be loaded back in.  However, I do not think of that as necessarily
> being a release team responsibility.  Pavel Krivanek is working on
> eToys and seems to be doing a good job.  In general, we are going to
> focus on the process of transforming the image in such a way that
> other programs are affected as little as possible.  We'll emphasize
> supporting other people making transformations and not plan to do it
> all ourselves.
>
> If I made a list of things that should be separate packages, it would
> look a lot like other people's lists.  I want the release team to
> focus on the *process* of splitting the image into packages, not the
> particular set of packages.  You can't have a good process unless you
> practice it constantly, so we will make packages as well as helping
> other people make packages.  My guess is that other people will do the
> high-impact, high visibility packages, and I will do the boring ones.
> Edgar is working with Pavel on eToys and Morphic, but that is too big
> a project for me right now.
>
>> > Each bug fix would have a test that shows the bug
>> > and that shows that it is fixed.
>>
>> What about non-bugs, like for example performance issues. Or do you
>> count
>> them to the bug category.
>
> New changes shouldn't break any of the existing tests.  I suppose that
> some
> of them will come with their own tests, and some won't.  It would be
> good for
> Squeak to have more tests, but we are not going to be hard on people
> about
> this.
>
> -Ralph
>
>

> I am far from a Monticello expert, but I have been looking at the  
> code.
> It looks to me that class PackageLoader could be changed to load  
> atomically.
> Basically, instead of making one pass through MCDefinitions (such as
> MCMethodDefinition, MCCLassDefinition and MCScript) and loading each
> one, the PackageLoader should first make a pass doing a preload and  
> then
> a pass doing a load.  Classes will be loaded during the preload and
> methods will be compiled during the preload, but actually installed  
> during
> the load.This would mean that you wouldn't run the compiler during the
> actualy loading of methods.  Something similar would have to be done
> for unloading.
>
> Do people who know more about MC than I do think this  would work?
>

> Second
> Problem, I am struggling to work out how to test my new code fully.
>
> 1. It turns out that the millisecondClockValue supplied by the vm, is
> one of those SmallInteger things which will roll over every once in a
> while. One needs to set up the scenario just before and after the roll
> over in order to see that everything is handled smoothly.
>
> 2. I have organised this implementation around a call
> #milliSecondsSinceMidnight, and it is necessary to test that the
> transition from 23:59.59 to 00:00.00 also goes smoothly.
>
> So within my test environment I have no control over the vm's
> millisecondClock. Secondly all of the interesting things, like timing
> offsets are stored in Class variables so my test code can't really
> mess with them. The best I can probably manage is to test the
> 'algorithm' and hope for the best. Any ideas?

> On 11/24/06, Keith Hodges <[hidden email]> wrote:
>> I put forward some work I am doing as a kind of example scenario, how
>> would the process handle this one, kind of thing.
>
>> I am looking at pulling together some recent tweaks and bug fixes to the
>> DateAndTime code. (see mantis 474 which doesnt have my final code as yet
>> , see below).
>
>> Atomic loading might help, since loading in code that modifies
>> DateAndTime-#now, really upsets the code that is loading and time
>> stamping the newly installed methods as they are compiled. As soon as
>> someone calls #now, before the class is fully loaded and importantly
>> before the class has been initialized we crash and burn.
>
> i don't know the answer to this, but I will guess.
>
> I am far from a Monticello expert, but I have been looking at the code.
> It looks to me that class PackageLoader could be changed to load
> atomically.
> Basically, instead of making one pass through MCDefinitions (such as
> MCMethodDefinition, MCCLassDefinition and MCScript) and loading each
> one, the PackageLoader should first make a pass doing a preload and then
> a pass doing a load.  Classes will be loaded during the preload and
> methods will be compiled during the preload, but actually installed during
> the load.This would mean that you wouldn't run the compiler during the
> actualy loading of methods.  Something similar would have to be done
> for unloading.
>
> Do people who know more about MC than I do think this  would work?
>
>> Second Problem, I am struggling to work out how to test my new code
>> fully.
>
> No code is every tested fully.  The question is whether it is tested
> enough.
> Perhaps you should settle for less complete tests.
>
>> 1. It turns out that the millisecondClockValue supplied by the vm, is
>> one of those SmallInteger things which will roll over every once in a
>> while. One needs to set up the scenario just before and after the roll
>> over in order to see that everything is handled smoothly.
>
> Mock up the millisecondClockValue from the VM.  Make a little "clock"
> object that you can replace with a mock object for testing.
>
>> 2. I have organised this implementation around a call
>> #milliSecondsSinceMidnight, and it is necessary to test that the
>> transition from 23:59.59 to 00:00.00 also goes smoothly.
>>
>> So within my test environment I have no control over the vm's
>> millisecondClock. Secondly all of the interesting things, like timing
>> offsets are stored in Class variables so my test code can't really mess
>> with them. The best I can probably manage is to test the 'algorithm' and
>> hope for the best. Any ideas?
>
> Mock these as well.  Redesign the class so it is easy to test.
>
> Or just have easier tests.
>
> -Ralph
>
>