|
|
>
> Bob is not a taskmaster who controls the image, demeaning our
> jobs to just submitting changesets for his approval. We, the
> community, build the image, and bob relieves us of the drudgery
> of making sure the packages load order is reproducable, and from
> waiting 5 hours for the unit tests to finish.
>
Not at all. You the community, pick the release designer, the team
leader. The team leader sets the goals, "right we are going to load all
the collections fixes in this release, and we are going to improve the
Network package." We have a month. The team leader writes a task for bob...
PackagesSqueak315 latest: 'Network'.
Installer mantis select: [ :ea |( ea category = 'Collections') & (ea
status = "resolved") & (fixedIn = '3.15')
Bob runs that task every day for a month, and you get to see the test
results and the output image. You also get the dev image the full image
and the minimal image, and the seaside image and the magmaserver if you
want it.
So you can all hack on network for a month, and Bob generates and tests
the result.
However... this is silly... you dont really want the release team to be
hacking away on Network while you are still making a release.
So two months earlier... you announce, we want to improve Network, who
wants to help.... the Network improvement team leader writes a task for
Bob which does the following.
Installer sf project: 'NetworkImprovements'; install: 'Network'.
So now the Network improving team get to hack away on their "trunk"
project for a couple of months, meanwhile bob is doing the testing for
them, and publically showing everyone how brilliant the new refactored
network package is.
So now fast forward 2 months to Release 3.15.... the task that the
teamleader defines is exactly the same, except, the work has already
been done, with interfaces specified and documented (in your dreams) and
tested for two months before hand.
So now he announces the goals as "we are going to load all the
collections fixes in this release, and we are going to integrate the
improved Network package, that is to migrate the kernel image to use the
new features of the Network packkge wherever possible.
But one enterprising member of the NetworkImproving team has forseen
this and so had spent a day working on porting the kernel over to use
the new Networking package. He knew that if he could publish this
changes in a way that the release team could use they would at least try
them out. His options are... CS/DS or, if he has a copy of 3.14 release
handy, he could do all the hacking and publish a complete new set of MC
packages, that include his change. The least useful option of the three
is the MC one, because it doesnt help any other fork to adopt the new
network package.
am I making any sense? (he says tempting fate)
Keith
>
|
Locked
