Ken Causey <ken <at> kencausey.com> writes:

On Tue, 2006-02-28 at 19:26 +0100, Marcus Denker wrote:

...

3.9a7004

<snip lots of great detail>

...

3.9a7003

<more good stuff>

Marcus,

I want to thank you for continuing to actively progress 3.9a. Even more I really want to thank you for taking the time to provide so much useful detail in your announcements to the list about each update. This is the sort of information that can often seem superfluous to some but can be exceedingly valuable when trying to track down what happened when because something seems to have gone wrong or simply due to curiousity.

I really appreciate it,

Ken

A question from me, if I may: The breakdown of bugs-fixed-in-this-release that Marcus has posted is indeed excellent - and very useful example for those of us who are using Squeak at work (with a Mantis installation) of giving our testers a build along with all the bugs fixed that they need to test.

So my question is: Is this breakdown generated automatically with some tool, or by hand? If by tool - is it in Squeakmap? If not, is anybody writing one?

Ahem, I appear to have sneaked more than one question in there - apologies for my wiley ways.

Cheers, S

On 01.03.2006, at 13:11, Marcus Denker wrote:

On 01.03.2006, at 11:24, Simon Kirk wrote:

...

A question from me, if I may: The breakdown of bugs-fixed-in-this- release that Marcus has posted is indeed excellent - and very useful example for those of us who are using Squeak at work (with a Mantis installation) of giving our testers a build along with all the bugs fixed that they need to test.

So my question is: Is this breakdown generated automatically with some tool, or by hand? If by tool - is it in Squeakmap?

embarrisingly

Hmm... I wanted to check if the Dictionary in MacOS knows this word, but some key-combination along ctrl-d actually sends a message. So consider this the be tripple - embarrassing (google-spell-corrected ;-))

So: No, by hand... but stuff like this should be automated... we need build-servers, test-server, better per-project bug-tracking (integrated with SqueakSource)...

Marcus

Il giorno mer, 01/03/2006 alle 17.55 +0100, stéphane ducasse ha scritto:

• 100 :)

Thanks for pushing that release.... Will be back soon...I hope.

PS: I hope to have some good tests for collection this year. And a first test server by Nicolas Melin

There is also Cees' Squeak On Fire system: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-December/098645....

Giovanni

On 01.03.2006, at 21:51, Simon Michael wrote:

Me too - thank you Marcus, Jerome, Bert and all others.

Marcus, would it be possible to have a breakdown of that log you just posted, suitable for folks who've been away from things ? I think:

• the 700x numbers are release numbers, corresponding to release

announcements, uploaded images etc. Two "unstable releases" were announced here.

In 3.9a we are trying to use Monticello for managing the image...

The update numbers (700x) are the number of changesets put in the update stream. The changeset loads one package ("ScriptLoader") that then has a build-script, mainly loading a set of Monticello packages from the squeaksource server, sometimes the scriptloader script has a postscript when needed (e.g. deleting preferences).

• ------ separates logical changes or change sets, though probably

not actual changesets just at the moment ? No, it looks like the second one was a changeset. One of these logical changes (updates ?) might include fixes for many mantis issues (the 000xxxx numbers).

the text was done by hand and follows no logic ;-) the numbers are manits bug numbers, yes. I don't post the full description there, but when a changeset was done with a nice preamble, I choose mostly to post that instead of the mantis number.

The best name for the release-numbers would be "build" I'd say: I load changesets (or fix stuff directly when seeing a simple to fix bug). Then I commit regularly to the source.squeakfoundation.org repository. When changes have piled up to be big enough for making it worth the effort, I make a build script, put in on the updatestream and upload an image.

As I said, the setup is far from perfect.... and we really need to improve it. e.g. updating is far too slow, and updating over multiple builds is broken...

I like MC as a versioning system (it should be speed up at bit...). But for providing what we had with the update stream it's not as good... what I would like would be a mix of the two: MC builds changesets that it then loads. There is a feature in SqueakSource that allows this to be done on the server an then cached (Bert implemented that). But this brakes down as soon as you change the code in the image via a normal changeset or a postscript: The diff the server builds between version is not the diff between the real images, as the postscript is ignored. But it should be possible to build a changeset when building the release image.... somehow, with taking the postscripts into account. This could then even set all MC data (e.g. version number) correctly, beeing a true diff.

This then should be available for people through the update stream, allowing for fast update without the need of having MC load ad decompress and diff everything on all clients... anyone would like to try implementing that?

And besides that, we need to automate much much more... I would like to have a system where I can commit to SqueakSource, and every night a build is done *completely* automatic, with image generation+upload, mail to list with changelog, generation of a changeset for the updatestream, everything.

• changes sometimes have no author information. That means they've

come from.. where ?

Either I have forgotten the author information (which would be bad, sorry to everyone who had that happen). Or the change is from me (e.g. I refactored some code now that CompiledMethods know their Selector and Class, or some small stuff, or stuff for the NewCompiler overrides/ ClosureRuntime merge).

Marcus