Hi fellow Squeakers!
Lots of time has gone by and we - the Coordinators - have been pretty silent for a while due to various personal reasons mainly. But we are now getting back into gear and stuff looks pretty good all in all in the land of the mouse.
This is a long report - but there is much to report. :)
NOTE: All reports available on http://swiki.krampe.se/castaways/8
Staring at the navel ------------------------ Before this report I asked the other coords (Doug, Cees, Marcus) a few questions about how we work and what we do. The net result can be summarized like this:
- We think the Team model is good and is working. This doesn't mean all *Teams* are working though. Coordination of the teams (our job) can be also improved, we should simply do more of it. :)
- We think our main job is just that - coordinating the Teams and making sure dropped issues gets picked up, teams are formed, leaders assigned, teams dispersed etc. And writing these reports.
- If we ever end up having to make decisions that don't naturally fit in any of our Teams, then yes, we will make them. But this will be ad hoc as needed.
- We have agreed to enlarge the group, and possibly also let one or two of us go. Yes, we need to start circulate a bit.
Stakeholder Suvery ---------------------- Just sent out. Deadline to answer is 23rd, results will be published a day or two after. I will put the survey questions up on the Coordinator Swiki together with the results.
The Foundation ------------------ I assume you all saw Stephane's announcement of the formation of the Squeak foundation. Exactly how the foundation relates to the Coordinators etc is still a bit unclear - Stef did the right thing and just "did it" - so now we are discussing how to evolve from here, and btw, that discussion can be held in public IMHO.
In short I/we are wondering if the two entities really need to be *two* :) or if we should merge them. Feel free to post thoughts on it.
The Coordinator's job is pretty clear, and I just described it earlier in this report (see above). The job of the foundation is pretty wide, but it doesn't (well, that is my perception of the goals listed at this time) explicitly list goals for the development of Squeak itself - at least not clearly.
So would it be best to have a single entity? Or is there a point in having the two groups separate? Personally I am leaning heavily towards declaring the two groups one, but I want to hear more thoughts. If we do merge them then I think the goals needs to be revised.
And yes, all this might sound a bit odd - after all both Marcus and I are in the Coordinator's group - so we are already "merged" in the sense of overlapping people. But the two entities are still different - which is good btw.
Anyway, the initiative is good and we will figure it out with your help. :)
Team Reports --------------- A few days back I asked for short status reports from all Teams, and here they are in one way or another.
Modules Team ---------------- I have not received any answer from Dan about a short progress report. It seems to me this team has stalled, but we will see if Dan pops up and gives us something later on. I will harass him a bit more. :)
Morphic Splitters ------------------- Cees is excused for not writing down a report (given his involvement in the Katrina disaster) but as we all have seen Juan Vuletich has delivered a first result from Morphic Splitters, nice! It has already been included in 3.9 alpha.
This is quoted from one of Juan's latest postings:
"This is the first MorphicSplitters change set. I prepared it for 3.9a-6690. It creates a few packages and does a massive categorization of classes and methods, to fill them. It does not modify any method or class definition. I believe this is a good moment to include it in the update stream.
It is at http://webs.sinectis.com.ar/jmvuletich/MorphicSplitters01.st (I didn't attach it to this message because there is a 100kb limit).
Next steps in the MorphicSplitters project will involve real refactoring, to allow unloading of the EToys and MorphicExtras packages. We're using MudPie and some removal scripts based on one by Dan for the analysis. I believe these will be useful for other refactoring efforts.
I'd like to thank to Cees, Edgar, Daniel, Dan and anyone else who helped in some way."
Packages Team ----------------- One of the major goals of the packages team was to enable the base image to be managed primarily as a set of packages rather than through the update stream. This is currently happening with Squeak 3.9 alpha, which has been divided into Monticello packages and is being maintained entirely through a dedicated SqueakSource installation. The process is described in more detail at http://minnow.cc.gatech.edu/squeak/5718.
Special thanks to Andreas for doing the initial Squeak packaging, Doug for getting the source.squeakfoundation.org server up and running, and Marcus for managing the new packaged 3.9a image.
Andreas announced on the packages list a restructuring that places the development tools into a fully unloadable package. An image with the tools already unloaded is available at http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip.
Integrating this work should be a high priority for the team in the future. Another recent and relevant development is the release by Michal Starke of Kabungu: http://map1.squeakfoundation.org/sm/package/63fe75bb-a060-4bba- bfe4-7930dd57a592
...the first dependency engine for SqueakMap; this may provide good basis for the SqueakMap/Universes conceptual integration that was discussed shortly after the packages team was formed.
Note by Göran: I have already promised Michal to integrate Kabungu ASAP in SM, we have exchanged a few emails in private and Kabungu is quite similar to my model - and still different - but the differences may very well be for the good. But above all - the code runs today. :)
ToolBuilder Team ------------------- This is "done for the time being". We might consider closing this team, Brian Brown has no more time to spare and this stuff is almost all in 3.9a. So good job Brian! :)
v3.9 Team ------------
From Doug:
"Technically I am the "team leader" for the 3.9a team, but for most practical purposes I have taken over lately as the leader of the packages team, and Marcus has taken over most of the 3.9a work.
With the packages team, considerable progress has been made... 3.9a is now partitioned into packages! (I guess this counts as 3.9a progress also.)
On the packages side, the SqueakSource repository containing the 3.9a packages has been set up and is up and running at http://source.squeakfoundation.org. This is a special SqueakSource install (based on code from Bert) which supports generating .mcd (diff) files, which results in much faster incremental updating of MC packages than loading entire .mcz files.
The items still to-do are to add the rest of the support for the Hybrid MC/Update Stream model, which is really just this: When someone requests to load updates, we first check the update stream for do-its, then we load the latest MC packages (in a predefined order). (This part should not be too hard... getting the new SS server running seemed to be the hard part.) This page has some details: http://minnow.cc.gatech.edu/squeak/5718
There are also some potential stability issues with SS which are being investigated.
On the 3.9a content side, Marcus has been doing lots of harvesting (as can be seen by browsing the SS server). Also, Toolbuilder changes have gone in (I think?), LookEnhancements, PreferenceBrowser, and there is serious discussion of Traits."
File Area Team ----------------- Nothing much happening, but Bruce is reliable and that is what counts! Bruce says: "Since the last report we've updated the unix/linux packages to use the fixed 3.8 image and have uploaded new MacVMs."
Janitor Team --------------- Ken beat me to it and reported separately, nothing much more to say except that David Shaffer signed up to help: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/0938 54.html
Box-admin Team ------------------ Well, we now have box2 up and running and we are gradually moving all services off of box1. Other than that there is not much to report I think, right Ken?
Website Team --------------- Website Team Report from Jason Rogers: - Content for the new site is coming along nicely, but we aren't quite there yet - We have added a new team member: David Brooks - We continue to have stability issues with the new site and are working on improving that - The current plan is to "release" the new site and take the old one offline as soon as we reach a stable juncture
(after this was written help has come forward with a new hopefully better working image and we hope to see the site coming up Real Soon Now(tm))
Pandora's box ---------------- Someone opened the box, and no, it wasn't me. I tried to shut it, but hey, this is a force of nature - who am I to think it would stay closed? :) I am talking about the recent licensing thread, as you might imagine.
Without getting into the details Craig told us on IRC that he is communicating with "the fruit company" in this regard together with... well, let's say he has some very prominent help. We (coordinators) will keep ourselves posted with Craig so that we are aware of the status of that ongoing communication and we think it seems wise to wait and see the result because Craig together with "prominent helpers" have a good personal incentive to get closure on this.
Craig thus is our "point man" on this from now on so if anyone has something interesting/important in this matter - contact Craig. And perhaps that will close the lid for now? No? Even if I sit on it? Sigh. :)
Developer initials evolved ------------------------------ Ever since SM2 was released the developer initials have been registered on SM. When I released SM2 I migrated all known initials from the Squeak Swiki page into SM.
The idea is that you create an SM account to make sure your dev initials are unique and known to the rest of us. This also maps your initials to a name and an email. Now, it is pretty important to us that this is a real name because the developer initials are used to track code. And if we don't know who has written some code then we have the problem of not knowing the license for that code - nor do we know whom to ask if we want to change the license of that code in the future etc.
The upcoming website has a "community howto" text in which we encourage new Squeak developers to register their developer initials so that we can keep track of ourselves and code authorship.
Recently Stephane brought up the problem of mentally mapping dev ids to real people - it isn't that easy since we now have more than 300 registered accounts on SM. MC only records the dev initials in an MC version, so that is all there is today.
My suggestion is that we do the following:
1. Add a field to SMAccount in which we can keep old developer initials. This way people can change their username on SM (=dev initials) and keep the old ones in that field, typically separated with a space. This means all published old code can still be mapped to a person and thus authorship is known.
2. Enhance our tools to perhaps map the id to SM and show the real name etc. I have used this in the "split changesets"-mechanism (not yet integrated in 3.9alpha) which is able to split a changeset based on PackageInfo boundaries, compose an email of the splits and the original changeset and send that to all maintainers of said packages. This means I map PackageInfo->SMPackage->all maintainers and co-maintainers->their emails. Now, this is a powerful thing to have and I have written about the importance of this mapping lots of times - please let us finally appreciate the importance of SM in this regard.
3. Also enhance the changeset tools and MC so that they not only include the dev initial but also the full name and email from SM. Sure, a bit redundant, but the email might change in the future, but whatever - then you can always look up the current one using the dev id.
Now, I predict only a few will start changing the dev initials to their full name like Stephane suggests - so without #2 and #3 above it will still be very hard to mentally map the dev id yourself.
If we can agree on this scheme I can take on myself to hack this.
And thus ends this report, hopefully with not too many glaring omissions or errors.
regards, Göran Krampe
Tasks identified in this report (and left from the previous one) ------------------------------------------------------------------------ --
Everyone: - Ponder the merge/separation of Coordinators/Foundation. Views? - Think about the Team model, what can we improve? Think, post. Subject tag: [TEAM] - Burning issues! Read, think, post. Subject tag: [BURN] - Follow Doug's lead on 3.9. Harvest etc.
Coordinators: - Find 1-2 more Coordinators - Compile and publish stakeholder survey results - Figure out how to merge/relate to Foundation. - Get better at harassing the Team leaders :) :) - Communicate with Craig to see where the license talks lead
Website team: - Get the new website out :)
Göran: - Move SM to box2 - Integrate Kabungu in SM - Possibly hack SM + some tools for developer initials proposal
Volunteers - not sure if these are fully done so leaving them in: - Worlds Of Squeak remake in 3.8 ?? - Get 3.8 properly published on the Squeak Swiki ??
On 13 sept. 05, at 10:39, goran@krampe.se wrote:
Hi fellow Squeakers!
Lots of time has gone by and we - the Coordinators - have been pretty silent for a while due to various personal reasons mainly. But we are now getting back into gear and stuff looks pretty good all in all in the land of the mouse.
This is a long report - but there is much to report. :)
NOTE: All reports available on http://swiki.krampe.se/castaways/8
Staring at the navel
Before this report I asked the other coords (Doug, Cees, Marcus) a few questions about how we work and what we do. The net result can be summarized like this:
- We think the Team model is good and is working. This doesn't mean
all *Teams* are working though. Coordination of the teams (our job) can be also improved, we should simply do more of it. :)
- We think our main job is just that - coordinating the Teams and
making sure dropped issues gets picked up, teams are formed, leaders assigned, teams dispersed etc. And writing these reports.
- If we ever end up having to make decisions that don't naturally
fit in any of our Teams, then yes, we will make them. But this will be ad hoc as needed.
- We have agreed to enlarge the group, and possibly also let one or
two of us go. Yes, we need to start circulate a bit.
Stakeholder Suvery
Just sent out. Deadline to answer is 23rd, results will be published a day or two after. I will put the survey questions up on the Coordinator Swiki together with the results.
The Foundation
I assume you all saw Stephane's announcement of the formation of the Squeak foundation. Exactly how the foundation relates to the Coordinators etc is still a bit unclear - Stef did the right thing and just "did it" - so now we are discussing how to evolve from here, and btw, that discussion can be held in public IMHO.
In short I/we are wondering if the two entities really need to be *two* :) or if we should merge them. Feel free to post thoughts on it.
The Coordinator's job is pretty clear, and I just described it earlier in this report (see above). The job of the foundation is pretty wide, but it doesn't (well, that is my perception of the goals listed at this time) explicitly list goals for the development of Squeak itself - at least not clearly.
So would it be best to have a single entity? Or is there a point in having the two groups separate? Personally I am leaning heavily towards declaring the two groups one, but I want to hear more thoughts. If we do merge them then I think the goals needs to be revised.
Yes I think that coordination of team should be integrated under the foundation.
And yes, all this might sound a bit odd - after all both Marcus and I are in the Coordinator's group - so we are already "merged" in the sense of overlapping people. But the two entities are still different - which is good btw.
Anyway, the initiative is good and we will figure it out with your help. :)
Team Reports
A few days back I asked for short status reports from all Teams, and here they are in one way or another.
Modules Team
I have not received any answer from Dan about a short progress report. It seems to me this team has stalled, but we will see if Dan pops up and gives us something later on. I will harass him a bit more. :)
Morphic Splitters
Cees is excused for not writing down a report (given his involvement in the Katrina disaster) but as we all have seen Juan Vuletich has delivered a first result from Morphic Splitters, nice! It has already been included in 3.9 alpha.
This is quoted from one of Juan's latest postings:
"This is the first MorphicSplitters change set. I prepared it for 3.9a-6690. It creates a few packages and does a massive categorization of classes and methods, to fill them. It does not modify any method or class definition. I believe this is a good moment to include it in the update stream.
It is at http://webs.sinectis.com.ar/jmvuletich/MorphicSplitters01.st (I didn't attach it to this message because there is a 100kb limit).
Next steps in the MorphicSplitters project will involve real refactoring, to allow unloading of the EToys and MorphicExtras packages. We're using MudPie and some removal scripts based on one by Dan for the analysis. I believe these will be useful for other refactoring efforts.
I'd like to thank to Cees, Edgar, Daniel, Dan and anyone else who helped in some way."
now in the repository of 3.9a ready for the next release.
Packages Team
One of the major goals of the packages team was to enable the base image to be managed primarily as a set of packages rather than through the update stream. This is currently happening with Squeak 3.9 alpha, which has been divided into Monticello packages and is being maintained entirely through a dedicated SqueakSource installation. The process is described in more detail at http://minnow.cc.gatech.edu/squeak/5718.
Special thanks to Andreas for doing the initial Squeak packaging, Doug for getting the source.squeakfoundation.org server up and running, and Marcus for managing the new packaged 3.9a image.
Andreas announced on the packages list a restructuring that places the development tools into a fully unloadable package. An image with the tools already unloaded is available at http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip.
Integrating this work should be a high priority for the team in the future. Another recent and relevant development is the release by Michal Starke of Kabungu: http://map1.squeakfoundation.org/sm/package/63fe75bb-a060-4bba- bfe4-7930dd57a592
...the first dependency engine for SqueakMap; this may provide good basis for the SqueakMap/Universes conceptual integration that was discussed shortly after the packages team was formed.
Note by Göran: I have already promised Michal to integrate Kabungu ASAP in SM, we have exchanged a few emails in private and Kabungu is quite similar to my model - and still different - but the differences may very well be for the good. But above all - the code runs today. :)
Excellent
ToolBuilder Team
This is "done for the time being". We might consider closing this team, Brian Brown has no more time to spare and this stuff is almost all in 3.9a. So good job Brian! :)
But now the migration of tools should start :)
v3.9 Team
From Doug:
"Technically I am the "team leader" for the 3.9a team, but for most practical purposes I have taken over lately as the leader of the packages team, and Marcus has taken over most of the 3.9a work.
With the packages team, considerable progress has been made... 3.9a is now partitioned into packages! (I guess this counts as 3.9a progress also.)
On the packages side, the SqueakSource repository containing the 3.9a packages has been set up and is up and running at http://source.squeakfoundation.org. This is a special SqueakSource install (based on code from Bert) which supports generating .mcd (diff) files, which results in much faster incremental updating of MC packages than loading entire .mcz files.
The items still to-do are to add the rest of the support for the Hybrid MC/Update Stream model, which is really just this: When someone requests to load updates, we first check the update stream for do-its, then we load the latest MC packages (in a predefined order). (This part should not be too hard... getting the new SS server running seemed to be the hard part.) This page has some details: http://minnow.cc.gatech.edu/squeak/5718
There are also some potential stability issues with SS which are being investigated.
On the 3.9a content side, Marcus
and Stef ;) (even if marcus did more)
has been doing lots of harvesting (as can be seen by browsing the SS server). Also, Toolbuilder changes have gone in (I think?), LookEnhancements, PreferenceBrowser, and there is serious discussion of Traits."
File Area Team
Nothing much happening, but Bruce is reliable and that is what counts! Bruce says: "Since the last report we've updated the unix/linux packages to use the fixed 3.8 image and have uploaded new MacVMs."
Janitor Team
Ken beat me to it and reported separately, nothing much more to say except that David Shaffer signed up to help: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005- August/0938 54.html
Box-admin Team
Well, we now have box2 up and running and we are gradually moving all services off of box1. Other than that there is not much to report I think, right Ken?
Website Team
Website Team Report from Jason Rogers:
- Content for the new site is coming along nicely, but we aren't quite
there yet
- We have added a new team member: David Brooks
- We continue to have stability issues with the new site and are
working on improving that
- The current plan is to "release" the new site and take the old one
offline as soon as we reach a stable juncture
(after this was written help has come forward with a new hopefully better working image and we hope to see the site coming up Real Soon Now(tm))
Pandora's box
Someone opened the box, and no, it wasn't me. I tried to shut it, but hey, this is a force of nature - who am I to think it would stay closed? :) I am talking about the recent licensing thread, as you might imagine.
Without getting into the details Craig told us on IRC that he is communicating with "the fruit company" in this regard together with... well, let's say he has some very prominent help. We (coordinators) will keep ourselves posted with Craig so that we are aware of the status of that ongoing communication and we think it seems wise to wait and see the result because Craig together with "prominent helpers" have a good personal incentive to get closure on this.
Craig thus is our "point man" on this from now on so if anyone has something interesting/important in this matter - contact Craig. And perhaps that will close the lid for now? No? Even if I sit on it? Sigh. :)
Developer initials evolved
Ever since SM2 was released the developer initials have been registered on SM. When I released SM2 I migrated all known initials from the Squeak Swiki page into SM.
The idea is that you create an SM account to make sure your dev initials are unique and known to the rest of us. This also maps your initials to a name and an email. Now, it is pretty important to us that this is a real name because the developer initials are used to track code. And if we don't know who has written some code then we have the problem of not knowing the license for that code - nor do we know whom to ask if we want to change the license of that code in the future etc.
The upcoming website has a "community howto" text in which we encourage new Squeak developers to register their developer initials so that we can keep track of ourselves and code authorship.
Recently Stephane brought up the problem of mentally mapping dev ids to real people - it isn't that easy since we now have more than 300 registered accounts on SM. MC only records the dev initials in an MC version, so that is all there is today.
My suggestion is that we do the following:
- Add a field to SMAccount in which we can keep old developer
initials. This way people can change their username on SM (=dev initials) and keep the old ones in that field, typically separated with a space. This means all published old code can still be mapped to a person and thus authorship is known.
- Enhance our tools to perhaps map the id to SM and show the real
name etc. I have used this in the "split changesets"-mechanism (not yet integrated in 3.9alpha) which is able to split a changeset based on PackageInfo boundaries, compose an email of the splits and the original changeset and send that to all maintainers of said packages. This means I map PackageInfo->SMPackage->all maintainers and co-maintainers-
their
emails. Now, this is a powerful thing to have and I have written about the importance of this mapping lots of times - please let us finally appreciate the importance of SM in this regard.
- Also enhance the changeset tools and MC so that they not only
include the dev initial but also the full name and email from SM. Sure, a bit redundant, but the email might change in the future, but whatever - then you can always look up the current one using the dev id.
not sure email is needed we can use SM for that.
Now, I predict only a few will start changing the dev initials to their full name like Stephane suggests - so without #2 and #3 above it will still be very hard to mentally map the dev id yourself.
If we can agree on this scheme I can take on myself to hack this.
And thus ends this report, hopefully with not too many glaring omissions or errors.
regards, Göran Krampe
Tasks identified in this report (and left from the previous one)
--
Everyone: - Ponder the merge/separation of Coordinators/Foundation. Views? - Think about the Team model, what can we improve? Think, post. Subject tag: [TEAM] - Burning issues! Read, think, post. Subject tag: [BURN] - Follow Doug's lead on 3.9. Harvest etc.
Coordinators: - Find 1-2 more Coordinators - Compile and publish stakeholder survey results - Figure out how to merge/relate to Foundation. - Get better at harassing the Team leaders :) :) - Communicate with Craig to see where the license talks lead
Website team: - Get the new website out :)
Göran: - Move SM to box2 - Integrate Kabungu in SM - Possibly hack SM + some tools for developer initials proposal
Volunteers - not sure if these are fully done so leaving them in: - Worlds Of Squeak remake in 3.8 ?? - Get 3.8 properly published on the Squeak Swiki ??
Good.... We are making progress.
Stef
Add a field to SMAccount in which we can keep old developer initials. This way people can change their username on SM (=dev initials) and keep the old ones in that field, typically separated with a space.
Very good, but if you're going there, please let's have something less primitive/hackish than space delimited strings, so that people can have a human-friendly 'Ada Byron' and not 'AdaByron', 'ByronAda', etc.
Michal
On 13-Sep-05, at 1:39 AM, goran@krampe.se wrote:
Goran, I would like to suggest an addition to your reports. This addition would be a summary page of the projects that the coordinators are coordinating and a brief paragraph of the current state / progress of the project on the main Squeak web page
1) It a summary: viewable in a single page, thus easily digestible (project status info could/should be linked to a different page) 2) Has a "Last Updated" date on the page AND beside every project name to show the world that Squeak in growing TODAY 3) It's visible to all visitors of the main Squeak web page 4) Improves visibility of the most high profile (most needed, most worked on, most interesting to the public) changes/projects in Squeak 5) Gives visibility of what the Coordinators are coordinating
As well, may this be a vote for having the Coordinator become part of the Squeak Foundation. My reasoning is visibility. For the outside world (and fellow Sqeakers!) to see a unified, coherent entity (project coordination being part of the Squeak Foundation) shows strength in our community. This image alone can help Squeak grow.
Jason
Hi!
j thej@shaw.ca wrote:
Goran, I would like to suggest an addition to your reports. This addition would be a summary page of the projects that the coordinators are coordinating and a brief paragraph of the current state / progress of the project on the main Squeak web page
- It a summary: viewable in a single page, thus easily digestible
(project status info could/should be linked to a different page) 2) Has a "Last Updated" date on the page AND beside every project name to show the world that Squeak in growing TODAY 3) It's visible to all visitors of the main Squeak web page 4) Improves visibility of the most high profile (most needed, most worked on, most interesting to the public) changes/projects in Squeak 5) Gives visibility of what the Coordinators are coordinating
As well, may this be a vote for having the Coordinator become part of the Squeak Foundation. My reasoning is visibility. For the outside world (and fellow Sqeakers!) to see a unified, coherent entity (project coordination being part of the Squeak Foundation) shows strength in our community. This image alone can help Squeak grow.
Jason
What can I say - you are absolutely right. :) I agree totally. In fact I think almost all the stuff we have today on the Coordinator readonly swiki should be on the new squeak.org site.
regards, Göran
squeak-dev@lists.squeakfoundation.org