Hernan Tylim wrote:

I am curious. Please tell me. Are anyone using the shapes that come with

Jacaranda? They were developed for a OOP course here in Argentina and because of them I am maintaining them. I allways thought that because they were not like the ones in UML they would probably not be used.

I only need class and state diagrams, so the shapes provided have suited me just fine. I noticed that various shapes were not quite conforming. It's not a problem now, but I can imagine that such non-conformance could mean rejection of Jacaranda, for certain users.

One thing I miss is the lack of role labels on each side of a class relationship. I compensated by parsing the relationship name.

Labels, in general, seem to misbehave. But I think Connectors2 (which I've not tried yet) has done some work on labels.

Thanks for a great tool.

--yanni

Thanks to Ned and Hernán for these tools. Connectors very nice system aesthetically . Jacaranda adds support for interaction diagrams. This kind of diagrams are most useful for me. It would be nice to specify uml class of an object and create uml class selectors in scenario diagrams by drawing message sends between objects as Rose does. It would be nice to make UML elements independent of their appearance in diagrams -- Class or Use Case may appear in many diagrams (maybe with different presentation options). Now I use Connectors + Jacaranda for sketching. Maybe UML models could be stored on some shared object database on server?

Vaidas

-----Original Message----- From: Hernan Tylim [mailto:htylim@yahoo.com.ar] Sent: Thursday, July 22, 2004 5:31 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [BUG][JACARANDA] Jacaranda does not like Connectors 2

Hi Thomas,

Thanks for your feedback.

Let me tell you that I am planning for this weekend to make a new

release of Jacaranda. In that release I will take out the DiagramBrowser from Jacaranda and make for it its own package. With this package you will be able to use it with any version of Connectors, or without Connectors at all.

For the rest of Jacaranda, the shapes, similar but not equal,

to UML, I am gonna make another package and make them use Connectors2. But this I think it could take me a little more time. But because I didn't look at Connectors2 yet I really don't know.

I am curious. Please tell me. Are anyone using the shapes

that come with Jacaranda? They were developed for a OOP course here in Argentina and because of them I am maintaining them. I allways thought that because they were not like the ones in UML they would probably not be used. (Note that Connectors1 already came with a couple of UML Shapes, the ones I am talking are the ones in the Jacaranda flap)

Thanks

Regards, Hernán

----- Original Message ----- From: "Thomas A Petersen" tpeterse@csc.com To: squeak-dev@lists.squeakfoundation.org Sent: Thursday, July 22, 2004 11:29 AM Subject: [BUG][JACARANDA] Jacaranda does not like Connectors 2

...

Hernan,

It looks like Jacaranda and Connectors 2 don't like each other. It

appears

...

that the base classes have been mixed around a bit and that the recent alterations in package loading may be ganging up on your current installation process.

Jacaranda and Connectors make a great wired diagramming system.

Thanks much,

tap

Hello folks!

We've begun work on TK4 in Tweak. One of the issues that has come up is the internationalization work that Michael and Yoshiki are working on.

Since TK4 depends on this work, I'd like to get a sense of the 3.8 status. I've seen notes from as far back as January, but I don't think 3.8 is done yet.

I'd like to see 3.8 nailed down to just these changes and finished. As more and more people learn about Squeak/Tweak and more projects start to rely on the wonderful work you do, we're going to need more stable versions than less stable versions, and shorter development cycles for each iteration.

Comments please. :)

Steve

Hi Doug,

I think it is worthwhile for a number of ongoing projects to consider a very short 3.8 cycle which basically pulls in the m17n stuff and no more. The reason being that various projects do need a stable point of departure which *does* include m17n and the changes are major enough that they will most definitely need some time to shake down. I think we would be better off if we basically go to beta straight away and maybe have another release two months down the road than putting in (and waiting for!) "new stuff" and have the next release only 6-8 month from now.

Cheers, - Andreas

----- Original Message ----- From: "Doug Way" dway@mailcan.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, July 26, 2004 10:39 PM Subject: Re: Squeak 3.8 status

On Monday, July 26, 2004, at 02:20 PM, Steven Riggins wrote:

...

Hello folks!

We've begun work on TK4 in Tweak. One of the issues that has come up is the internationalization work that Michael and Yoshiki are working on.

Since TK4 depends on this work, I'd like to get a sense of the 3.8 status. I've seen notes from as far back as January, but I don't think 3.8 is done yet.

