Release July 2009

release@lists.squeakfoundation.org

7 participants
7 discussions

Re: [Release] The role of Bob, Installer & Co.
by Andreas Raab 11 Jul '09

11 Jul '09

Keith Hodges wrote: > You really dont get it do you... I think that's pretty obvious by now, isn't it. What I'm trying to do is to enable developers to work together. I can't possibly imagine why anyone would be so violently against that, so clearly I'm not getting the point. I think our main practical difference is that you "abso-bloody-lutely" want people to go through Mantis. Which is okay, you can use Mantis for anything you'd like. But I myself, and other developers who understand the MC workflow, would rather collaborate that way. If Bob can't support workflows that use collaboration through shared MC repositories then it's not suited for the task of image building. And if it does support these workflows, then I don't understand why we're even having this discussion. Cheers, - Andreas

5 44

Re: [Release] Philosophical Discussion - The updates button is useless - discuss
by edgar De Cleene 09 Jul '09

09 Jul '09

--- El jue 9-jul-09, Keith Hodges <keith_hodges(a)yahoo.co.uk> escribió: >> >>Our target audience is not the end users, or even the individual >>programmer, it is the builder of interesting customised images, so they >>would be capable of using a less than single click solution. >>If this is the case then the builder of the customised image will have >>detailed knowledge of how he configured the image he published, and the >>update stream might be useful to him for passing on emergency fixes to >>his own users. >>Keith I think we need more people doing Squeak , not less people. Maybe it's me , but frankly i don't understand why we waste time and do not have nothing useful for another person who not was Keith. I can't wish start again Formula One tales, but now Squeak bacomes like this days Formula One. Because wrong polythics and unclear rules most powerfuls teams like Ferrari, BMW, McLaren , Toyota was behind newcomers less powerful teams. So SOB take actions now. I continue working in the SqueakLightII and MinimalMorphic images. This days i learning a lot from EToys 4.0 and Cuis. Also from John on Ipod related stuff. Claim having the most advanced Squeak and have videos to prove it. Do not claim is suited to all, free of bugs or being good Smalltalk. Tryng to synch with any Andreas decide. Meet me on irc or in Skype as edgardec. Edgar ____________________________________________________________________________________ ¡Viví la mejor experiencia en la web! Descargá gratis el nuevo Internet Explorer 8 http://downloads.yahoo.com/ieak8/?l=ar

2 1

Re: [Release] The role of Bob, Installer & Co.
by Andreas Raab 05 Jul '09

05 Jul '09

Keith Hodges wrote: > Andreas' proposal is to throw every package within the kernel and the > image as a whole out to be treated as an "external package" to be hacked > on by any approved person who fancies a go. Really, the fundamental idea of the proposal to have a shared repository where I can collaborate with other Squeak developers on core packages. > The result can be viewed and used by anyone by publishing to MC and > subscribing via an updates mechanism. Correct. > The image will probably be a bit unstable for a bit, but we cant go to > the extent of breaking it ever, because we are not distibuting a new > image, just updates, everything must continue to work seamlessly. Not necessarily. If there is a need to distribute a new image, we can certainly do that. I'm just not in favor of requiring a new image any time you want to do anything. Keep in mind that in previous messages I've pointed out Bob's role in building images based on the trunk packages. That's useful because people can fetch the latest version for playing with it which is right in line with the idea of reducing hurdles since the need to go through a lengthy update process can be just as bothersome as the need to download a new image every week. In short: Updates and images go hand in hand. Yes, there will be images, and I would like Bob to play a role in building these automatically (say on a weekly basis). > Everything has to be done in small evolutionary steps as required by an > updates mechanism. There is no mechanism for removing things from the > image, or for changing the image structure. You will have to clear out > stale package references, repository references from your image > yourself. All of this can be done automatically. Removals and doIts can be deployed (for example) via package preambles/postscripts and since the MCM update mechanism can be instructed to load precisely those version with the scripts attached to it you can utilize the process in a similar manner as preambles/postscripts in change sets. > Then it is supposedly up to Bob to take these packages as an **input** > putting the image into an unpredictable state. Actually, you start with some base image (like the previous release) which I think we can agree on as being called stable. Then you run the package updater process just like any client would. Not much difference to a SakeTask (which could be produced from the MCM automatically) and it leaves the image in a no more unpredicable state than loading any other code would. > Then Bob is expected to apply some fixes from mantis which were perhaps > submited a year ago and were definitely not targeted at the image in > which bob has to get them to work. Bob then uploads the resulting > packages up to the trunk repo, > Bob is now an automated contributor to the single trunk repository. That's the point where I would hope that Bob can help us to drastically reduce the turnaround times. A fix produced a year ago should not stall for a year in Mantis. If Bob identifies the fix within a week or two, if Bob can prove that the fix doesn't break an existing test and does allow the provided tests to run then there should be little need to wait for a year. The point being that Bob's stamp of approval can help us screen tests that "look ready" much, much faster. > Bob also helps out by running tests in the hope that at some point in 2 > years time, we get to a point where all the enthusiastic contributors to > trunk have calmed down and have arrived at a reasonably stable working > image. At which point a release will be asssembled manually by someone, > probably Andreas, who will manually update the versions number, and > manually ftp the new image up to ftp.squeak.org or publish an mcm for > people to use. Something along those lines, yes. I think that having an ongoing release team would be useful, for example to work out which demos should be included, how the contents is presented, which extra parts (fonts, media, etc) to include and so on. Cheers, - Andreas

2 1

The role of Bob, Installer & Co.
by Andreas Raab 05 Jul '09

05 Jul '09

Folks - I just had a very good (off-list) discussion where it was brought to my attention that one might look at the proposal from the point of view that it replaces Installer, Bob & Co. in situ and that there is no role for these tools in the proposed process. Nothing could be further from the truth. What I am imagining goes along these lines: Consider Bob running daily/weekly builds and then checks if any new fixes have appeared on Mantis. If there is anything new, it loads the fix, runs the tests inside the image, runs the tests attached to the bug. If this works out Bob puts his "stamp of approval" on the fix or commits it directly to the repository. In effect, Bob becomes our main harvester doing all the boring integration stuff that we can reasonably automate. This is actually quite similar to what Bob does today - except that Bob isn't producing an image but rather commits to the trunk. In any case, from my perspective there is a lot of room for Bob and Installer - be that in providing up-to-date images from weekly builds, running automated test suites, and so on. I have no intention to get rid of Bob and Installer. I hope that with Keith's help we can make maximum use of both since these are valuable tools in a successful software development project. Cheers, - Andreas

3 4

3.11 liaison change
by Andreas Raab 03 Jul '09

03 Jul '09

Folks - You might (or might not ;-) have noticed this but due to some internal reshuffling of responsibilities [1] I am now the "official" board liaison for the 3.11 release. Randal remains the contact for 4.0 since it's so intrinsically connected to relicensing but I'm trying to help out since he would otherwise have too many responsibilities all at once. I've been looking at the archives but since there wasn't too much communication I am not sure how I can best help. Please let me know what you'd like help with - I can be anything from coder, to tester, to whip, help communicate, or whatnot. Your choice ;-) I still feel somewhat uncomfortable defining when exactly we would consider 3.11 "done" and how far along we are in that process. I would very much like to try to come to a schedule which we can communicate and work towards so I'd appreciate any help you can provide. Cheers, - Andreas [1]http://squeakboard.wordpress.com/2009/04/03/meeting-report-for-422009/

5 25

02Jul Diary
by Keith Hodges 03 Jul '09

03 Jul '09

Simplifying Sake/Packages so that it is better placed to be the definitive (declarative) database of what works where. Today I have been fixing up Sake/Packages so that it can run Seaside29 package definitions. So now Bob can build Seaside29 images using Sake/Packages (try that in universes) cheers Keith - Plans for this coming week... Get auto testing running Build dev images Finally get around to generating a public build of 3.11

1 0

[Fwd: Problem with installing DS on 3.10-lpf-atomic]
by Keith Hodges 03 Jul '09

03 Jul '09

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Release July 2009