Dear Ralph,
I think movments like the one you are exposing here adds value to the whole Squeak as project. Also adds value to all Smalltlak as a consequence.
I'm pretty sure that the projects that will emerge, based on Squeak versions like that, eventually will gain a lot more value just because of that. Very healthy initiative.
If the objetives can be archieved, it can be useful as support of a wisely defined marketing strategy campaing (just for reference: http://www.4hb.com/0107flmarketingcampaign.html).
Cheers,
Sebastian Sastre
ssastre@seaswork.com.ar Seaswork Special Software Solutions
Este mensaje y sus adjuntos son confidenciales y de uso exclusivo para el usuario a quien esta dirigido. Puede contener información amparada por el secreto profesional. Si Ud. no es el destinatario especificado no debe copiar, enviar o utilizar ninguna parte del mismo y/o de sus adjuntos por ningún medio tecnológico. Las opiniones vertidas son responsabilidad del autor y no son emitidas ni avaladas por SEASWORK a menos que se indique claramente lo contrario y que la identidad y autoridad del autor, para comprometer a nuestra empresa, puedan ser verificados. No se garantiza la integridad de los mensajes enviados por e-mail ni que los mismos sean enviados en termino, o que no contengan errores o virus. El emisor no aceptara responsabilidad por los errores, modificaciones u omisiones que resulten en el mensaje, bajo la hipótesis de que pudo ser modificado.
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] 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