[Squeakfoundation]Order of business ...

[d***@netvision.net.il]

Hi Guides (fellow Squeakers in the audience? ;-)

Three issues we should start moving on, IMO:
1. Process to take physical ownership of updates.
* Scott/SqC - do you have any remaining agenda for 3.4a/3.2.1, to
settle before handing over the "keys"?
* Scott, are you interested in some role (as vaguely ;-) postulated by
goran, or otherwise) under the guidance (sic) of us Guides?
* If neither of the above, can you explain the current existing tools
in the image for handling this and the required resources, so we can
plan a clean transition?

I assume basically we'll need some public readable, Guides writeable
storage space on updates.squeakfoundation.org, and a final update on
both all current servers and versions that changes the urls currently in
the image. Am I missing something?

2. Start planning the next release, in terms of content.
* I'll start a thread on the squeak-dev list to hear what people think.
I'll also outline the process for posting refactorings as I sent to you
guys on the internal "Re: Fwd: Re: Image factoring" thread, and see what
people think.
* Doug, we need to know what's currently on the table of the former
Harvesters group, so we can decide what to integrate, what to reject,
and what to punt to the list and SM.
* If you guys have directions you want the image to take in the near
term beyond what I summarized as "removing constraints", like a merge
plan to VI4, or whatever, I think now would be a good time to mention
it.
* After we get some inputs from all these sources, I suggest we hash
out a basic release road map. As an initial sketch of it's shape (we'll
have actual content later) -
3.4 - a quicky release to remove some constraints and test our process
for refactoring and removing a few obvious applications from Squeak.
3.5 - a slightly longer release to optimize and continue the process,
stabilize our work tools.
4.0 - New image format...

3. VI4/Jitter. Tim, you've mentioned a few times on the list that some
VI4 changes may be incompatible with J5. I'm getting those too-familiar,
unpleasent "we're not communicating and may be heading for some bad
feelings" vibes. Could you, Ian, and Anthony talk business, hash it out
and give us some nice bright future for this? I think the transition to
VI4 will still need quite a bit of work, and J5 compatibility is the
major risk I see, it would be nice to know what we're doing about it.

Daniel

[Stephane Ducasse]

Hi daniel, Guides and Scott

Post by d***@netvision.net.il
1. Process to take physical ownership of updates.
* Scott/SqC - do you have any remaining agenda for 3.4a/3.2.1, to
settle before handing over the "keys"?
* Scott, are you interested in some role (as vaguely ;-) postulate=

d by

Post by d***@netvision.net.il
goran, or otherwise) under the guidance (sic) of us Guides?

I hope Scott is willing to continue his work there. I think that ther=
e=20
is
a lot of space for people like him or Dan that knows the system so we=
ll.

Scott what is your view on that?

Post by d***@netvision.net.il
* If neither of the above, can you explain the current existing to=

ols

Post by d***@netvision.net.il
in the image for handling this and the required resources, so we ca=

n

Post by d***@netvision.net.il
plan a clean transition?
I assume basically we'll need some public readable, Guides writeabl=

e

Post by d***@netvision.net.il
storage space on updates.squeakfoundation.org, and a final update o=

n

Post by d***@netvision.net.il
both all current servers and versions that changes the urls current=

ly=20

Post by d***@netvision.net.il
in
the image. Am I missing something?
2. Start planning the next release, in terms of content.
* I'll start a thread on the squeak-dev list to hear what people=

=20

Post by d***@netvision.net.il
think.
I'll also outline the process for posting refactorings as I sent to=

you

Post by d***@netvision.net.il
guys on the internal "Re: Fwd: Re: Image factoring" thread, and see=

=20

Post by d***@netvision.net.il
what
people think.
* Doug, we need to know what's currently on the table of the forme=

r

Post by d***@netvision.net.il
Harvesters group, so we can decide what to integrate, what to rejec=

t,

Post by d***@netvision.net.il
and what to punt to the list and SM.
* If you guys have directions you want the image to take in the ne=

ar

Post by d***@netvision.net.il
term beyond what I summarized as "removing constraints", like a mer=

ge

Post by d***@netvision.net.il
plan to VI4, or whatever, I think now would be a good time to menti=

on

Post by d***@netvision.net.il
it.
* After we get some inputs from all these sources, I suggest we ha=

sh

Post by d***@netvision.net.il
out a basic release road map. As an initial sketch of it's shape (w=

e'll

Post by d***@netvision.net.il
have actual content later) -
3.4 - a quicky release to remove some constraints and test our pro=

cess

Post by d***@netvision.net.il
for refactoring and removing a few obvious applications from Squeak=

.

Post by d***@netvision.net.il
3.5 - a slightly longer release to optimize and continue the proce=

ss,

Post by d***@netvision.net.il
stabilize our work tools.
4.0 - New image format...
3. VI4/Jitter. Tim, you've mentioned a few times on the list that s=

ome

Post by d***@netvision.net.il
VI4 changes may be incompatible with J5. I'm getting those=20
too-familiar,
unpleasent "we're not communicating and may be heading for some bad
feelings" vibes. Could you, Ian, and Anthony talk business, hash it=

out

Post by d***@netvision.net.il
and give us some nice bright future for this? I think the transitio=

n to

Post by d***@netvision.net.il
VI4 will still need quite a bit of work, and J5 compatibility is th=

e

Post by d***@netvision.net.il
major risk I see, it would be nice to know what we're doing about i=

t.

Post by d***@netvision.net.il
Daniel
_______________________________________________
Squeakfoundation mailing list
http://lists.squeakfoundation.org/listinfo/squeakfoundation

Dr. St=E9phane DUCASSE (***@iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes

[Ned Konz]

Post by d***@netvision.net.il
* Doug, we need to know what's currently on the table of the
former Harvesters group, so we can decide what to integrate, what
to reject, and what to punt to the list and SM.

It looks like we may be able to get some volunteer help with fixing
bugs, removing packages, etc.

Could we perhaps prioritize:

* desired additions (probably SM-related, etc. tools for dealing with
the new shape of the image)

* desired removals from the image

* tests needing to be written and/or tested

* persistent bugs that are getting in our way and need to be fixed
(like, for instance, the FileDirectory problems that have crept in
with 3.4 and have existed with relative paths in MacOS for some
time).

Given a list, we can start signing people up for various tasks...

[g***@bluefish.se]

Ok, guys, everything sounds nice.

I hope Scott is interested and willing to stay as the main "gate keeper"
for a while - but it is of course important to document the process so
that we can both let someone else fill in if needed and also remake the
whole harvesting process given the outlined vision of an interactive
tool.

But let me skip the details for just one more post. I think it would be
good to do these two steps FIRST:

1. Rework the Squeakfoundation Swiki. Rip oup the old cruft, put in some
fresh info - the Mission statement etc. I can start doing this if we
agree on it.
2. Put up a page there with the current Guides and their *roles*. I can
do that too - but you need to help me formulate them, see below.

This last part became quite obvious when I was writing about the near
future in the mission statement. Now I will throw out some roles and see
what you say:

1. Guide of VMs and image format: Tim Rowledge. Coordinate the VMs, the
BC stuff, J5 etc. Tim has the deep knowledge to do this and he is one of
he four horseme... ehrm, I mean VM port maintainers.

2. Guide of image detanglement (dependency analysis and making the base
package friendly): Daniel Vainsencher. Daniel has tools brewing
(Spaghetti tracer), a bunch of good ideas how to make the image more
dynamic and package friendly etc. I think you would fit perfectly in
that role leading the forces forward and handing out responsibility
areas. Much like you just started to do in previous postings here.

3. Guide of SM: Me. I will simply focus on moving SM forward, first step
will be to present the roadmap ahead. Then if people are interested to
help out I will coordinate that.

4. Guide of the update stream: I think Doug is the perfect fit. Having
been a harvester Doug knows the ropes and could start by documenting the
process we have together with Scott and then perhaps start sketching on
a new system for this as we have envisioned. I would like to participate
in the design because SM has quite a lot to do with that. Best would be
if Scott wants to continue doing the updates of course but with
assistance of Doug and perhaps we could also start a more aggressive
collection into our alpha version - it is after all alpha, right? There
are literally TONS of fixes out there. And the focus should be on fixes,
not extra stuff.

5. Guide of (top down) application breakout: Ned Konz. Ned has deep
Morphic knowledge which seems to come handy when ripping out a few apps
from the image! Also given SAR and good knowledge of SM Ned could see to
that we hand out apps to people willing to take them on and help them
break them out and start maintaining them.

6. Guide of (bottom up) kernel image buildup: Craig Latta. Craig has low
level knowledge and an interest in small platforms. Perhaps this is a
perfect fit with Dan Ingalls/Andreas Raab to help us get that small
kernel image and also start layering packages on top of it.


Note that I just whipped these up from thin air - pick, choose, reject
and select according to your own!

regards, Göran

[Ned Konz]

Post by g***@bluefish.se
2. Guide of image detanglement (dependency analysis and making the
base package friendly): Daniel Vainsencher. Daniel has tools
brewing (Spaghetti tracer), a bunch of good ideas how to make the
image more dynamic and package friendly etc. I think you would fit
perfectly in that role leading the forces forward and handing out
responsibility areas. Much like you just started to do in previous
postings here.
5. Guide of (top down) application breakout: Ned Konz. Ned has deep
Morphic knowledge which seems to come handy when ripping out a few
apps from the image! Also given SAR and good knowledge of SM Ned
could see to that we hand out apps to people willing to take them
on and help them break them out and start maintaining them.
6. Guide of (bottom up) kernel image buildup: Craig Latta. Craig
has low level knowledge and an interest in small platforms. Perhaps
this is a perfect fit with Dan Ingalls/Andreas Raab to help us get
that small kernel image and also start layering packages on top of
it.

These seem pretty well tangled up together.

There's some more roles outside the technical issues that relate to
Values #1 (encourage participation by Squeakers of all levels) and #3
(grow the Squeak community and increase its visibility).

7. Guide of community organization. We need someone to coordinate the
various efforts in the Squeak community so that we can involve as
many people as possible. We've mentioned a number of ways this can
happen, but it needs some kind of visible structure so people can
volunteer to do things.

8. Guide of external relations. We need someone to announce releases
to the outside world, prepare press releases, make sure that Squeak
is listed and current on the various software catalogs (not
necessarily do this themselves, but make sure it gets done), etc.

[Cees de Groot]

7. Guide of community organization. We need someone to coordinate the=20
various efforts in the Squeak community so that we can involve as=20
many people as possible. We've mentioned a number of ways this can=20
happen, but it needs some kind of visible structure so people can=20
volunteer to do things.
8. Guide of external relations. We need someone to announce releases=20
to the outside world, prepare press releases, make sure that Squeak=20
is listed and current on the various software catalogs (not=20
necessarily do this themselves, but make sure it gets done), etc.

Dunnow whether you want more Guides or not, but I'm prepared to sign up
for this (certainly the first, but I'll be happy to take both).

[g***@bluefish.se]

Hi all!

Post by Cees de Groot

7. Guide of community organization. We need someone to coordinate the=20
various efforts in the Squeak community so that we can involve as=20
many people as possible. We've mentioned a number of ways this can=20
happen, but it needs some kind of visible structure so people can=20
volunteer to do things.
8. Guide of external relations. We need someone to announce releases=20
to the outside world, prepare press releases, make sure that Squeak=20
is listed and current on the various software catalogs (not=20
necessarily do this themselves, but make sure it gets done), etc.

Dunnow whether you want more Guides or not, but I'm prepared to sign up
for this (certainly the first, but I'll be happy to take both).

Yes, I was also thinking along these lines. Now when/if we are taking
this role-based approach, which I think would be very good (opinions?),
we can probably handle one or two more Guides. Cees is running some
infrastructure, has good connections with other communities and has IMHO
proven earlier quite well that he is committed to the "task".

Btw - sorry for my wording "cruft" about SqF swiki - wasn't implying
that the stuff there was bad in any way - when going in I will of course
not "trash" anything, just move around a bit perhaps.

Or... if the others are ok with you joining us (which I assume) and you
pick 7&8 above then perhaps you could do te reorg of the Swiki, put the
mission statement up there and start nailing down the "role" table.

Typically we could also at the same page record other responsibilities
held by other people than the Guides.

How does this sound?

regards, Göran

[Cees de Groot]

Post by g***@bluefish.se
How does this sound?

Fine with me, but I'll wait for the others to give their say before rushing in
(besides, I'm supposed to run my business at this time ;-))

[Ned Konz]

Post by g***@bluefish.se
Or... if the others are ok with you joining us (which I assume) and
you pick 7&8 above then perhaps you could do te reorg of the Swiki,
put the mission statement up there and start nailing down the
"role" table.

Fine with me! Cees would be a welcome addition.

[Cees de Groot]

Post by g***@bluefish.se
1. Rework the Squeakfoundation Swiki. Rip oup the old cruft, put in some
fresh info - the Mission statement etc. I can start doing this if we
agree on it.

Of course you're more than welcome to rework the Swiki in any manner you see
fit, but a) I'd appreciate it if you would leave the 'old cruft' at least
accessible, and b) I think we still want that official foundation, so AFAIC
this is still on track (postponed, probably, until everyone gets some
breathing room which will probably after the economy recuperates).

Post by g***@bluefish.se
Note that I just whipped these up from thin air - pick, choose, reject
and select according to your own!

Well, in that case I must admire your wipping skills ;-)

[d***@netvision.net.il]

Rework the SqF Swiki - sure, go ahead. We need it in a good initial
state, and we'll all add content as needed.

Roles -
I obviously hope to guide the detanglement process (2), which to me is
almost synonymous to 5. There's plenty of space here for two, and Ned
also has relevant experience packaging a significant application
(connectors) in a non-trivial manner.

I heard Craig was the other volunteer, so I'm pretty sure he has some
clear idea on what he wants to do, which I'd be glad to hear...

If he can sketch a migration path that gives us high quality sockets
that don't bring up GUI, while not breaking everything currently in the
image, I'd be glad to hear that, too.

Daniel

Post by g***@bluefish.se
Ok, guys, everything sounds nice.
I hope Scott is interested and willing to stay as the main "gate keeper"
for a while - but it is of course important to document the process so
that we can both let someone else fill in if needed and also remake the
whole harvesting process given the outlined vision of an interactive
tool.
But let me skip the details for just one more post. I think it would be
1. Rework the Squeakfoundation Swiki. Rip oup the old cruft, put in some
fresh info - the Mission statement etc. I can start doing this if we
agree on it.
2. Put up a page there with the current Guides and their *roles*. I can
do that too - but you need to help me formulate them, see below.
This last part became quite obvious when I was writing about the near
future in the mission statement. Now I will throw out some roles and see
1. Guide of VMs and image format: Tim Rowledge. Coordinate the VMs, the
BC stuff, J5 etc. Tim has the deep knowledge to do this and he is one of
he four horseme... ehrm, I mean VM port maintainers.
2. Guide of image detanglement (dependency analysis and making the base
package friendly): Daniel Vainsencher. Daniel has tools brewing
(Spaghetti tracer), a bunch of good ideas how to make the image more
dynamic and package friendly etc. I think you would fit perfectly in
that role leading the forces forward and handing out responsibility
areas. Much like you just started to do in previous postings here.
3. Guide of SM: Me. I will simply focus on moving SM forward, first step
will be to present the roadmap ahead. Then if people are interested to
help out I will coordinate that.
4. Guide of the update stream: I think Doug is the perfect fit. Having
been a harvester Doug knows the ropes and could start by documenting the
process we have together with Scott and then perhaps start sketching on
a new system for this as we have envisioned. I would like to participate
in the design because SM has quite a lot to do with that. Best would be
if Scott wants to continue doing the updates of course but with
assistance of Doug and perhaps we could also start a more aggressive
collection into our alpha version - it is after all alpha, right? There
are literally TONS of fixes out there. And the focus should be on fixes,
not extra stuff.
5. Guide of (top down) application breakout: Ned Konz. Ned has deep
Morphic knowledge which seems to come handy when ripping out a few apps
from the image! Also given SAR and good knowledge of SM Ned could see to
that we hand out apps to people willing to take them on and help them
break them out and start maintaining them.
6. Guide of (bottom up) kernel image buildup: Craig Latta. Craig has low
level knowledge and an interest in small platforms. Perhaps this is a
perfect fit with Dan Ingalls/Andreas Raab to help us get that small
kernel image and also start layering packages on top of it.
Note that I just whipped these up from thin air - pick, choose, reject
and select according to your own!
regards, Göran
_______________________________________________
Squeakfoundation mailing list
http://lists.squeakfoundation.org/listinfo/squeakfoundation

[Michael Rueger]

***@netvision.net.il wrote:

I would be interested in staying in the loop of 5 and 6.

Post by d***@netvision.net.il
If he can sketch a migration path that gives us high quality sockets
that don't bring up GUI, while not breaking everything currently in the
image, I'd be glad to hear that, too.

I'm about to post my network rewrite that uses exceptions instead of
error:. It overlaps partly with Craig's flow 2.x code, but only partly.

If only fewer emails would come in... ;-)

Michael

[Doug Way]

Post by d***@netvision.net.il
Hi Guides (fellow Squeakers in the audience? ;-)
1. Process to take physical ownership of updates.
* Scott/SqC - do you have any remaining agenda for 3.4a/3.2.1, to
settle before handing over the "keys"?
* Scott, are you interested in some role (as vaguely ;-) postulated by
goran, or otherwise) under the guidance (sic) of us Guides?
* If neither of the above, can you explain the current existing tools
in the image for handling this and the required resources, so we can
plan a clean transition?
I assume basically we'll need some public readable, Guides writeable
storage space on updates.squeakfoundation.org, and a final update on
both all current servers and versions that changes the urls currently in
the image. Am I missing something?

This sounds like the right idea. I can contact Scott about this if he
doesn't respond soon, I'm not sure if he's following this list yet (or
keeping up with the torrent of emails & squeak-dev postings :-) ).

Post by d***@netvision.net.il
2. Start planning the next release, in terms of content.
* I'll start a thread on the squeak-dev list to hear what people think.
I'll also outline the process for posting refactorings as I sent to you
guys on the internal "Re: Fwd: Re: Image factoring" thread, and see what
people think.
* Doug, we need to know what's currently on the table of the former
Harvesters group, so we can decide what to integrate, what to reject,
and what to punt to the list and SM.

Well, there were two bundles of fixes harvested by myself and Luciano
about six months ago, which fell off the table somehow before making it
into the 3.3alpha update stream. These were mostly useful fixes &
refactorings. I could look at (non-module) retrofitting these to
3.4alpha. There haven't been all *that* many updates in the last six
months (which would potentially conflict), so this may not be too hard.

Other than that, there's the usual swarm of fixes/enhancements submitted
to the list over the last 6 months which still haven't been harvested,
or even put "on the table" (in the sqfixes harvesting tables). (Adding
items to the sqfixes is only a semi-automatic process right now, which
is something in the process that we can definitely improve.)

I guess I need to think about whether to generate tables for the list
submissions over the last 6 months, or whether to just issue a call to
the list to re-submit items which people think are important.

Post by d***@netvision.net.il
* If you guys have directions you want the image to take in the near
term beyond what I summarized as "removing constraints", like a merge
plan to VI4, or whatever, I think now would be a good time to mention
it.
* After we get some inputs from all these sources, I suggest we hash
out a basic release road map. As an initial sketch of it's shape (we'll
have actual content later) -
3.4 - a quicky release to remove some constraints and test our process
for refactoring and removing a few obvious applications from Squeak.
3.5 - a slightly longer release to optimize and continue the process,
stabilize our work tools.
4.0 - New image format...

This sounds pretty good, at least for 3.4 and 3.5. (I'll let others
comment on 4.0.)

- Doug

[Luciano Notarfrancesco]

Post by Doug Way
Well, there were two bundles of fixes harvested by myself and Luciano
about six months ago, which fell off the table somehow before making
it into the 3.3alpha update stream. [...]
I guess I need to think about whether to generate tables for the list
submissions over the last 6 months, or whether to just issue a call to
the list to re-submit items which people think are important.

Hi all,
I'm excited about all the news, and I'm happy to see Squeak taking some
impulse again. I'm sorry I haven't had a chance to do much harvesting
lately but, if it's allright with everybody, I intend to continue my
role as a harvester. Let me know when the new tables are up, so I can
start reviewing the submissions.

Peace,
Luciano.-

[Doug Way]

Post by g***@bluefish.se
1. Rework the Squeakfoundation Swiki. Rip oup the old cruft, put in some
fresh info - the Mission statement etc. I can start doing this if we
agree on it.

Yes. You might keep the old SqF intro page around for historical
purposes, but move/rename it and mark it as obsolete.

Post by g***@bluefish.se
2. Put up a page there with the current Guides and their *roles*. I can
do that too - but you need to help me formulate them, see below.
...
4. Guide of the update stream: I think Doug is the perfect fit. Having
been a harvester Doug knows the ropes and could start by documenting the
process we have together with Scott and then perhaps start sketching on
a new system for this as we have envisioned. I would like to participate
in the design because SM has quite a lot to do with that. Best would be
if Scott wants to continue doing the updates of course but with
assistance of Doug and perhaps we could also start a more aggressive
collection into our alpha version - it is after all alpha, right? There
are literally TONS of fixes out there. And the focus should be on fixes,
not extra stuff.

Sounds good, you can put me down for that role. See my reply to Daniel
about how to handle the current load of fixes. Also, we'll have to
figure out how much time to spend on collecting fixes versus working on
a new harvesting system (which could help quite a bit).

- Doug

[d***@netvision.net.il]

Great. I'd suggest to make ourselves visible to Python and Ruby people.
They might be attracted, since the languages are relatively similar.

I think it would be great to attract the participation of more people
that are open source veterans into the Squeak and Smalltalk communities
- our diversity of opinions/skills is our strength.

Also, connections with other open source communities might lead us to
interesting collaborations.

But I don't actually know these communities.. more data, anyone?

Daniel

Post by Ned Konz

Post by g***@bluefish.se
2. Guide of image detanglement (dependency analysis and making the
base package friendly): Daniel Vainsencher. Daniel has tools
brewing (Spaghetti tracer), a bunch of good ideas how to make the
image more dynamic and package friendly etc. I think you would fit
perfectly in that role leading the forces forward and handing out
responsibility areas. Much like you just started to do in previous
postings here.
5. Guide of (top down) application breakout: Ned Konz. Ned has deep
Morphic knowledge which seems to come handy when ripping out a few
apps from the image! Also given SAR and good knowledge of SM Ned
could see to that we hand out apps to people willing to take them
on and help them break them out and start maintaining them.
6. Guide of (bottom up) kernel image buildup: Craig Latta. Craig
has low level knowledge and an interest in small platforms. Perhaps
this is a perfect fit with Dan Ingalls/Andreas Raab to help us get
that small kernel image and also start layering packages on top of
it.

These seem pretty well tangled up together.
There's some more roles outside the technical issues that relate to
Values #1 (encourage participation by Squeakers of all levels) and #3
(grow the Squeak community and increase its visibility).
7. Guide of community organization. We need someone to coordinate the
various efforts in the Squeak community so that we can involve as
many people as possible. We've mentioned a number of ways this can
happen, but it needs some kind of visible structure so people can
volunteer to do things.
8. Guide of external relations. We need someone to announce releases
to the outside world, prepare press releases, make sure that Squeak
is listed and current on the various software catalogs (not
necessarily do this themselves, but make sure it gets done), etc.
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
_______________________________________________
Squeakfoundation mailing list
http://lists.squeakfoundation.org/listinfo/squeakfoundation

[Cees de Groot]

Post by d***@netvision.net.il
Great. I'd suggest to make ourselves visible to Python and Ruby people.
They might be attracted, since the languages are relatively similar.

Yeah, but you must be careful not to tread on long toes and incite language
flame wars. So it's probably wiser to stick to the general community:
- SEUL project (www.seul.org), especially the educational subproject and
the spin-off (IIRC) schoolforge.net;
- Freshmeat, Avogato, Kuro5hin, Slashdot, Linux News, ...;
- Whysmalltalk, STIC, goodstart, ...
- c.o.l.announce, c.l.smalltalk;
etcetera.

[Jimmie Houchin]

I agree general communities are better. No need for direct confrontation
in any of the other language groups. The people of interest in those
groups will also read general community sites. I think that we need to
be relatively inclusive of general communities as Squeak is so
multiplatform. *nix is very open source and an easy target, but I
believe we should also inform and educate the Win and Mac camps, too.

I believe that there is no need for being confrontational. We will do
well enough being informational.

Jimmie Houchin

Post by Cees de Groot

Post by d***@netvision.net.il
Great. I'd suggest to make ourselves visible to Python and Ruby people.
They might be attracted, since the languages are relatively similar.

Yeah, but you must be careful not to tread on long toes and incite language
- SEUL project (www.seul.org), especially the educational subproject and
the spin-off (IIRC) schoolforge.net;
- Freshmeat, Avogato, Kuro5hin, Slashdot, Linux News, ...;
- Whysmalltalk, STIC, goodstart, ...
- c.o.l.announce, c.l.smalltalk;
etcetera.

[Ned Konz]

Post by d***@netvision.net.il
But I don't actually know these communities.. more data, anyone?

Avi and I (and probably others) are members of the Ruby community.

Randal Schwartz, I and several others are members of the Perl
community.

One long-running discussion in those two communities has to do with a
common bytecode interpreter/jitter (like Parrot); Squeak has been
pretty independent along these lines.

I think that many Rubyists would be easily attracted to Squeak due to
the similarities in the object model and its nicer environment; don't
know about Perl people.

[Jimmie Houchin]

I've always wanted to see Squeak stuff on LWN like the other languages
have. I would consider volunteering for this and some PR in general.

I don't currently know what other sources of PR are available but would
be willing to research.

I believe as Squeak 3.4 becomes more viable and apps are installable and
uninstallable, then Squeak will become more attractive to more people.

I believe people from other language communities will be interested. One
can't count how many times "Which GUI should I use?" pops up in
c.l.python and I imagine everywhere else but c.l.tcl. Some people
require (or at least so they think) a native GUI. I personally don't
think it is as big a requirement as much as having a nice attractive
GUI. Squeak can win people here, IMHO.

My apologies if I shouldn't have posted here. I don't know if such a
determination has been made. If so let me know and I'll crosspost
further comments into squeak-dev.

Jimmie Houchin

Post by d***@netvision.net.il
Great. I'd suggest to make ourselves visible to Python and Ruby people.
They might be attracted, since the languages are relatively similar.
I think it would be great to attract the participation of more people
that are open source veterans into the Squeak and Smalltalk communities
- our diversity of opinions/skills is our strength.
Also, connections with other open source communities might lead us to
interesting collaborations.
But I don't actually know these communities.. more data, anyone?
Daniel

[snip]

[d***@netvision.net.il]

Until we have some automatic infrastructure to pick up everything
posted, I would not want to commit to us picking everything up - I don't
want to be enslaved to a work load we can't keep up with.

Pointing the community to what has been gathered, and telling them to
tell us what they want sounds good.

What do you think the infrastructure should look like so we can get a
better process up? given Seaside and related technology, I'm sure
someone in the community could help us realize this, if we can post a
clear sketch of minimal, critical functionality for a first release.

Daniel

Post by Doug Way

Post by d***@netvision.net.il
Hi Guides (fellow Squeakers in the audience? ;-)
1. Process to take physical ownership of updates.
* Scott/SqC - do you have any remaining agenda for 3.4a/3.2.1, to
settle before handing over the "keys"?
* Scott, are you interested in some role (as vaguely ;-) postulated by
goran, or otherwise) under the guidance (sic) of us Guides?
* If neither of the above, can you explain the current existing tools
in the image for handling this and the required resources, so we can
plan a clean transition?
I assume basically we'll need some public readable, Guides writeable
storage space on updates.squeakfoundation.org, and a final update on
both all current servers and versions that changes the urls currently in
the image. Am I missing something?

This sounds like the right idea. I can contact Scott about this if he
doesn't respond soon, I'm not sure if he's following this list yet (or
keeping up with the torrent of emails & squeak-dev postings :-) ).

Post by d***@netvision.net.il
2. Start planning the next release, in terms of content.
* I'll start a thread on the squeak-dev list to hear what people think.
I'll also outline the process for posting refactorings as I sent to you
guys on the internal "Re: Fwd: Re: Image factoring" thread, and see what
people think.
* Doug, we need to know what's currently on the table of the former
Harvesters group, so we can decide what to integrate, what to reject,
and what to punt to the list and SM.

Well, there were two bundles of fixes harvested by myself and Luciano
about six months ago, which fell off the table somehow before making it
into the 3.3alpha update stream. These were mostly useful fixes &
refactorings. I could look at (non-module) retrofitting these to
3.4alpha. There haven't been all *that* many updates in the last six
months (which would potentially conflict), so this may not be too hard.
Other than that, there's the usual swarm of fixes/enhancements submitted
to the list over the last 6 months which still haven't been harvested,
or even put "on the table" (in the sqfixes harvesting tables). (Adding
items to the sqfixes is only a semi-automatic process right now, which
is something in the process that we can definitely improve.)
I guess I need to think about whether to generate tables for the list
submissions over the last 6 months, or whether to just issue a call to
the list to re-submit items which people think are important.

Post by d***@netvision.net.il
* If you guys have directions you want the image to take in the near
term beyond what I summarized as "removing constraints", like a merge
plan to VI4, or whatever, I think now would be a good time to mention
it.
* After we get some inputs from all these sources, I suggest we hash
out a basic release road map. As an initial sketch of it's shape (we'll
have actual content later) -
3.4 - a quicky release to remove some constraints and test our process
for refactoring and removing a few obvious applications from Squeak.
3.5 - a slightly longer release to optimize and continue the process,
stabilize our work tools.
4.0 - New image format...

This sounds pretty good, at least for 3.4 and 3.5. (I'll let others
comment on 4.0.)
- Doug
_______________________________________________
Squeakfoundation mailing list
http://lists.squeakfoundation.org/listinfo/squeakfoundation

[d***@netvision.net.il]

Sounds like we have some expertise here. So what do we have to offer
those general communities? Can we "sell" them Swiki's, or anything else
we already have? is anyone in their lists, and knows what they need?

Daniel

Post by Jimmie Houchin
I agree general communities are better. No need for direct confrontation
in any of the other language groups. The people of interest in those
groups will also read general community sites. I think that we need to
be relatively inclusive of general communities as Squeak is so
multiplatform. *nix is very open source and an easy target, but I
believe we should also inform and educate the Win and Mac camps, too.
I believe that there is no need for being confrontational. We will do
well enough being informational.
Jimmie Houchin

Post by Cees de Groot

Post by d***@netvision.net.il
Great. I'd suggest to make ourselves visible to Python and Ruby people.
They might be attracted, since the languages are relatively similar.

Yeah, but you must be careful not to tread on long toes and incite language
- SEUL project (www.seul.org), especially the educational subproject and
the spin-off (IIRC) schoolforge.net;
- Freshmeat, Avogato, Kuro5hin, Slashdot, Linux News, ...;
- Whysmalltalk, STIC, goodstart, ...
- c.o.l.announce, c.l.smalltalk;
etcetera.

_______________________________________________
Squeakfoundation mailing list
http://lists.squeakfoundation.org/listinfo/squeakfoundation

[Cees de Groot]

Post by d***@netvision.net.il
Sounds like we have some expertise here. So what do we have to offer
those general communities? Can we "sell" them Swiki's, or anything else
we already have? is anyone in their lists, and knows what they need?

Let's take it step by step - first some general brand marketing, because
no-one is going to be interested in Wiki implementation number 42 when they
have never heard of Squeak. Probably play on the strong points:
- Heritage. In the area of OO and GUI's, Squeak is top breed;
- Portability. The only platform that runs bit-identical on X (how many?)
machines, including multimedia;
- Scope.

[Jimmie Houchin]

I agree that Squeak OO, GUI, portability and scope are strong points.

While we may not have a quote "best of breed" app in any particular area
as you say we have many (I hate to put this way) "good enough) apps.

I believe these apps and others (as they come) will grow and improve as
3.4 matures. I believe as apps are extracted (from the image) or are
developed (new) in SM independent manner that the apps will continue to
improve in quality.

Due to the strengths of Squeak the apps you mentioned and other can
become either best of breed or top tier apps in their area.

I would love to see Celeste become a best of breed email app. In my
opinion I don't like much in the way of Windows or Mac email clients (or
Linux for that matter). I would love to use Celeste but its UI doesn't
currently meet my needs. But it will :).

Because apps in Squeak are in a live environment they can improve
magnitudes in short order.

As discussed on the squeak-dev Squeak's living environment is also to me
a killer app aspect. Because of this no app is ever necessarily stagnate.

[Cees de Groot]

Post by Jimmie Houchin
While we may not have a quote "best of breed" app in any particular area
as you say we have many (I hate to put this way) "good enough) apps.

I *love* to put it this way. MS Office and StarOffice are best-of-breed
apps, in their market. They're bulky, bloated monsters and no-one uses
more than 5% of their features. IMNSHO, Squeak should aim at supplying
'good enough' apps and giving the user - or at least the nearest techie -
the means to make it 'just what I need' apps.

Post by Jimmie Houchin
I believe these apps and others (as they come) will grow and improve as
3.4 matures.

Improve yes. I think I can do without the growth ;-)

Post by Jimmie Houchin
I would love to use Celeste but its UI doesn't
currently meet my needs.

You don't like the GUI. I don't like the fact that it doesn't IMAP. Alice
doesn't like the fact that it doesn't do full-text search. Bob doesn't like
the fact that it doesn't have an attachment database with preview buttons and
free indexing feels. Carol doesn't like the fact that it doesn't do her
laundry.

Now, how are we going to make sure that Celeste becomes to everyone what
everyone wants without making it a bloated monster? I already read my mail
with a bloated monster (Mozilla), I don't need Celeste for that. Here lies the
challenge, I think.

Post by Jimmie Houchin
Because apps in Squeak are in a live environment they can improve
magnitudes in short order.

Absolutely. However, pointing this out in a marketing campaign steps
firmly on the long toes of developers that work in language D+#^, who
are certain that their language is the most productive one in the world...

Post by Jimmie Houchin
I know I've seen many from the Python community come and go. I've stayed
because I saw the potential which I've seen nowhere else. The potential
is unequaled.

That's because the Python community people expected a great language, a
great development environment, and are used to great documentation. They
didn't find all that and decided to stick with Python. Lesson learnt:
marketing/sales is for a big part about managing expectations. If we entice
them with a development environment and give them Croquest, even though
Croquet is the greatest thing since the greatest thing since sliced bread,
they are going to turn away.

[Jimmie Houchin]

Post by Cees de Groot

Post by Jimmie Houchin
While we may not have a quote "best of breed" app in any particular area
as you say we have many (I hate to put this way) "good enough" apps.

I *love* to put it this way. MS Office and StarOffice are best-of-breed
apps, in their market. They're bulky, bloated monsters and no-one uses
more than 5% of their features. IMNSHO, Squeak should aim at supplying
'good enough' apps and giving the user - or at least the nearest techie -
the means to make it 'just what I need' apps.

While many might consider MS Word a best of breed app. I believe MS
killed the best of breed app along Word's (MS's) path of destruction.
Because of its bulk, bloat and kitchen-sink manner I have a hard time
classifying it as best of breed. I may be a minority. Oh well.

I personally use MS Works on my Windows box and Apple Works on my Macs
and feel few constraints with regard to word processing. Most
limitations could be overcome without coming near approaching MS Word.

Post by Cees de Groot

Post by Jimmie Houchin
I believe these apps and others (as they come) will grow and improve as
3.4 matures.

Improve yes. I think I can do without the growth ;-)

Growth can occur intelligently and without bloat. That's one nice thing
about Squeak. If an app begins to bloat, we can do something about it.

Post by Cees de Groot

Post by Jimmie Houchin
I would love to use Celeste but its UI doesn't
currently meet my needs.

You don't like the GUI. I don't like the fact that it doesn't IMAP. Alice
doesn't like the fact that it doesn't do full-text search. Bob doesn't like
the fact that it doesn't have an attachment database with preview buttons and
free indexing feels. Carol doesn't like the fact that it doesn't do her
laundry.
Now, how are we going to make sure that Celeste becomes to everyone what
everyone wants without making it a bloated monster? I already read my mail
with a bloated monster (Mozilla), I don't need Celeste for that. Here lies the
challenge, I think.

I think we are up to the challenge. I too use that bloated email client.

Post by Cees de Groot

Post by Jimmie Houchin
Because apps in Squeak are in a live environment they can improve
magnitudes in short order.

Absolutely. However, pointing this out in a marketing campaign steps
firmly on the long toes of developers that work in language D+#^, who
are certain that their language is the most productive one in the world...

This is where I believe as I stated previously we don't need to be
confrontational. Stating a fact about Squeak in a general community
forum is lifting Squeak up and enlightening others about Squeak. It is
not a means of putting down any other language. This isn't about putting
other languages down, but lifting Squeak up. Squeak is far more than a
language.

In general forums like LWN where a multiplicity of languages are
reported on there should be no reason for offense over simple reportings
of Squeak Community activities, new apps, mailing list discussions, etc.
Or simply a link to the latest Squeakly News. No need for us to ever
bring up other languages in our statements about Squeak. We are neither
doing nor initiating a comparison. We can never prevent someone from
being offended should they choose to be so. Oh well. They can grow up,
and we can move on.

Post by Cees de Groot

Post by Jimmie Houchin
I know I've seen many from the Python community come and go. I've stayed
because I saw the potential which I've seen nowhere else. The potential
is unequaled.

That's because the Python community people expected a great language, a
great development environment, and are used to great documentation. They
marketing/sales is for a big part about managing expectations. If we entice
them with a development environment and give them Croquest, even though
Croquet is the greatest thing since the greatest thing since sliced bread,
they are going to turn away.

That is all true. Documentation and tutorials are an area in which we
could improve. I believe we will. And I believe we will attract people
who can and will contribute in those areas.

One simple fact is that we don't need everybody. :)

If someone comes our way and isn't happy with whatever and has no
intention of helping us improve whatever, then we and they are better
off with them returning to whence they came.
And that is alright. Nothing wrong about it.

Natural growth and attrition are better than artificial growth and
traumatic attrition.

I would much rather see simple educational and informational pieces out
in the general communities. Statements beyond those areas can occur
within our own community and our own materials. No one should be
surprised to come into our home and see us speaking proudly of our
chosen product, tool, environment, our Squeak.

We want natural growth with right people.
Those people are self chosen. They aren't chosen by us.
But we do need educational and informational literature out there so
that the right people can be exposed to us.

Uh oh. Run on post. Better stop. :)

Jimmie Houchin

[Ned Konz]

I do think that as a 'killer app', we should try to see whether we
can come up with power-point like functionality. If I'm correct,
the largest problem at the moment is that the BookMorph doesn't
work good enough (b/c, AFAIK - I'm a moronic nitwit kind of guy in
the Morphic area - it doesn't have the ability to pop into
full-screen mode you are used to from presentation software).

Make Squeak full-screen: Navigator/Escape browser.

Hide flaps.

BookMorph, menu (little dot in the middle top), "show full screen"

It would be a good idea to make this keystroke sensitive; I think this
is about a 2 minute job (Goran did this for his presentation
quickly).

[Cees de Groot]

Post by Ned Konz
Make Squeak full-screen: Navigator/Escape browser.
Hide flaps.
BookMorph, menu (little dot in the middle top), "show full screen"
It would be a good idea to make this keystroke sensitive; I think this=20
is about a 2 minute job (Goran did this for his presentation=20
quickly).

Write docs.

Write tutorials.

Write examples.

- that's the hard part (and not our strongest side - it seems we have
forgot to appoint a Guide here ;-)).

Target audience: first, say the guys who think it's cool to give presentations
that are not based on PowerPoint or StarImpress (typical tools-for-suits) but
know zilch about Squeak/Smalltalk although they're probably tech-savvy.
Later, suits.

(tentative name: 'Roar' ;-))

[Jimmie Houchin]

I don't know about expertise. ;)
I have some opinions and many ideas and I may have kissed the Blarney
Stone early in life. :)

I have been part of the c.s.mac* communities, c.l.python, zope, long
time reader and subscriber to LWN.

I am not a professional programmer, nor do I play one on TV.
I am merely a very high level end user. And I view Squeak through such
eyes. I know what I want and have seen others want as end users.

I see Squeak as an enabling technology for people at all levels. There
is no "Operating Environment" or development technology more enabling
and more open for all users than Squeak. JMHO. :)

I have many app ideas I want to build in Squeak, because of the many
virtues Squeak brings to the table. I am teaching my 14 year old son
Squeak. I hope as Squeak matures to have apps that the rest of my family
use in Squeak.

I am willing to volunteer my expertise towards whatever direction is
deemed best.

Thanks,

Jimmie Houchin

Post by d***@netvision.net.il
Sounds like we have some expertise here. So what do we have to offer
those general communities? Can we "sell" them Swiki's, or anything else
we already have? is anyone in their lists, and knows what they need?
Daniel

Post by Jimmie Houchin
I agree general communities are better. No need for direct confrontation
in any of the other language groups. The people of interest in those
groups will also read general community sites. I think that we need to
be relatively inclusive of general communities as Squeak is so
multiplatform. *nix is very open source and an easy target, but I
believe we should also inform and educate the Win and Mac camps, too.
I believe that there is no need for being confrontational. We will do
well enough being informational.
Jimmie Houchin

Post by Cees de Groot

Post by d***@netvision.net.il
Great. I'd suggest to make ourselves visible to Python and Ruby people.
They might be attracted, since the languages are relatively similar.

