links to this page:    Swiki Page List Release Plan for 3.9 Squeak Report for 2005

Immediate first steps to get things going:

• General Approach
  • Open/Optimistic approach, keep the process simple.
  • First come, first serve. In other words, whoever adds their code first will probably have the least amount of merging to do. So, get yer stuff in before it's too late. ;) Your code should be reasonably complete/working when being added to the stream, although it doesn't have to be perfect. You are expected to merge with any changes which went in before yours. If you don't do this, you screwed up. (Built-in ConflictChecker will help detect needed merges.)
  • Give update stream access to a larger group than we've had in the past. Experts should be able to add updates themselves with minimal overhead.

• Unstable Stream
  • Everything should be broadcasted to the unstable stream in 3.9. (3.8 does not have to follow this rule, that's up to Michael.) I will probably disable direct broadcasting to the public/stable stream, or at least insert a warning when attempting to do that.
  • Every 1-3 weeks the items in unstable will be moved to stable, with a (mostly automatically generated) "[Updates]" announcement on squeak-dev. I will probably handle this at first for a short while, but any Committer should be able to do this if the time is ripe.
  • Unstable should never "fork" from stable, it merely stays ahead of it. Unstable is always a superset of stable. Similar to the old Squeak Central process.

• Who can have access
  • Anyone with "Master" level status on SqueakPeople
  • The Coordinators/Team Leaders/SqC Members (pretty much covered in the above group anyway)
  • Possibly a few other people who work hard submitting good fixes and reviewing stuff on Mantis, at the discretion of the update stream manager.
  • The general idea is to start with a fairly large group of 15-30 people, which will probably settle down to a somewhat smaller group of active people. But in order to be sustainable, it really should not be too small a group.
  • Perhaps we should call these people "Committers" rather than Harvesters, as it doesn't necessarily involve harvesting (although it can).
  • Committers do not necessarily have to be extremely active to remain committers, since we will have a larger group. But some minimum level of activity should be required, such as at least one update every six months.
  • Probably startup a mailing list for the Committers. (maybe read-only to the public)

• How to commit/broadcast an update
  • Select the changeset in the FileList, "broadcast as update", select Unstable Updates, enter id/pw. That's all there is to it.

• Guidelines for adding things to the stream
  • 1. Fixes/refactorings should just go in with no review. They can be fixes/refactorings that you harvested from someone else, or something you wrote yourself. If you're really unsure of the fix/refactoring, use guideline #2 instead.
  • 2. Modest enhancements and significant functionality changes should be preceded by a quick announcement (on squeak-dev or perhaps on a Committers list) first, as a heads-up warning to everyone. But if there is no comment within a few days, go ahead and broadcast the change.
  • 3. Major enhancements should be discussed on squeak-dev or the appropriate team list first and added to the release plan before they go in.

Additional steps to improve the process after we've started:

• Automated checks when broadcasting updates
  • ConflictChecker - try to add this to the broadcasting code ASAP, to help everyone detect when code needs to be merged
  • Checking for changeset preambles, class comments in new classes, etc
  • Maybe try to write a semi-automated merge tool also, stealing code from MC if available
  • These checks will be setup to automatically run when broadcasting an update, although there should be a workaround if they must be skipped
  • We don't need to wait for any of this functionality before getting going with 3.9, we can add them as we go along

• Separate id/pw's for each Committer
  • It's generally not good to have a single id/pw shared among 20+ people.
  • Would enable us to track who posted which update, which would be handy.
  • Cees says it would be preferable if broadcasting could be converted to an HTTP POST instead of an ftp transfer, which makes access level maintenance easier & more secure from an admin point of view.

• Long term
  • Long term, we may phase out the update stream in favor of a distributed model of individually maintained packages, but we first need to get the update stream running smoothly again. The partitioning effort (which relies on the update stream) and a package dependencies scheme will both need to be completed before we can consider dumping the update stream.

Action Plan

• Doug will email the list of Committers (defined above) to get the process going.