There was originally talk (early this year) of getting the internationalization work in 3.7, but the i18n changes were major enough that Michael & Yoshiki needed a stable point at which to add the changes, instead of the constantly shifting base of 3.7alpha. So they're being added now as the first item in 3.8alpha, without having to have any other changes go in first.

3.8 is not done yet, it only recently started.

...

I'd like to see 3.8 nailed down to just these changes and finished.

Well, 3.8 was tentatively planned to be a shorter/smaller release (coordinated with the 64-bit 4.0 release) so something like this *might* work out. But we need to hear from the 64-bit folks on this.

(disclaimer: I'm just now looking up "TK4" on Google, although I'm familiar with Tweak & Croquet)

...

As more and more people learn about Squeak/Tweak and more projects start to rely on the wonderful work you do, we're going to need more stable versions than less stable versions, and shorter development cycles for each iteration.

Unfortunately these last two (more stability and shorter development cycles) are in conflict with each other. Well, you can decrease the overall amount of change in Squeak and then I guess you could get both of those things. Or, try to improve the development process in general (e.g. have the equivalent of some direct "committers"), which we're working on, but that's not easy.

Anyway, 3.7 is taking about 9 months instead of the originally planned 6 months, so I agree that is too long. But getting the releases significantly faster than every 6 months... ain't gonna happen anytime soon. It would require someone else taking over the release process from me (for starters), and doing a lot of work on the process...

• Doug

On Tuesday, July 27, 2004, at 06:07 AM, goran.krampe@bluefish.se wrote:

"Andreas Raab" andreas.raab@gmx.de wrote:

...

Hi Doug,

I think it is worthwhile for a number of ongoing projects to consider a very short 3.8 cycle which basically pulls in the m17n stuff and no more. The reason being that various projects do need a stable point of departure which *does* include m17n and the changes are major enough that they will most definitely need some time to shake down. I think we would be better off if we basically go to beta straight away and maybe have another release two months down the road than putting in (and waiting for!) "new stuff" and have the next release only 6-8 month from now.

Well, if the other Guides think this sounds reasonable - and the VM port maintainers, then why not. We could instead focus on changing the development process during these months.

This sounds generally reasonable to me. The one modification I'd make is that we should still allow the usual fixes and small enhancements/refactorings to be harvested from the BFAV during this release. (There is already a backlog of approved items from 3.7beta.) This could happen after the m17n changes have gone in and are being tested, so it shouldn't significantly add to the time spent on the release.

However, we would not add any major enhancements (other than m17n) which have been discussed, such as splitting out a bunch of packages, major compiler changes, RegExp, Squat, etc. Those could be lined up for the following release.

- Doug

Andreas Raab wrote:

Correct. And by closing alpha early and getting to a release fairly quickly we'd make sure that these changes aren't delayed forever. That's why I was looking at the 2 months range - we basically have this stuff lined up to go (there is even a prototype alpha already which will be the Squeakland plugin image) so let's fold it in, wrap it up, declare victory for now, and put it the new stuff afterwards.

I agree; i18n stuff is worth a minor version number, get it in, make sure it works ok on all platforms and for everyone willing to do some testing (and to heck with those unwilling) and close it out.

Then I can get on with _really_ breaking stuff for 4.0alpha :->

How'd y'all fancy 64bit stuff, new compiled method format, dumping lots of ancient crap, multiple host windows and chocolate flavoured undies? (Whoops, I should add 'Eh' to the end of that since I'm in Canada)

tim

Doug,

I think that andreas is right. If we could have shorter and denser release cycles this would be good (if we can sustain it :)).

Stef

Hi,

...

...

Well, if the other Guides think this sounds reasonable - and the VM port maintainers, then why not. We could instead focus on changing the development process during these months.

This sounds generally reasonable to me. The one modification I'd make is that we should still allow the usual fixes and small enhancements/refactorings to be harvested from the BFAV during this release. (There is already a backlog of approved items from 3.7beta.)

That was implicit in saying let's go to beta quickly - beta is for fixes and some other small enhancements or refactorings won't hurt, I think. The point would be to get past alpha fairly quickly.

...

However, we would not add any major enhancements (other than m17n) which have been discussed, such as splitting out a bunch of packages, major compiler changes, RegExp, Squat, etc. Those could be lined up for the following release.

Correct. And by closing alpha early and getting to a release fairly quickly we'd make sure that these changes aren't delayed forever. That's why I was looking at the 2 months range - we basically have this stuff lined up to go (there is even a prototype alpha already which will be the Squeakland plugin image) so let's fold it in, wrap it up, declare victory for now, and put it the new stuff afterwards.

Cheers,

• Andreas

Thank you all for understanding. We're going to be doing our part to forward Squeak (We're already working on adding OS windows and all sorts of goodness)

We can't really port Tweak until M17n is in place however as we don't want to keep re-porting it. And as it stands, some comments won't even load in properly :)

I'm not asking anyone to build a special Squeak for us. But I think more stable squeaks with shorter life cycles are better for the platform than a 18 month release with 20 new things that cause all sorts of havoc.

Not to mention once this m17n stuff goes in and is debugged, everyone in the community wins with a large step forward.

Steve

P.S. We don't have a page for TK4 up yet, which will be open source btw. I'm working on it.

On Jul 27, 2004, at 10:10 AM, Julian Fitzell wrote:

I actually think this sounds reasonable too. I think it's useful to focus on a specific feature set for a release and m17n certainly seems large enough to pretty much justify its own release. By the time we work out any bugs in it and any other that we come along (plus random other small stuff) there will be plenty of reason to do it. It would also give us practice at getting shorter releases :)

Julian

Andreas Raab wrote:

...

Hi Doug, I think it is worthwhile for a number of ongoing projects to consider a very short 3.8 cycle which basically pulls in the m17n stuff and no more. The reason being that various projects do need a stable point of departure which *does* include m17n and the changes are major enough that they will most definitely need some time to shake down. I think we would be better off if we basically go to beta straight away and maybe have another release two months down the road than putting in (and waiting for!) "new stuff" and have the next release only 6-8 month from now. Cheers,

• Andreas

----- Original Message ----- From: "Doug Way" dway@mailcan.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, July 26, 2004 10:39 PM Subject: Re: Squeak 3.8 status

...

On Monday, July 26, 2004, at 02:20 PM, Steven Riggins wrote:

...

Hello folks!

We've begun work on TK4 in Tweak. One of the issues that has come up is the internationalization work that Michael and Yoshiki are working on.

Since TK4 depends on this work, I'd like to get a sense of the 3.8 status. I've seen notes from as far back as January, but I don't think 3.8 is done yet.

There was originally talk (early this year) of getting the internationalization work in 3.7, but the i18n changes were major enough that Michael & Yoshiki needed a stable point at which to add the changes, instead of the constantly shifting base of 3.7alpha. So they're being added now as the first item in 3.8alpha, without having to have any other changes go in first.

3.8 is not done yet, it only recently started.

...

I'd like to see 3.8 nailed down to just these changes and finished.

Well, 3.8 was tentatively planned to be a shorter/smaller release (coordinated with the 64-bit 4.0 release) so something like this *might* work out. But we need to hear from the 64-bit folks on this.

(disclaimer: I'm just now looking up "TK4" on Google, although I'm familiar with Tweak & Croquet)

...

As more and more people learn about Squeak/Tweak and more projects start to rely on the wonderful work you do, we're going to need more stable versions than less stable versions, and shorter development cycles for each iteration.

Unfortunately these last two (more stability and shorter development cycles) are in conflict with each other. Well, you can decrease the overall amount of change in Squeak and then I guess you could get both of those things. Or, try to improve the development process in general (e.g. have the equivalent of some direct "committers"), which we're working on, but that's not easy.

Anyway, 3.7 is taking about 9 months instead of the originally planned 6 months, so I agree that is too long. But getting the releases significantly faster than every 6 months... ain't gonna happen anytime soon. It would require someone else taking over the release process from me (for starters), and doing a lot of work on the process...

• Doug

http://www.geeksrus.com/

heh shows what I know. I even made the book with those cheesy Omnigraffle slides :)

That text is part of proposal. I think, when we're done, we're going to have a really fun environment for authors (non-programmers) to be introduced to Smalltalk and squeak. It is kind of how a class I helped teach iMovie went - We didn't teach people iMovie for a weekend, we showed them how to shoot video, gave them scenes to shoot, brought the video in and then had them edit their own stories, which of course made them ask "How can I cut out this video..." and off they went until 2:30am :)

The power of Squeak et al, to an end user such as my mother, does not lie at the System Browser, but at other tools that allow them to get tasks done, like eToys. Similar to seaside, web surfers never see smalltalk, it just works. In our case, I want to be able to email my mom a working widget game and have her drop it into her scrapbook of stuff her son did.

Power at all levels, when someone needs it. We'll try and get a more formal site up as we release code for people to play with. Right now we're in the mode of learning tweak, building use cases and executing them and getting some issues like OS windows out of the way so we can concentrate on the fun stuff :)

Steve

Hi steven

On 27 juil. 04, at 22:07, Steven Riggins wrote:

Thank you all for understanding. We're going to be doing our part to forward Squeak (We're already working on adding OS windows and all sorts of goodness)

This is really nice to hear that. I think that being aware that other people work on something is the first level of communication and this is important.

We can't really port Tweak until M17n is in place however as we don't want to keep re-porting it. And as it stands, some comments won't even load in properly :)

I'm not asking anyone to build a special Squeak for us. But I think more stable squeaks with shorter life cycles are better for the platform than a 18 month release with 20 new things that cause all sorts of havoc.

Yes. But we are quite a few and doing that the nights :)

Not to mention once this m17n stuff goes in and is debugged, everyone in the community wins with a large step forward.

Stef

Steve

P.S. We don't have a page for TK4 up yet, which will be open source btw. I'm working on it.

On Jul 27, 2004, at 10:10 AM, Julian Fitzell wrote:

...

I actually think this sounds reasonable too. I think it's useful to focus on a specific feature set for a release and m17n certainly seems large enough to pretty much justify its own release. By the time we work out any bugs in it and any other that we come along (plus random other small stuff) there will be plenty of reason to do it. It would also give us practice at getting shorter releases :)

Julian

Andreas Raab wrote:

...

Hi Doug, I think it is worthwhile for a number of ongoing projects to consider a very short 3.8 cycle which basically pulls in the m17n stuff and no more. The reason being that various projects do need a stable point of departure which *does* include m17n and the changes are major enough that they will most definitely need some time to shake down. I think we would be better off if we basically go to beta straight away and maybe have another release two months down the road than putting in (and waiting for!) "new stuff" and have the next release only 6-8 month from now. Cheers,

• Andreas

----- Original Message ----- From: "Doug Way" dway@mailcan.com To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org Sent: Monday, July 26, 2004 10:39 PM Subject: Re: Squeak 3.8 status

...

On Monday, July 26, 2004, at 02:20 PM, Steven Riggins wrote:

...

Hello folks!

We've begun work on TK4 in Tweak. One of the issues that has come up is the internationalization work that Michael and Yoshiki are working on.

Since TK4 depends on this work, I'd like to get a sense of the 3.8 status. I've seen notes from as far back as January, but I don't think 3.8 is done yet.

There was originally talk (early this year) of getting the internationalization work in 3.7, but the i18n changes were major enough that Michael & Yoshiki needed a stable point at which to add the changes, instead of the constantly shifting base of 3.7alpha. So they're being added now as the first item in 3.8alpha, without having to have any other changes go in first.

3.8 is not done yet, it only recently started.

...

I'd like to see 3.8 nailed down to just these changes and finished.

Well, 3.8 was tentatively planned to be a shorter/smaller release (coordinated with the 64-bit 4.0 release) so something like this *might* work out. But we need to hear from the 64-bit folks on this.

(disclaimer: I'm just now looking up "TK4" on Google, although I'm familiar with Tweak & Croquet)

...

As more and more people learn about Squeak/Tweak and more projects start to rely on the wonderful work you do, we're going to need more stable versions than less stable versions, and shorter development cycles for each iteration.

Unfortunately these last two (more stability and shorter development cycles) are in conflict with each other. Well, you can decrease the overall amount of change in Squeak and then I guess you could get both of those things. Or, try to improve the development process in general (e.g. have the equivalent of some direct "committers"), which we're working on, but that's not easy.

Anyway, 3.7 is taking about 9 months instead of the originally planned 6 months, so I agree that is too long. But getting the releases significantly faster than every 6 months... ain't gonna happen anytime soon. It would require someone else taking over the release process from me (for starters), and doing a lot of work on the process...

• Doug

http://www.geeksrus.com/

Let me just point out a small fact that we all IMHO should be aware of:

The open Squeak community (as differentiated from closed projects like Croquet) doesn't have access to Tweak. I have personally just recently *seen* it for the first time. I have no idea about the goals or plans for Tweak. I have no idea how the involved persons joined the project and I have no idea about release plans or licenses or anything else regarding Tweak.

Do not frustrate we will be enlighted once and may be become estatics, who knows? Sometimes I wish I would be less idiot and be more egoist and use my time for my stuff.

I am guessing it will be released to us soon, and I am guessing it will be under a reasonable license, and I am guessing it is meant to become a Morphic replacement and I am guessing that the project will eventually be developed in an open fashion too. And these guesses are also my hopes.

Now, perhaps people think I am too harsh and you get annoyed with me for saying all this. I am not saying that Tweak *must* be open - it can be a closed project and I have absolutely no right to criticize it for that. Heck, I assume there are tons of closed projects out there using Squeak as a base platform!

But my focus is the open Squeak. The stuff we all share. And my focus is the plans laid out for improving and developing open Squeak - in a community fashion. In the open source fashion.

I *love* all those closed projects using Squeak because that is GOOD for Squeak! :)

But I *don't* give those projects a single thought when it comes to the plans for the open Squeak.

So... if anyone want me as a Guide to consider how Tweak should be handled in Squeak - then I am sorry, I don't have an opinion and I can't plan for it, in that respect Tweak doesn't exist yet.

Agreed but if tweaker are going faster that way, let us wait and see. A better morphic sounds like a dream....

And again - please don't get upset at me! :) The Tweak team is fully aware of this and my personal guess is that they *like* to work on it "on their own" and thus are waiting as long as they possibly can until they open it up to the rest of us. Again, that is *their* choice.

stef

Am 26.07.2004 um 20:20 schrieb Steven Riggins:

Hello folks!

We've begun work on TK4 in Tweak. One of the issues that has come up is the internationalization work that Michael and Yoshiki are working on.

Since TK4 depends on this work, I'd like to get a sense of the 3.8 status. I've seen notes from as far back as January, but I don't think 3.8 is done yet.

Doug already answered most of the questions. here are just some general remarks...

If you depend on squeak, you should try to get involved with the harvesting process (or work on improving/replacing that process). You can view that as an "investment" in your own future.

One thing that did hold the release of 3.7 back was that we did not have the manpower to get important fixes in especially in April/May/June. It has gotten a bit better over the last weeks again.

I'd like to see 3.8 nailed down to just these changes and finished. As more and more people learn about Squeak/Tweak and more projects start to rely on the wonderful work you do, we're going to need more stable versions than less stable versions, and shorter development cycles for each iteration.

The problem is that all people involved with squeak 3.7a are not doing Squeak full time in any way. Those who do seem to always have more important stuff to do than the getting trivial fixes added to Squeak...

So those who rely on a stable release are not involved in the process, and those who do the work don't need that stable release.

The only solution I see is that those who need a stable release, uhm, just help to build that?

Marcus

On 27 juil. 04, at 10:14, Marcus Denker wrote:

If you depend on squeak, you should try to get involved with the harvesting process (or work on improving/replacing that process). You can view that as an "investment" in your own future.

I totally agree with marcus. It is CRUCIAL that people making (or wishing) to make money with Squeak invest also in the process. Note that for me I could live happy with any image I patch and do not care to give the result back to the community. In general this costs me to send/harvest changes and I do not get money (nor wish to make money with squeak).

The problem is that all people involved with squeak 3.7a are not doing Squeak full time in any way. Those who do seem to always have more important stuff to do than the getting trivial fixes added to Squeak...

Sad but true. I think that this is the failure of open-source a la squeak even if we got some really nice tools recently (SM, MC, Shout, RB, TestingBrowser).

Stef

Hi lex

We are all volunteers and we do a lot during our nights. And I'm sorry but if one person would help doug the process would go faster. At one point in time I was the only harvester and I can tell you that when marcus joined it was a great feeling.

Lex my main point is that if somebody payed to code in Squeak would spend 1 hour every three days then this would make a big boost.

So I disagree with you, steven cannot say we need shorter iteration cycles, stabler versions and not participate. There are certainly some problems with the current process but it starts to work. Now we have to improve it this is clear, but without BFAV we would be nowhere right now. (Thanks for all the people that are working to improve it. This is really important). I remember the SqueakC time where not funny, cool compiler fixes where simply lost (certainly because of time problems too).

I think that for example a Guide for eToy and Multimedia is NEEDED. I was discussing this issue off-line with the other guides. Now if you find a guru in each the part of Squeak then this is clear that the current process is not efficient enough still having another person browsing your code is always good. At least for me I really appreciate that someone have a look at my fixes because sometimes I'm idiot, tired, or thinking to something else.

Stef

u wrote:

=?ISO-8859-1?Q?st=E9phane_ducasse?= ducasse@iam.unibe.ch wrote:

...

On 27 juil. 04, at 10:14, Marcus Denker wrote:

...

If you depend on squeak, you should try to get involved with the harvesting process (or work on improving/replacing that process). You can view that as an "investment" in your own future.

I totally agree with marcus. It is CRUCIAL that people making (or wishing) to make money with Squeak invest also in the process. Note that for me I could live happy with any image I patch and do not care to give the result back to the community. In general this costs me to send/harvest changes and I do not get money (nor wish to make money with squeak).

I disagree. The current harvesting process is quite inefficient, and we need to fix it, not get even more people to work on it. It is not a good use of time to go through endless patches, most of which any individual reviewer cannot add input to.

To put it another we, we already have TONS of volunteer effort in Squeak. It is crazy to suggest that we need even more before we can make progress. Somehow, we need to figure out how to rationally use the tons of effort we already have.

To show what I am talking about, let me give you a quick story. I received an email a couple of days ago asking that I resubmit a FIX and this time include a test case. Actually, the post did include a test case; it simply wasn't in SUnit form. When I tried to write one, I noticed that the code was no longer broken! It turns out that someone else had fixed it, this time with a SUnit test, and had their fix included.

What do we see from this example?

1. Email was wasted because a clear fix is not done in the most

perfect beaureacratic way. All someone had to do was run the example one-liner that was broken, look at the patch, try the patch, run the code again and see that it was fixed.

2. Multiple people have fixed the same bug. This is wasteful.

3. Everyone is having trouble searching BFAV. At least two people did

not realize the same bug had already been fixed: the person who emailed me, and the other person who fixed it. I myself wasted time trying to build a SUnit test case for something that had already been fixed without my noticing. 4. On the whole, much more effort was expended talking about this bug and the different fixes, than was spent solving the problem itself. This patch changes two lines of code, for a grand total of 14 characters. (It changes "Number" to "Integer" in two places.) Even going through an expedited cross examination would have been overkill for such a tiny patch, but when you look at the quite slow process that happened in practice, it is truly awesome how inefficient we were at dealing with this bug.

My favorite direction to go in would be to put reasonable people in charge of various parts of Squeak, as we have already begun to do so. And if some part of Squeak is too obscure for anyone to volunteer as the maintainer of it, we shouldn't lose too much sleep that it is not being maintained. Once maintainers are in place, we can trust those guys to do the right thing most of the time and not subject them to lots of cross examination on every little change.

If there is a problem with getting people to volunteer, then perhaps the first person to post a fix to a new area should get a chance to become the maintainer for that part. After all, they new enough to fix something, so they have to be a reasonable choice.

Anyway, to make this approach work really well, BFAV would need to have tags for which part of the system a bug report is associated with, and it should be possible for people to reassign those tags. Alternatively, of course, we could use any existing off-the-shelf bug tracker; all of the ones I've seen have this functionality. Even email might work better, honestly, if we also had a swiki page listing the points of contact for each portion of the system.

At any rate, let's please back off from trying to recruit more people to get out of the car and push. Let's focus on getting the engine started.

Lex

lex@cc.gatech.edu wrote:

As a quick case in point, I see six BFAV entries regarding StarBrowser that have not been responded to, and some of them are really trivial. Is Roel even seeing these things? It doesn't appear that he is, and yet, everyone *else* who trawls BFAV is seeing them!

Actually, I have been maintaining the Squeak port of StarBrowser, and have fixed the problems I've seen. But those fixes were to the version that I've been evolving, so I can't just post fixes easily.

And I've been really busy and haven't gotten around to packaging releasing the fixed version. Sorry.

lex@cc.gatech.edu wrote:

My favorite direction to go in would be to put reasonable people in charge of various parts of Squeak, as we have already begun to do so. And if some part of Squeak is too obscure for anyone to volunteer as the maintainer of it, we shouldn't lose too much sleep that it is not being maintained. Once maintainers are in place, we can trust those guys to do the right thing most of the time and not subject them to lots of cross examination on every little change.

Do you mean having different people issuing updates for diffrent parts of Squeak in the update stream ? Or splitting the image up and maintain packages seperatly onSqueak Source and then pull them together using Squeak Map. I can understand that Doug have a heavy responability and workload and maybe his role could be maintained by a group of people.

If there is a problem with getting people to volunteer, then perhaps the first person to post a fix to a new area should get a chance to become the maintainer for that part. After all, they new enough to fix something, so they have to be a reasonable choice.

Or this will scare people away from fixing because they get the responsability for some buggy old stuff ;-) But I guess since they fixed it they want to use it...

Anyway, to make this approach work really well, BFAV would need to have tags for which part of the system a bug report is associated with, and it should be possible for people to reassign those tags. Alternatively, of course, we could use any existing off-the-shelf bug tracker; all of the ones I've seen have this functionality. Even email might work better, honestly, if we also had a swiki page listing the points of contact for each portion of the system.

There is always room for improvments. But some decitions have to be made. Should we split the image into packages? When is this going to happen ? How is packages maintained? Who maintain them ?

At any rate, let's please back off from trying to recruit more people to get out of the car and push. Let's focus on getting the engine started.

Yup.

Karl

Am 02.08.2004 um 17:11 schrieb lex@cc.gatech.edu:

No, I mainly mean that there should be people who can say "yes" to the really obvious bugfixes without needing two approvals and an SUnit test.

This is actualy not how the current process works in practice. I sent you the mail that an Sunit test would be needed because I executed your example, nothing happended that I could trivialy see as "broken". So I just was confused and having a test is quite nice in that case. I should have written that, sorry.

For the process: What is needed as of today is just that someone whom I trust says "yes, that's good". Then I sent an approval. For a lot of simple fixes I do both: I look at the code, file it in, test, and then I approve. This is especialy the case with non-complicated stuff from trusted people (e.g. Ned).

So there is no real complicated process with required SUnit tests, formal peer review or stuff like that. (if you look at the stuff that is already approved you can see that).

I will answer your mails in more detail later.

Marcus

Hi people!

Karl Ramberg karl.ramberg@chello.se wrote:

lex@cc.gatech.edu wrote:

...

...

There is always room for improvments. But some decitions have to be made. Should we split the image into packages? When is this going to happen ? How is packages maintained? Who maintain them ?

Should we split? Yes when easy, no when hard.

When? How about now?

Adam Spitz made some image splitting code a while ago. Let's hope that goes into 3.8.

Let us instead hope someone picks it up, works through it and adapts it so that it can go into 3.8 in pieces. Like I did with some of that stuff (it neeeded work because bits rot). Anyway, what I mean is that things don't magically "go into" 3.8. Things go in if someone works for it.

Anyway, as always I think "small steps" is the way to go. We have some stewards/maintainers lined up and the first step is IMHO to get PackageInfo instances into the image (using the stream) so that we can clearly stakeout a few areas. Then we can continue using BFAV/update stream to maintain those parts, but the difference is that we have people assigned and responsible.

Small steps.

regards, Göran

lex@cc.gatech.edu wrote:

I disagree. The current harvesting process is quite inefficient, and we need to fix it, not get even more people to work on it. It is not a good use of time to go through endless patches, most of which any individual reviewer cannot add input to. [and more details]

Halleluja. Some honest to god, Colin-style "This is not working, we need to change it" feedback. Some points I want to respond to: 1. "buearaucratic" - Marcus answered that partially - the process actually isn't (IMO), but people sometimes experience it that way (for reasons that may or may not depend on them). If you see a way to do that, please say so (preferably, refer to the "official" version on the wiki - that's what people are/should be seeing). 2. Hard to find things in the BFAV - I think you're absolutely right. Some ideas (for anyone that wants to improve the process), in order of increasing madness: - Make the BFAV order the posts according to simple criteria: dont show topics I'm last poster on, show at top subjects I posted on at some point, and am not last poster on... - Use the Bayesian text classifier in Celeste to order the rest of the posts in order of "likely to be interesting to specific user". - Do something server side that annotates/autocloses fixes that are now identical to the code in the image (because another fix got there first, for example). - Use BWT algorithm to detect code duplication between different proposed patches and notify authors so they can merge/review/complete one anothers posts, preventing some of the duplication, and turning it into mutual aid. - Use some sort of classifier (Bayes, SVM...) to detect patches that are "unlikely to be approved", and notify the author. If people start to classify why they don't want to approve a patch ("dont see what it fixes", "don't understand the code", "not documented enough, what the heck is it"...) then patch authors could even get a predicted cause for failure in some cases. 3. Nominate Czars - actually, any approver can nominate himself czar of something, and can approve anything in the area except his own code. Might be a good time to designate more approvers, possibly, as you mention, with topical powers. I do think that anyone that's going to put code into the general system does need a little more qualification than "first post". Don't you? if not, why? I'm thinking a little familiarity with the process and experience (say, reviewing a few of other peoples posts, some a bit complex) might be sufficient for most. 4. Getting new people into the process is wrong - I completely disagree. How else are we going to find out where its broken, and how it can be improved? we need the fresh eyes. But I do completely agree we should also definitely fix the process/tools.

Daniel

To put it another we, we already have TONS of volunteer effort in Squeak. It is crazy to suggest that we need even more before we can make progress. Somehow, we need to figure out how to rationally use the tons of effort we already have.

To show what I am talking about, let me give you a quick story. I received an email a couple of days ago asking that I resubmit a FIX and this time include a test case. Actually, the post did include a test case; it simply wasn't in SUnit form. When I tried to write one, I noticed that the code was no longer broken! It turns out that someone else had fixed it, this time with a SUnit test, and had their fix included.

What do we see from this example?

1. Email was wasted because a clear fix is not done in the most perfect

beaureacratic way. All someone had to do was run the example one-liner that was broken, look at the patch, try the patch, run the code again and see that it was fixed.

2. Multiple people have fixed the same bug. This is wasteful.

3. Everyone is having trouble searching BFAV. At least two people did

not realize the same bug had already been fixed: the person who emailed me, and the other person who fixed it. I myself wasted time trying to build a SUnit test case for something that had already been fixed without my noticing. 4. On the whole, much more effort was expended talking about this bug and the different fixes, than was spent solving the problem itself. This patch changes two lines of code, for a grand total of 14 characters. (It changes "Number" to "Integer" in two places.) Even going through an expedited cross examination would have been overkill for such a tiny patch, but when you look at the quite slow process that happened in practice, it is truly awesome how inefficient we were at dealing with this bug.

My favorite direction to go in would be to put reasonable people in charge of various parts of Squeak, as we have already begun to do so. And if some part of Squeak is too obscure for anyone to volunteer as the maintainer of it, we shouldn't lose too much sleep that it is not being maintained. Once maintainers are in place, we can trust those guys to do the right thing most of the time and not subject them to lots of cross examination on every little change.

If there is a problem with getting people to volunteer, then perhaps the first person to post a fix to a new area should get a chance to become the maintainer for that part. After all, they new enough to fix something, so they have to be a reasonable choice.

Anyway, to make this approach work really well, BFAV would need to have tags for which part of the system a bug report is associated with, and it should be possible for people to reassign those tags. Alternatively, of course, we could use any existing off-the-shelf bug tracker; all of the ones I've seen have this functionality. Even email might work better, honestly, if we also had a swiki page listing the points of contact for each portion of the system.

At any rate, let's please back off from trying to recruit more people to get out of the car and push. Let's focus on getting the engine started.

Lex

You can clearly see that I did too much harvesting last week. It was no example of burocracy, just my fault.

Just to be clear, I actually think you did a fantastic job considering what you were up against.

-Lex

Marcus Denker wrote:

Am 04.08.2004 um 17:38 schrieb lex@cc.gatech.edu:

...

...

You can clearly see that I did too much harvesting last week. It was no example of burocracy, just my fault.

Just to be clear, I actually think you did a fantastic job considering what you were up against.

An I should stress that I, too, think we need to improve the "process". (Even the name is wrong: It suggests non-fun burocracy).

One thing we should try is to move the bugs out of BFAV: They are not dealt with in the harvesting process.

Some non-public Squeak projects have used Mantis with some success. So we should try to use Mantis for Bug-tracking and BFAV for managing reviews/harvesting only.

We already talk offline about the use of a BTS like Mantis with some of you. Can we try to make an experiment for example to manage the bugs in the stable 3.7 ? My vision is to have something like the way the linux kernel dev work : a very conservative stable version with a frozen API and only bug fixes, and an unstable version managed with the BFAV process.

Maybe, we can also have a maintainer for the stable version like Marcelo Tosatti is the Linux kernel 2.4 maintainer. We could have several stable release (3.7.1, 3.7.2, ...) at fixed time, for example every two or three months.

-- oooo Serge Stinckwich OOOOOOOO Université de Caen>CNRS UMR 6072>GREYC>MAD OOESUGOO http://purl.org/net/SergeStinckwich oooooo Smalltalkers do: [:it | All with: Class, (And love: it)] \ / ##