Yeah, but you must be careful not to tread on long toes and incite language
- SEUL project (www.seul.org), especially the educational subproject and
the spin-off (IIRC) schoolforge.net;
- Freshmeat, Avogato, Kuro5hin, Slashdot, Linux News, ...;
- Whysmalltalk, STIC, goodstart, ...
- c.o.l.announce, c.l.smalltalk;
etcetera.

[Doug Way]

Post by Luciano Notarfrancesco

Post by Doug Way
Well, there were two bundles of fixes harvested by myself and Luciano
about six months ago, which fell off the table somehow before making
it into the 3.3alpha update stream. [...]
I guess I need to think about whether to generate tables for the list
submissions over the last 6 months, or whether to just issue a call to
the list to re-submit items which people think are important.

Hi all,
I'm excited about all the news, and I'm happy to see Squeak taking some
impulse again. I'm sorry I haven't had a chance to do much harvesting
lately but, if it's allright with everybody, I intend to continue my
role as a harvester. Let me know when the new tables are up, so I can
start reviewing the submissions.

Hi Luciano.

It would be great if you want to continue on as a harvester. We will
still need a group of harvesters oustide of the current Guides. The
Guides may do a little bit a harvesting too, but they have enough other
stuff to worry about without trying to do all the harvesting.

Eventually, as the image is split up into packages, the harvesting
process will become more package-specific, but until that time (and
possibly even after), we'll probably need a coordinated group of
harvesters.

For now, feel free to follow the discussions on the SqF list... we'll
continue to discuss how the harvesting process can be improved.

- Doug

[Doug Way]

I sent a somewhat lengthy reply to this last night, but the new email
client I was trying pretended to send the message, without notifying me
the smtp server was down and without saving a local copy. Argh! >:-(

Post by d***@netvision.net.il
Until we have some automatic infrastructure to pick up everything
posted, I would not want to commit to us picking everything up - I don't
want to be enslaved to a work load we can't keep up with.
Pointing the community to what has been gathered, and telling them to
tell us what they want sounds good.

Yes, I've been thinking the same thing. Then we could just harvest the
relatively small amount of important fixes/cleanups that people tell us
about the second time. I guess the list of "what has been gathered" is
simply the last six months or so of Bert's SQFIXES site.
http://swiki.gsug.org:8080/SQFIXES/

I should probably send out this request for important fixes to the list
soon.

Post by d***@netvision.net.il
What do you think the infrastructure should look like so we can get a
better process up? given Seaside and related technology, I'm sure
someone in the community could help us realize this, if we can post a
clear sketch of minimal, critical functionality for a first release.

I haven't thought too much about how the back-end infrastructure might
work. It could be based on SqueakMap or something else.

But we definitely want it to be automated so that
bugfix/enhancement/refactoring submissions are compiled somewhere with
no manual effort on our part.

One way to do this would be to simply require that people use a tool
(either a tool within Squeak, or a web form like with SqueakMap uploads)
to submit these submissions. There would be additional benefits in
requiring that certain file formats and information be included with
submissions via such a tool (whereas the current submissions are kind of
a free-for-all, sometimes the formatting is bad, etc.).

I don't think this would be too harsh a requirement for the community.
An automatically-generated email could still be sent to the squeak-dev
list, so people would still see fixes/etc coming in.

Then we would want some sort of upload space to exist, maybe just ftp
space on squeakfoundation.org or something, where the submissions would
be stored. The harvesters would need to be able to look at the list of
submissions, and be able to annotate them somehow as being "approved",
"rejected", or otherwise commented upon.

This is kind of sounding like something that SqueakMap would be able to
handle, with some customization. It would be a separate catalog from
the usual SM packages, of course. And the submissions themselves would
need to be stored somewhere. But SM would perhaps be good for storing
the meta-info (annotations, etc.) about each submission. A special UI
(different from SMLoader/SMBrowser) would need to be developed for the
harvesters to use to do the annotating, but it could probably start out
relatively simple.

Having both the submission tool and the harvesting/browsing tool within
Squeak would provide opportunities for cool functionality... e.g. my
ConflictChecker utility could be run on a submission by a simple
menu-click.

Or there might be other better ways to do this. I'm just throwing
around ideas right now, and it's getting a bit late. :)

- Doug

[Ned Konz]

Post by Doug Way

Post by d***@netvision.net.il
What do you think the infrastructure should look like so we can
get a better process up? given Seaside and related technology,
I'm sure someone in the community could help us realize this, if
we can post a clear sketch of minimal, critical functionality for
a first release.

I haven't thought too much about how the back-end infrastructure
might work. It could be based on SqueakMap or something else.
But we definitely want it to be automated so that
bugfix/enhancement/refactoring submissions are compiled somewhere
with no manual effort on our part.

I've been considering using Avi's new Repository stuff to grab stuff
off the Squeak list (like sqfixes does), tag it with proper comments
(like the message it was attached to), and then provide it to a
separate UI.

[Doug Way]

Post by Ned Konz

Post by Doug Way
I haven't thought too much about how the back-end infrastructure
might work. It could be based on SqueakMap or something else.
But we definitely want it to be automated so that
bugfix/enhancement/refactoring submissions are compiled somewhere
with no manual effort on our part.

I've been considering using Avi's new Repository stuff to grab stuff
off the Squeak list (like sqfixes does), tag it with proper comments
(like the message it was attached to), and then provide it to a
separate UI.

[g***@bluefish.se]

Doug Way <***@riskmetrics.com> wrote:
[SNIP]

Post by Doug Way
I haven't thought too much about how the back-end infrastructure might
work. It could be based on SqueakMap or something else.
But we definitely want it to be automated so that
bugfix/enhancement/refactoring submissions are compiled somewhere with
no manual effort on our part.
One way to do this would be to simply require that people use a tool
(either a tool within Squeak, or a web form like with SqueakMap uploads)
to submit these submissions. There would be additional benefits in
requiring that certain file formats and information be included with
submissions via such a tool (whereas the current submissions are kind of
a free-for-all, sometimes the formatting is bad, etc.).
I don't think this would be too harsh a requirement for the community.
An automatically-generated email could still be sent to the squeak-dev
list, so people would still see fixes/etc coming in.
Then we would want some sort of upload space to exist, maybe just ftp
space on squeakfoundation.org or something, where the submissions would
be stored. The harvesters would need to be able to look at the list of
submissions, and be able to annotate them somehow as being "approved",
"rejected", or otherwise commented upon.
This is kind of sounding like something that SqueakMap would be able to
handle, with some customization. It would be a separate catalog from
the usual SM packages, of course. And the submissions themselves would
need to be stored somewhere. But SM would perhaps be good for storing
the meta-info (annotations, etc.) about each submission. A special UI
(different from SMLoader/SMBrowser) would need to be developed for the
harvesters to use to do the annotating, but it could probably start out
relatively simple.
Having both the submission tool and the harvesting/browsing tool within
Squeak would provide opportunities for cool functionality... e.g. my
ConflictChecker utility could be run on a submission by a simple
menu-click.
Or there might be other better ways to do this. I'm just throwing
around ideas right now, and it's getting a bit late. :)
- Doug

I think that if we take the SM codebase plus it's two current UIs and
simply hack it a bit for dealing with FIX/ENH stuff then it would work
very good.

We can always have some "interconnection" between the two catalogs by
linking to UUIDs of packages. But you typically don't want to mix these
two catalogs together - they wil have different mechanisms and you
seldom want to load/look in both.

regards, Göran

[Anthony Hannan]

Again, we need some kind of modeling of packages. Right now there are
* SqueakMap's card
* PackageInfo (previously a part of DVS, now separate).
I see these as being complementary; the SqueakMap deals with releases
and finding them, and the PackageInfo deals with code.

What about classes as packages as per my recent email entitled "Class
Dependencies". I really think we should consider this.

Cheers,
Anthony

[Stephane Ducasse]

Hi anthony

I think that classes are not packages. I think that this really=20
important
not to have classes as packages. Because packages are groups of
declaration (class def, method def, var def).

We can unify everything and at the end we got a magna.
Some programming languages try to unify classes and modules but
conceptually this is really different and when you teach concepts abo=
ut=20
OO
you never have classes as subsystem.

So I would vote really against it.

Stef

Again, we need some kind of modeling of packages. Right now there =

are

* SqueakMap's card
* PackageInfo (previously a part of DVS, now separate).
I see these as being complementary; the SqueakMap deals with relea=

ses

and finding them, and the PackageInfo deals with code.

What about classes as packages as per my recent email entitled "Cla=

ss

Dependencies". I really think we should consider this.
Cheers,
Anthony
_______________________________________________
Squeakfoundation mailing list
http://lists.squeakfoundation.org/listinfo/squeakfoundation

Dr. St=E9phane DUCASSE (***@iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes

[g***@bluefish.se]

Post by Anthony Hannan

Again, we need some kind of modeling of packages. Right now there are
* SqueakMap's card
* PackageInfo (previously a part of DVS, now separate).
I see these as being complementary; the SqueakMap deals with releases
and finding them, and the PackageInfo deals with code.

What about classes as packages as per my recent email entitled "Class
Dependencies". I really think we should consider this.
Cheers,
Anthony

Well, I need some time to read your post more carefully - but my initial
reaction is that I don't really think it will work in practice. It is
simply too "fine granular". IMHO one of the whole points in talking
about packages is the fact that we indeed try to group things together
in bigger more understandable chunks.

It seems to me that simply saying class == package doesn't solve
anything.

But again, I need to read it more carefully.

regards, Göran

[Avi Bryant]

I haven't tried the Repository stuff yet... is it working well enough
now that it could be used for this? If you wanted to put something
together on a test server, that might be interesting.

I'm going to put up a test public repository later today - just need to
write some brief docs first.

With tweaking, it sounds like either the Repository stuff or SqueakMap
might be a usable framework for dealing with harvesting. The Repository
stuff is missing some security stuff which SqueakMap has, but SqueakMap
doesn't include actual file storage. There are probably other
trade-offs. (I haven't really used either one yet enough.)

I'll definitely want to add security to the repository quite soon anyway.

We do need this in general, although I'm not sure if it relates to
harvesting. I would assume most fix/enhancement submissions would be
changesets, not packages.
Or are you saying that a submission should have a way to refer to a
package? That would be good. Eventually, people will need to be able
to submit a fix to a specific package, and the harvesting may become
more package-based. (Although some fixes/enhancements may require
changes to more than one package.)

[g***@bluefish.se]

Hey!

Post by Avi Bryant

I haven't tried the Repository stuff yet... is it working well enough
now that it could be used for this? If you wanted to put something
together on a test server, that might be interesting.

I'm going to put up a test public repository later today - just need to
write some brief docs first.

With tweaking, it sounds like either the Repository stuff or SqueakMap
might be a usable framework for dealing with harvesting. The Repository
stuff is missing some security stuff which SqueakMap has, but SqueakMap
doesn't include actual file storage. There are probably other
trade-offs. (I haven't really used either one yet enough.)

[SNIP]

Just a few notes. I IRCed with Luciano yesterday and the day before and
I sketched out how the SM codebase can be used to produce a harvesting
tool independent of SM but using the same architecture (with uploads
added of course). He got very excited, sat down and looked through the
SM code, liked it and is itching badly to help out on this!

So Doug, perhaps we could do something like this:
- Perhaps you Doug could list what you think the tool would/should
do/need? On the Swiki typically. I can help also.
- Then we look at what we got in the form of code and combine it into a
nice tool. I could see the SM codebase in conjunction with Monticello
forming a nice toolset. They complement each other nicely.
- And especially, we could use Monticello to develop this tool in the
first place!
- And we hook up with Luciano of course.

Anyway, I am on IRC now and for the next 8 hours - irc.openprojects.net,
channel #squeak. Use the new IRC client - it's great (even though it
seemed to remove the "dynamic open menu"...)!

regards, Göran

[Doug Way]

Post by g***@bluefish.se
Just a few notes. I IRCed with Luciano yesterday and the day before and
I sketched out how the SM codebase can be used to produce a harvesting
tool independent of SM but using the same architecture (with uploads
added of course). He got very excited, sat down and looked through the
SM code, liked it and is itching badly to help out on this!

That sounds good... I was thinking about this yesterday.

Poking around in the SqueakMap code, I figured out that the SqueakMap
server code ("master"?) is also in the SqueakMap package, and that it
runs with Comanche. Looking at it superficially, yeah, it looks like
you could modify the SMSqueakMap server to add support for
harvesting-related stuff, like uploading files, and possibly things like
emailing to a mailing list when a new package/submission is added.

And then writing a new browser/client UI for this is something I could
help with.

Post by g***@bluefish.se
- Perhaps you Doug could list what you think the tool would/should
do/need? On the Swiki typically. I can help also.

Yes, I will create a swiki page listing these things, which we can all
edit. (it's getting late, I'll do it tomorrow)

Post by g***@bluefish.se
- Then we look at what we got in the form of code and combine it into a
nice tool. I could see the SM codebase in conjunction with Monticello
forming a nice toolset. They complement each other nicely.
- And especially, we could use Monticello to develop this tool in the
first place!

True! Well, whatever is simplest to get started, anyway.

Post by g***@bluefish.se
- And we hook up with Luciano of course.

Yes, if Luciano wants to get started on it, that would be great. He can
join in the discussion here about how to proceed, or we could discuss on
the swiki page that I will set up soon. :-)

- Doug

[Doug Way]

Post by g***@bluefish.se
Just a few notes. I IRCed with Luciano yesterday and the day before and
I sketched out how the SM codebase can be used to produce a harvesting
tool independent of SM but using the same architecture (with uploads
added of course). He got very excited, sat down and looked through the
SM code, liked it and is itching badly to help out on this!
- Perhaps you Doug could list what you think the tool would/should
do/need? On the Swiki typically. I can help also.

Okay, I've put up a preliminary Swiki page with my thoughts on what the
tool(s) should be able to do.

http://swiki.squeakfoundation.org/squeakfoundation/86

Goran & Luciano & others, add your comments there as you see fit.

- Doug