Hannes raised an important question - where does time pressure come from?
He also raised another important question - why didn't we meet our stated goals?
I think these are important enough, they deserve answering, not arguing about them.
Time pressure comes from the nature and purpose of releases. One can say that any image at all of Squeak, with any combinations of changesets loaded, is a version of Squeak. What separates a release from any other version is that it's visible. All of it's natural and most important qualities come simply from that: it's rarity causes it to be visible.
It's important to remember that people measure the quality of an implementation mostly by it's releases - not by fixes/packages that can be loaded, because probably no two pair of people will apply the same ones. This is meant to change when we have configurations, but that's the way it is now.
What that means, is that right now, people measure us by 3.2. Most everyone on the list knows of SM, and loaded it for their 3.2, or just uses 3.4, which is nicely stable enough to load anything that doesn't touch the core as Island or Traits do. So we don't suffer much from the delay of this release. Or rather, not directly. Because newbies surely do. To newbies, loading anything into Squeak is still quite complicated, and the first thing they're likely to be told is not to use the official release, but a development release.
That's a sign of a project that's not releasing often enough. If your production and your development are very different, you stop feeling the pains of the production, and you stop being aware of what your product is like, and you focus on the wrong things.
If we have bugs (and we have more than just those handful that were mentioned), the solution isn't to delay the release, it is to have SUnit tests, use them, and keep them green. Think longer term - it's not about making a perfect release - that'll always be a good excuse to delay a little more. It's about having many releases, at quite frequent, predictable intervals, that are getting better and better, and keeping production and development close. That'll give us long term properties that will keep Squeak getting better.
And no, I don't promise to never break anything that's worked before. First, nobody's ever promised that, neither the previous regime, nor any other maintainer except maybe Knuth. Second, the main technical benefit of an open source project is parallelized testing/debugging. But that is completely dependent on people actually doing it. Third, to promise strictly monotone-improving releases, I'd need SUnit tests with every change that gets submitted. Hmm :-)
Now, why didn't all of the refactorings get in? well, there's a page on squeakfoundation swiki, devoted to the status of the intended refactorings. They're almost all done and waiting for (come on, I'm sure you know - ) testing. When people want to see them get in, they'll start testing, and as soon as people tell their authors that they load, or they don't load, or there's this problem or that or it's all very nice, we can actually do the work of clearing them to get in the image. In 3.5, of course.
Why didn't we meet our goals? because the goals we stated and the actions of the wider community were not in line. I'm not shocked - this is a community, not an army unit. Also, the new "regime" is pretty new, so us and said community are still getting used to each other. Having alot of these releases, a time when emotions run high and soul searching is popular, will make the adaptation go faster.
Daniel
Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote:
Roel Wuyts roel.wuyts@iam.unibe.ch wrote:
Somebody needs to decide what is a release and what's get in there, and it was decided that these were the Guides. I trust them to do an excellent job at this, that is why they are responsible. I can imagine that there is some 'bigger plan' for which they want to have this release. The question for me is: 'what is this bigger plan'. If it is only that it was promised to have a new release by a certain time, then I agree with you that we can wait. But I guess the plan for 3.4 was to have SM up and running, and that is also important to get out so that everybody can enjoy it.
Yes, adding SM and not breaking existing things.
<citation> 3.4 -- The main purpose of this release is to create an up to date, viable version, that's a good starting point to making Squeak more modular and it's development more decentralized.
Changes:
- Includes non-modules related updates from 3.3a, including the dynamic
filelist services refactoring.
- An option to load the SqueakMap package catalog and the base Package
Loader from the net.
- A dynamic open menu so packages can now register there and become
first class applications.
- Refactorings making various parts of the image easily removable. See
Modularizing the Squeak image for the plan and status.
- Various other fixes have been included.
Release is tentatively set to end of 2002.
</citation>
Regarding "Refactoring making various packages easily removable":
There is just Balloon3DRemoval and GamesRemoval. I do not consider this goal is met.
And breaking an important thing and not including the fix is surely not good stewardship as well.
Again: Where does this time pressure at the expense of quality come from?
Cheers Hannes _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Daniel Vainsencher danielv@netvision.net.il writes:
If we have bugs (and we have more than just those handful that were mentioned), the solution isn't to delay the release, it is to have SUnit tests, use them, and keep them green. Think longer term - it's not about making a perfect release - that'll always be a good excuse to delay a little more. It's about having many releases, at quite frequent, predictable intervals, that are getting better and better, and keeping production and development close. That'll give us long term properties that will keep Squeak getting better.
+1, well said.
I've found releasing on the first of every month to be a useful discipline. What changes would be needed to make this practical for squeak, I wonder ? Maybe none.
Thanks for your work, guides. -Simon
On Fri, 2003-02-28 at 17:56, Simon Michael wrote:
+1, well said.
seconded.
I've found releasing on the first of every month to be a useful discipline. What changes would be needed to make this practical for squeak, I wonder ? Maybe none.
Yup - we've taken to release an RC every Thursday at 13:30, and when no showstoppers have been found by Friday 18:00, it is moved into production. I think a similar time regime could put the necessary pressure on the cooker to help here in cleaning up procedure (it surely helped with us!).
Probably a quarterly regime would work fine. Announce a gamma release one month before the end of the cycle (and fork there so development continues), and make abundantly sure that whatever happens, it is going to be the production version one month later. This shifts quite a bit of the responsibility for testing back to where it belongs: the users a.k.a. the Squeak community.
On Friday, February 28, 2003, at 11:56 AM, Simon Michael wrote:
... I've found releasing on the first of every month to be a useful discipline. What changes would be needed to make this practical for squeak, I wonder ? Maybe none.
I think releasing every month probably isn't realistic, and I'm not sure it's a good idea anyway.
One problem is that I don't think we'd be able to do it very soon and still keep a reasonable level of quality in the releases. To attain a release cycle that rapid, with such short beta/gamma stages, we'd probably need to have unit tests for the whole image to ensure that stuff wasn't breaking. We're not too close to that point yet. (I agree there are some advantages to a rapid release cycle, though.)
Another problem is that I'm not sure a monthly release with new features in every release is desirable for a public "stable" software release, even if they are relatively bug-free.
For example, let's say Squeak 3.5 is released in April, 3.6 in May, 3.7 in June, 3.8 in July, etc., through 4.3 in December. This would require that people who try to write production-quality packages for Squeak would constantly have to test their packages to make sure they work with the latest version.
Or, the owner of package X may not bother and just test it with 3.7 and declare it compatible with that. Package Y may also be written during the summertime but its maintainer may have used 3.9 instead. Then, if some user wants to use package X and package Y together, they wouldn't be able to. (Or, they would have to at least do some testing to see if package X still worked in 3.9, which is some effort/worry to deal with.)
Some of these problems might be lessened by having the image split up into packages with a powerful dependencies scheme in place. (with compatibility ranges and that sort of thing)
But it still seems that you'd just have too many versions out there for people to make sense of. :-) Are there any open-source projects out there which come out with a (non-alpha/non-testing) release as often as every month? To me, a monthly release makes a lot of sense for something that is still in development, or perhaps for a level of user somewhere in between bleeding-edge-alpha tester and stable-product-only user. I believe Debian has something like that.
Whether a one-time one-month release is appropriate for 3.5 is a different question, for a different email. :-)
- Doug Way
squeak-dev@lists.squeakfoundation.org
-
Cees de Groot -
Daniel Vainsencher -
Doug Way -
Simon Michael