|
Re: Where Squeak is Headed [was: Module discussion]: msg#00365lang.smalltalk.squeak.general
I volunteer to be part of the updates stream group. A few comments about the future role of the update stream - I think SqueakMap is right now a good way to distribute what we'd call goodies, and also many of the kind of larger tools/systems that used to be integrated in past directly into the image (speech synthesis, for example, as Connectors are now distributed in SM). People, as they post their work to SM are constrained, however, by various in the image. Examples include: - applications posted on SqueakMap could appear in the open menu, if code for a dynamic open menu was in the image. - The FileList refactoring that's in 3.3a would allow the simple addition of packages that add entries to the FileList. - Many applications that use sockets could handle errors more gracefully if sockets threw exceptions instead of deciding to wait, or asking the user directly. - Many packages could be more usable and useful if PluggableMorphLists were much faster, and allowed colored or bold items. I think the update stream should now be used mainly to fix these sort of problems, rather than introducing new functionality, which would be better released through SM. This means a change in the criteria for inclusion of things in the image - the focus would be "does this make Squeak freer, removing constraints and complexity?". It also means changes to our contribution process - the group maintaining the update stream will definitely not be able to know and judge the effect of changes on all packages. Feedback from the people that depend on/are affected by the change will become even more important. It may be a good idea to change the process formally - for example, deciding that changes will be considered for the update stream if they are endorsed/used by two maintainers of different packages. This will also encourage people to get and give more feedback A second role for the update stream might be to incrementally remove existing applications from the image, once they find a maintainer and appear as complete packages on SM. Daniel Vainsencher > Michael shared with me one other topic raised at the OOPSLA BOF, but not > included in the public report. Here's the wording I saw: > > "The suggestion is to hand management of the update stream over to a > group > of experienced Squeakers. This group will manage the review and > publishing > process and have SqC as advisors in the background. > Candidates right now are Göran, Doug, Ned and Tim (you did volunteer, > didn't you? ;-) ). Volunteers, comments, vetos are welcome." > > - Dan
|
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: Croquet on Linux, Randal L. Schwartz |
|---|---|
| Next by Date: | (no subject), Stephane Ducasse |
| Previous by Thread: | Re: Where Squeak is Headed [was: Module discussion], Tim Rowledge |
| Next by Thread: | [BUG?][FIX?] - driveName existence on windows, Magistrello Alejandro (SFA) |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |