Incorporating new changes (was Re: 3.9alpha update stream)

[Doug Way]

On Tue, 5 Jul 2005 10:20:58 +0200, "Alexandre Bergel"
<bergel at iam.unibe.ch> said:
> It works fine. 
> 
> I have some changes related to the changeset notification. how should I
> proceed to submit it ?
> 
> I loaded my changeset, and the System is modified. Shall I save the
> package System? 
> 
> As far as I understood, people willing to submit fixes, have to do it
> using changeset, and harvester are the only ones who can update the 39a.

Ok, here is where things get interesting. :)

Basically, most of the old rules are now gone.  You won't have one group
of harvesters controlling everything (so that everyone else has to send
them changesets) anymore.

We need to get small groups of 2-6 maintainers for all of the 35
packages making up the base image.  Easier said than done, of course,
but we need to make a stab at it.

In this case, it sounds like all of your changes are in the System
package?  (When you make your changes, does only the System package have
a "*" by it in the MC Browser?)

If that is the case, since you are doing significant work in the System
package, I would suggest that you be one of the co-maintainers of the
master System package.  Various folks at Berne have made significant
changes to System in the last few years (KCP team etc), so it makes
sense for you or someone else there to be one of the co-maintainers.

With an important package like System, it's probably good to have at
least 3 maintainers, so that the group is self-sustaining if somebody
leaves, they can review each other's changes, etc.  One of these people
would be the "lead" maintainer.  More trivial packages such as
VersionNumber could probably just have one maintainer.  (This is really
a topic for a whole other email.)

Anyway, ideally we should have a master System package repository set up
somewhere.  Could be at source.sqf.org or squeaksource.com or somewhere
else.  As one of the co-maintainers, you would simply commit your
changes to the System package there.  Periodically, we (the v3.9 team)
would add the latest version of the System package to the 39a repository
as well, and then we'd have your changes.

(The cool thing about the master vs release repository separation is
that if the maintainers of the System package don't do their job,
someone else could create a competing System package in a different
repository, and the v3.9 team could simply switch to using that version
instead.)

So, the master repository vs release repository aspect is a little bit
complicated, but it seems like the only real way to move to a system of
truly distributed package development.  We do already have master
repositories for some packages, such as MC, MCConfigurations, SM-Base,
etc.  Now we need them for all the other packages.

In the short term, one thing we could do is simply make changes to the
System package and other core packages directly in the 39a repository,
since we don't have master repositories for these packages yet.  I
hesitate to suggest this, though, as this is still too centralized a
model.  But if we have trouble finding package maintainers, we may end
up having to do this for some packages in the short term.

It is still true that an outsider submitting a bug fix should submit a
changeset via Mantis or whatever current process.  The package
maintainers would be checking Mantis periodically for fixes from the
community, and incorporating them into their package.

> If what I understood is correct, I will contribute to the swiki page Doug
> started once I am back in bern next week.

So, you got that? ;-)

For now, I'm not sure if you should go ahead and make the change in the
39a System package, or if you should wait until we do a real
maintainership drive, and create all the remaining master packages. 
Thoughts from anyone else?

- Doug