Marcus Denker denker@iam.unibe.ch wrote:

Am 31.10.2004 um 18:00 schrieb Ken Causey:

...

Just a reminder that the next Harvesting Party will take place between 16:00 (4 PM) and 20:00 (8 PM) GMT Monday November 1st, 2004.

I just want to add the reminder that the overall participation of the community is quite non-existent. There is nothing happening at these partys.

There's a practical problem that needs adressing; what on earth is going on with bug fixing?

Are we using BFAV or Mantis?

Does anybody actually care any more? I think the only feedback I got about VMMaker3.7 was from Alejandro. John & I got approximately zilch response to releasing the multilple windows stuff, something that plenty of people had claimed was crucial to the usability of Squeak.

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: RJT: Read and Jam Tape

David T. Lewis wrote:

p.s. Speaking of lack of feedback, the 64 bit VM seems like a really big thing to me. Ditto Croquet. I'm trying to figure out the cheapest 64 bit box that would let me try these out. I'm sure as soon as I do I'll be wanting to use the latest VMMaker and I might as well try out some multiple host windows while I'm at it ;-)

Is about $1000 US cheap enough? I built a 64-bit AMD64 box in June for about that much, and some of the parts have come down in price since then:

2.2GHz AMD Athlon 64 1GB DDR400 RAM 120GB SATA drive DVD burner Gentoo Linux All in a case small enough to fit in carry-on luggage.

I've been very happy with it, except for a recent adventure with a failed power supply in the second case I bought for it. I moved back to the first case and I'm fine.

I assume the list isn't all that interested in all the gritty hardware details (and that they'll speak up if they are) so contact me off-list if this sounds like a direction you'd like to go and want more details.

-Martin

On Sun, Oct 31, 2004 at 07:11:07PM -0800, Tim Rowledge wrote:

Martin McClure martin@hand2mouse.com wrote:

...

David T. Lewis wrote:

...

p.s. Speaking of lack of feedback, the 64 bit VM seems like a really big thing to me. Ditto Croquet. I'm trying to figure out the cheapest 64 bit box that would let me try these out. I'm sure as soon as I do I'll be wanting to use the latest VMMaker and I might as well try out some multiple host windows while I'm at it ;-)

Is about $1000 US cheap enough?

And for only a little more you can get a G5 iMac with a nice screen thrown in. Not as much RAM, to be sure, but still a real (nice) 64 bit machine.

Wait a minute, I'm still saving up for an Acorn, and now you want me to throw it all away on a fancy newfangled iMac?

Am 31.10.2004 um 23:32 schrieb Tim Rowledge:

Marcus Denker denker@iam.unibe.ch wrote:

...

Am 31.10.2004 um 18:00 schrieb Ken Causey:

...

Just a reminder that the next Harvesting Party will take place between 16:00 (4 PM) and 20:00 (8 PM) GMT Monday November 1st, 2004.

I just want to add the reminder that the overall participation of the community is quite non-existent. There is nothing happening at these partys.

There's a practical problem that needs adressing; what on earth is going on with bug fixing?

There is a lot of stuff in BFAV. As of now, we have not decided to just abandon all that. So BVAF is there.

Yet, the last year has shown that people do not like to use BFAV.

So when Mantis started to get very successfully used for both squeakland and Tweak, we decided to just try to use it, too. It makes no sense to continue to insist on BFAV if nobody besides me uses it.

I personally like some things with Mantis a lot: the ability to sort bugs and fixes (e.g. VM, Network), or assigning to a developer. Having a web-interface is nice. And not having to sent an email for flipping a bit is a good thing, too.

BFAV didn't help much with Bugs. It never got used as a bugtracker, more a "harvesting" tool.

So other things are better with BFAV: The ability to quickly look at a changeset from inside Squeak is really helpfull. (e.g. browse code, or conflictchecker). Or the fact that there is kind of an interface to submit to BFAV from inside Squeak (mail bugreport, mail changeset to list).

In the end, it would be nice to have the best of both worlds...

Marcus

Michael Rueger michael@squeakland.org wrote:

Marcus Denker wrote:

...

In the end, it would be nice to have the best of both worlds...

A newer version of Mantis includes a web service interface that could be used to have just that.

I hope to find some time next week to upgrade the server.

Which reminds of an annoyance with Mantis - attempting to upload any attachment gets me a file 'upload.php' rather than 'fredsBugFixFile.cs.gz'. Is this just me or is it so for everyone?

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim The world's coming to an end. Log off and leave in an orderly fashion.

On Tue, Nov 02, 2004 at 07:58:19PM +0100, Marcus Denker wrote:

Yet, the last year has shown that people do not like to use BFAV.

So when Mantis started to get very successfully used for both squeakland and Tweak, we decided to just try to use it, too. It makes no sense to continue to insist on BFAV if nobody besides me uses it.

For those who may not know this, BFAV is absolutely the easiest way to find a [BUG] or a [FIX] that has been posted on this list, and all the discussion that goes with it. Also, since BFAV is in the image, you can browse the code for proposed fixes, or load it easily into your image if you want to try it out.

There is of room for improvement, but it is already a very useful tool. So even for someone who does not feel comfortable participating in the reviews and harvesting, I suggest trying it anyway.

Dave

Marcus Denker wrote:

The question is what to do? Suggestions welcome.

For me, Squeak already has everything I need: -Smalltalk devt tools -a web app platform -connects to PostgreSQL

"Squeak" is too big. It needs to shrink, to grow.

I'd suggest 3.8/3.9 be the last 3.X release, and we start immediately on a 4.0 based on the Squat minimal image, with (possibly) the 64-bit VM.

If someone wants something to move forward, then they'll port it. The "Core" Squeak developers would provide a roadmap for things that seem to be "core", in a perhaps hopeless attempt to control the ensuing bedlam. After porting, stewardship of any packages that are deemed "core" would pass to the Core team.

For non-core packages, they would need to form their own community (maybe piggybacking on Squeak for a time).

--yanni

...

...

...

...

"Marcus" == Marcus Denker denker@iam.unibe.ch writes:

Marcus> submit changesets.

Marcus> Harvesting ist not about "we need to do X". It's just about Marcus> "Someone has already done Y, let's get it in the release".

Marcus,

I understand your frustration. However, I think that moving Squeak forward requires more cooperation from the harvesters themselves.

To take my own case, I had to revert to using a 3.7 image for my work because of the refusal of the harvesters to guarantee that the 3.8 unstable stream will be incremental[1]. I really liked to fix bugs as I found them instead of using workarounds. I really liked to distract myself from serious work for a few dozens of minutes by going through the BFAV and reviewing changesets. But I really *had to* go back to 3.7 because I don't feel like using two radically different images, one for my serious work and one for my bugfixing/reviewing work, and I can't loose time to reinstall all my environment in a new image (I work on several projects at the same time) when the unstable update stream gets modified back in time.

As I stated before, I think that Squeak, as other software projects, will get better only if people can use the development version daily and base their work on it, even if there are obvious stability concerns in doing so (this is a development version after all and people should be ready to get bogus updates and fix them).

Don't get me wrong: I am not complaining, I am just giving an example where someone quite productive (regarding the rate of my submissions and reviews at the end of 3.7 and the beginning of 3.8alpha) had to stop because the current handling of the unstable stream[2] is not compatible with the available resources.

I am still hoping that at some point you will change your mind, or that you will add new harvesters if more are needed. The Debian GNU/Linux distribution for example works that way: you can always go forward, you never need to go backward; if something gets broken, it gets fixed later.

Sam

Notes: [1] Except of course if the update mechanism itself has been badly broken and needs to be fixed back in time.

[2] That is removing bogus updates rather than reverting them, because it takes much less time for the harvesters.

...

...

...

...

"stéphane" == stéphane ducasse ducasse@iam.unibe.ch writes:

...

I am still hoping that at some point you will change your mind, or that you will add new harvesters if more are needed.

stéphane> But we cannot add them. People are harvesting or not. We stéphane> just pay attention that when you harvest something we look stéphane> at it and push into the unstable stream.

stéphane> I think that one the problem with the unstable stream is stéphane> that its items were not pushed fast enough into the alpha stéphane> image.

I meant "pushers", maybe we need to add more pushers.

stéphane> Unstable is really for making sure that we can make stéphane> mistake. Because you could then work in the alpha image.

Making a mistake doesn't imply going back in time. A mistake can be fixed by going forward, even if it takes more time.

stéphane> Please continue to clean and review bug fixes because squeak stéphane> needs that.

I simply won't be able to (time resources cannot be extended) as long as past updates can be removed from the unstable stream. I've explained why in length.

Sam

karl.ramberg@chello.se wrote:

I think we could/should agree on that a rollback of a cs in the unstable stream should be the very last option to get out of a jam eg. a update that screw up seriously. People comitting to be part of unstable should be credited for their comitment and we should not pull the carpet under their feet at every twist and turn. We need people working for enhancing

But, please, lets not forget we are talking about an *unstable alpha* stream here. alpha in my understanding already implies "all bets are off, don't rely on it for serious work", and the word "unstable" has a certain meaning as well. We should, however, keep unstable and stable closer together. The gap we got in the 3.8 process was a result from too many things trying to get in at once while we were still sorting out the m17n issues.

JMTC

Michael

Marcus Denker napsal(a):

Am 01.11.2004 um 04:22 schrieb Yanni Chiu:

...

"Squeak" is too big. It needs to shrink, to grow.

I feel good someone thinks the same as me. Now, can we refer to this as "clean-up" effort? If so, do we stick with something "cleaners" can rely on? I found "Cleanup/Enhancement Projects" http://minnow.cc.gatech.edu/squeak/3082 but I remember there was maybe better information but didn't find it now (wiki has no tree).

submit changesets.

I did some clean-up for getting rid of OldSocket. I was then adviced to make a backup as a SqueakMap package. Is it right place for backups? Or should it be published as *-Removal package? Sorry to "talk" again, but there are questions I don't even know whom to ask. There's SpeechRemoval package, so what to do now in order to have Speech as installable package and not like traveling with every new image being released?

Harvesting ist not about "we need to do X". It's just about "Someone has already done Y, let's get it in the release".

I have read somewhere "Process of completion is about subtraction, not addition". I just think refactoring oriented to completness (like this complies with RFC XXXX) brings Squeak its power to stay alive and well.

for the OldSocket please send your cs that remove them from the image. Or publish a sm package that remove it from the image.

I would prefer to deprecate it simply. Is there anybody there that need it?

Stef

OldSocket contains examples on the class side (hope they'll survive)

What should I do? Post changeset with examples after OldSocket be removed?

Only if *you* rescue them. Otherwise they don't.

• A.

On 02/11/04 13:42, "stéphane ducasse" ducasse@iam.unibe.ch wrote:

for the OldSocket please send your cs that remove them from the image. Or publish a sm package that remove it from the image.

I would prefer to deprecate it simply. Is there anybody there that need it?

Stef

Don¹t forget add this to Socket. Some old methods are still needed. And fix all examples in OldSocket for working with Sockets and move to class I think I send something about this a long time ago.

Edgar

Hi all!

Kamil Kukura kamk@volny.cz wrote:

stéphane ducasse napsal(a):

...

for the OldSocket please send your cs that remove them from the image. Or publish a sm package that remove it from the image.

I would prefer to deprecate it simply.

Yes, that is the way I'm going. As soon as all of tests and examples will be isolated from OldSocket I'll put the whole class in deprecated state so it can be removed during versioning step. Right now I have extracted some of the tests.

Very good. Keep it going.

...

Is there anybody there that need it?

Need OldSocket? I hope nobody. Need this sockets clean-up/refactor? Well, I am confident with an idea that having clean, well-written, realiable parts of Squeak would bring it more respectful view than just being a toy with play-and-throw-away usage. But... if I'm wrong, please stop me...

You are most definitely not wrong. :) I applaud your effort and will help with reviewing later if not anyone more competent steps up and does it, like John etc.

regards, Göran

Am 01.11.2004 um 07:42 schrieb Blake:

On Sun, 31 Oct 2004 21:19:34 +0100, Marcus Denker denker@iam.unibe.ch wrote:

...

The question is what to do? Suggestions welcome.

I've followed some of these links to the harvesting parties and, unless I missed something, there's no explanation of what they are.

I've sort of picked up on it, but not fully enough to feel comfortable to chip in. Others may feel the same way.

There is *nothing* going on at that times on the list wrt. harvesting. Just normal talking on IRC.

Harvesting would mean: Lets fire up BFAV. Look at a submission, test, look the code, decide if that should go in.

Marcus

Absolutely. There I was with Squeak all fired up, ready to dive in an follow along...and maybe...just maybe...find a useful contribution to make during a Harvesting party.

The result? A couple of comments about the Yankees and Red Sox. I kept thinking...was I on the wrong #squeak channel? Why didn't all the other folks logged in to the channel have anything to say? Where was the harvesting?

Will the next one be any better?

On Sunday, Oct 31, 2004, at 23:56 America/Vancouver, Blake wrote:

On Mon, 1 Nov 2004 08:33:37 +0100, Marcus Denker denker@iam.unibe.ch wrote:

...

There is *nothing* going on at that times on the list wrt. harvesting. Just normal talking on IRC.

Well, I didn't mean that I'd picked it up from listening on IRC. I don't do IRC. I meant I'd picked up on it here.

...

Harvesting would mean: Lets fire up BFAV. Look at a submission, test, look the code, decide if that should go in.

Sounds simple. On what basis does one make that decision?

Blake blake@kingdomrpg.com wrote:

On Mon, 1 Nov 2004 08:33:37 +0100, Marcus Denker denker@iam.unibe.ch wrote:

...

Harvesting would mean: Lets fire up BFAV. Look at a submission, test, look the code, decide if that should go in.

Sounds simple. On what basis does one make that decision?

If it's a bugfix, see if the bug is a reproducable bug or just a glitch and if the fix does fix that bug. Bugfixes with SUnit tests are easiest since you just (in theory) have to run the test before and after the fix is filed in.

Enhancements are a little harder to review. But here we have to rely on eachothers judgement over if it is something that enhances the system, and not just adds some junk. Karl