FWIW I am 100% behind "release often, integrate as soon as possible". Not only this but you only have to do a small amount of googling to begin to realise that *finally* the computing world is getting the sea change required to make this approach the main stream, rather than the BUF* (release planning in this case). I'm not trying to invalidate people taking other approaches: I simply don't think they're the best way to do things. If those people working hard on Pharo can stick to the guns of this approach (and it's not an easy approach), I think it will be the right one. I'm sorry I don't have more time to give myself, but I try to keep myself useful from time to time. Cheers, Simon On 29 Sep 2008, at 20:55, Keith Hodges wrote:
Release image? that means, you will not close *any* bug-report until you release 3.11? Wow. But you sure close at least duplicated bug-reports? Wow what? The release will know which bug fixes are included and provide a list of fixes which can be closed, when the release is actually ready and available.
Everything that I have been developing loads into "all" existing images, so for example, LPF may want to load fixes into 3.7 if it needs something.
So does this make sense? I think there is not enough manpower to even get *one* stable and *one* development branch going. Beeing backtward compatible to such old releases makes no sense. So why does Seaside, Magma etc run in older images?
Please think sensibly, we are not trying to make "everything" work in all images. Just to enable the things that we want to work when necessary.
Last year I found myself working in 3.8, 3.9 and 3.10, maintaining different packages in different images. For example I would have to have an image especially configured just for developing contributions to Seaside. I ended up running about 12 different images. Simply because MC would not handle method extensions and overrides correctly.
So essential step... "make MC run identically in all images, and make overrides and extensions work"... in the process benefit the whole community.
Especially as 3.7 is very different to 3.9 (just the I18N stuff will kill you). It wont kill me since I am not using it.
The point is that there are people actually using 3.7 and 3.8 for things. Up until recently Gjallar was using 3.8. The transition to 3.10 was achieved by building the image in 3.8 using an installer script, then migrating that script and the packages involved to work with both 3.8 and 3.10. Finally the script was run to generate a 3.10 image.
In the end, what you are doing will result in kind of re-doing 3.8 for 3.7, 3.9 for 3.8... and so on, Not really.
To get Monticello 1.5 working in 3.7 requires something like 5-6 methods to be added to the base image. Necessary changes to Kernel are usually very minimal.
in addition to actually doing 3.11. Is that realistic?
Previously fixes are ONLY available by waiting for the release team to harvest, or by manually loading a changeset in yourself. Now the harvesters can make a fix readily available for everyone through Installer.
This attitude of supporting all users of squeak, while moving things forward for everyone, is a core-value of the 3.11 team.
This is *the* recipe for failure. There is no need to be so dramatic.
We have been doing this for a while now and have seen nothing but success. LPF is useful it works and has worked for lots of people, whereas before the Croquet community and the XO community were destined to be out on their own. I now know that I can load my website up on my XO, and I fully expect to be able to try Rio out in Croquet.
You can not do anything even remotely complex if any changeset that fixes something in 3.11 needs to work on 3.7, too. I never said that it would "have to", but it can if necessary. However, the old way, fixes are applied to a moving target, since the
But this can not work: fixes depend on each other. It is *one of the most important principles* to let the submitter of fixes do the work of merging his fix with the latest fix applied to the image. Else you will die. That's a bit dramatic, I am not planning on dying any time soon. You can never manage the amount of changes submitted if you can just say: "rejected. reason: conflicts with current version. Please resubmit". We dont need to say that at all. We can say, here is an image, (or here is a script which builds the image) in which your fix is loaded and needs further work. Another very important principle is to close reports on the bugtracker as soon as possible to keep it managable. I don't see that, but then I am not looking at the BugTracker to read bug reports. I periodically export reports into squeak, so I am look at them in my class browser where each report is a method that I can categorize. This even means that once a changeset is harvested, the report is closed *and not re-opend* if there is a new bug after applying. That is a *new* report, for a *new* bug (the report then will of course refrence the faulty closed report). Sounds fair enough. But I dont think you are understanding the "release" is an atomic event. Fixes can get tweaked improved up until the release. Overall, I am 100% sure that your idea how to manage 3.11 is fundamentally wrong (sorry). Your approach is based around small incremental changes to an image, performed by a single person. In particular it is easier to add things than to remove things. Overall it results in an adhoc process that lacks planning. It lacks control over the big picture. Everyone ends up following the one person doing the release. The release team do what they want in whatever order they want to do it. No one knows what the plan is in advance and there is no mechanism provided for people to contribute into the work.
We have 3.11 fully planned, the script to generate the test-candidate runs, from end to end. Contributors can add their fix-tasks to that script.
And Pharo will do it completely differently: release often, integrate as soon as possible, keep the bugtracker down to managable levels and do not be religiously backwards-compatible. This is a cop out, it is taking a process that could be a slope and making it a step, but you are pretending that it will be a slope by saying nice things like "release often" and "integrate asap". Squeak has never been release often or integrate as soon as possible. The reason for this is nothing to do with squeak, it is to do with PROCESS. The Squeak 3.7 3.8 3.9 PROCESS did not support these ideals. So unless the Pharo process has changed, the pharo process will not be any different.
However, the 3.11 development has been entirely about creating a process that will support "release often" and that we could do monthly time boxed releases with.
We will see at the end what was the better Idea ;-) I have always maintained that Pharo's goals and 3.11's goals are essentially the same.
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA