Last updated at 5:37 pm UTC on 20 October 2005
This is the coordination page for the partitioning effort of the Packages Team. The goal is to have only one person working on partitioning one package at any one time, to avoid conflicts. So, if you want to help with the partitioning effort:
- first, sign up for the packages mailing list by emailing firstname.lastname@example.org (see the Packages team list)
- then, pick a package from the Package List that doesn't have anyone's name beside it
- edit the Package List page to put your name and the current date beside it
- when you're done working on that package for the time being, email a changeset of your work to the packages list, and take your name off the page again.
Once a few of these changesets start coming in, we'll set up a special update stream for them so that people can easily keep in sync - then there'll be an additional "update from the packaging stream" step before you start.
If you're interested in maintaining a package in the long term, rather than (or as well as) doing partitioning work on it now, feel free to also put a note with your name after the package to this effect.
Partitioning is a frustrating and difficult process: in the end, it requires making a decision about which package every method and class in the image should live in. Because it requires moving methods from one package to another, it is also difficult to take a "divide and conquer" approach without a lot of coordination: if the person working on package A wants to move a method to package B, ideally the person working on package B needs to know about and agree to this first.
To soften the impact of these problems somewhat, we propose to do the partitioning in two distinct stages. In the first stage, the goal is to decide, for each class and method that is currently in a package in the image, whether or not it should remain there. The idea is to identify and remove any foreign extension methods, without worrying about whose extension methods they might be, and without going looking for potential extension methods for your package that are currently in other places. We propose a simple way of marking these foreign extensions, by prepending "*orphaned-" to their method category name (or "Orphaned-" to the class category name for classes), so that they can always easily be listed by browsing the "Orphaned" package.
Once the first stage is well underway, the second stage will begin: a second pass through each package where the goal is to identify which of the extension methods and classes placed into Orphaned by other packages, might belong in yours.
Here's the Package List to start with (based on Squeak3.8g-6548). This list is not fixed in stone: if you start working on a package and realize that it should really be either broken down into smaller pieces, or joined with another package to make one larger one, just post to the list to that effect so we can coordinate that change.
(List moved to Package List - CdG)
Package Teams Best Practices