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.
As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at
http://people.squeakfoundation.org/article/7.html
Information about the Harvesting Party idea can be found at
http://people.squeakfoundation.org/article/29.html
If you have the time please attend and work toward the future of Squeak.
The next seven parties are scheduled for
20:00 (08:00 PM) GMT Friday November 05, 2004
00:00 (12:00 AM) GMT Wednesday November 10, 2004
04:00 (04:00 AM) GMT Sunday November 14, 2004
08:00 (08:00 AM) GMT Thursday November 18, 2004
12:00 (12:00 PM) GMT Monday November 22, 2004
16:00 (04:00 PM) GMT Friday November 26, 2004
20:00 (08:00 PM) GMT Tuesday November 30, 2004
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 are currently only two (or maybe three) people doing *anything* to get bugfixes in the release via the harvesting process.
There is a huge baglog of stuff, most of the submitted changesets can't be harvested because they are clashing with recent (and not so recent) updates.
The question is what to do? Suggestions welcome.
Marcus
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
On Sun, Oct 31, 2004 at 02:32:10PM -0800, Tim Rowledge wrote:
Marcus Denker denker@iam.unibe.ch wrote: 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.
Urk. I don't seem to have enough time to keep up with everything that is going on here. But yes I do care. Thanks for your work on multiple windows and VMMaker.
Dave
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 ;-)
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
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.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Plan to be spontaneous tomorrow.
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?
On Sun, Oct 31, 2004 at 06:59:27PM -0500, David T. Lewis wrote:
On Sun, Oct 31, 2004 at 02:32:10PM -0800, Tim Rowledge wrote:
Marcus Denker denker@iam.unibe.ch wrote: 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.
I plan on looking at it, but I'm in the middle of SW a death march in my real life :(. If I survive, you will eventually get feedback from me about it.
Urk. I don't seem to have enough time to keep up with everything that is going on here. But yes I do care. Thanks for your work on multiple windows and VMMaker.
Dave
p.s. Speaking of lack of feedback, the 64 bit VM seems like a really big
Ditto - I'm waiting for my ADC Tiger pre-release to run it in 64-bit mode on my Mac.
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 ;-)
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.
Am 02.11.2004 um 20:43 schrieb Tim Rowledge:
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?
Works for me (Safari 1.2.3)
Marcus
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 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 are currently only two (or maybe three) people doing *anything* to get bugfixes in the release via the harvesting process.
There is a huge baglog of stuff, most of the submitted changesets can't be harvested because they are clashing with recent (and not so recent) updates.
The question is what to do? Suggestions welcome.
Keep up the good work you are doing. I, too, wish more people would pitch in a few hours so the backlog could become history. Not there yet. Karl
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
Am 01.11.2004 um 04:22 schrieb Yanni Chiu:
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.
submit changesets.
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 mean, is it really so hard to understand that adding bugfixes may be a good idea?
But it could be that I just don't understand something. Maybe it's better to not fix bugs, ignore all sent chagesets, and just talk instead.
Marcus
"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.
Hi samuel
I am still hoping that at some point you will change your mind, or that you will add new harvesters if more are needed.
But we cannot add them. People are harvesting or not. We just pay attention that when you harvest something we look at it and push into the unstable stream.
I think that one the problem with the unstable stream is that its items were not pushed fast enough into the alpha image. Unstable is really for making sure that we can make mistake. Because you could then work in the alpha image.
Please continue to clean and review bug fixes because squeak needs that. Stef
"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
Samuel Tardieu sam@rfc1149.net wrote:
"stphane" == stphane 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.
stphane> But we cannot add them. People are harvesting or not. We stphane> just pay attention that when you harvest something we look stphane> at it and push into the unstable stream.
stphane> I think that one the problem with the unstable stream is stphane> that its items were not pushed fast enough into the alpha stphane> image.
I meant "pushers", maybe we need to add more pushers.
stphane> Unstable is really for making sure that we can make stphane> 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.
stphane> Please continue to clean and review bug fixes because squeak stphane> 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.
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 Squeak and we need to value their time and effort.
Ommitting the bad updates and their revert should be easy when the unstable updates are moved over to stable
Karl
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
Am 02.11.2004 um 19:10 schrieb Michael Rueger:
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.
Yes, the original idea was to have unstable for testing new submissions, synched very soon with alpha. So we are talking about just a handful of changesets and days, not hundrets of changesets and months.
This didn't work out in the 3.8 unstable, sorry for that and we will try hard to do it better next time.
Marcus
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
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.
-- Kamil
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)
Precisely. You can do this even before OldSocket is removed.
Cheers, - Andreas
----- Original Message ----- From: "danil a. osipchuk" danil-home@tsnet.ru To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Tuesday, November 02, 2004 11:43 AM Subject: Re: Squeak cleanup
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
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.
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...
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
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.
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
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?
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?
On Mon, 2004-11-01 at 06:23 -0800, Roy Garris wrote:
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?
Uh. I think you must have indeed been in the wrong place. Or are you trying to make a joke? I don't think I was there the entire time but I was certainly there most of the time and although little harvesting discussion occurred I sure don't remember and MLB discussion. Interestingly enough no such discussion occurs in the logs either:
http://tunes.org/~coreyr/read.php?chan=squeak&date=04.11.01
Did you connect to irc.freenode.net (or any of the many servers on the Freenode network) and go to #squeak? If not that's where you want to be. Perhaps you went to irc.parcplace.net? We used to have a bridging bot that would connect both channels but I just now notice it's not around anymore. If that's where you were I'm surprised anyone was there as there rarely has been in the past. (I just checked and no one is around now either).
Will the next one be any better?
That's up to you. Always (and I mean ALWAYS) feel free to interject with Squeak/Harvesting discussion and don't be afraid to interrupt, especially when the discussion is offtopic. We are pretty good about not being too offtopic (I couldn't stay on the channel if it was anything like other channels I won't name.) but it happens sometimes.
The main purpose of the scheduled harvesting parties to my mind is to give newcomers a place to go and have some expectation of finding someone to answer fundamental questions. But questions are only answered when they are asked, so please don't hesitate.
Ken
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
Am 01.11.2004 um 08:56 schrieb Blake:
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?
That's the hard part... I don't think it makes sense to have a hard definition for that. We tried that, and it turned into a burocratic nightmare.
For all submissions: Is there an attachement? are there conflicts with updates? Does the .cs has a preamble?
For fixes: Does it fix the bug? Who did the fix? does it look ok? Tests? For enh: Does it make sense to have it in the image or should it be on SM? Who did it? does the code look ok? commented? tests? does it work? Do i want to see this in the image?
stuff like that.... as I said, it makes no sense to define the requirements. sometimes, it makes sense to just add something without looking (e.g. it was done by someone trusted), sometimes a real review is needed.
Marcus
squeak-dev@lists.squeakfoundation.org