Sure, I will work on it next week, once we're back.
Cheers, Alexandre
On Tue, Jul 05, 2005 at 04:37:27PM -0400, Doug Way wrote:
On Tue, 5 Jul 2005 10:20:58 +0200, "Alexandre Bergel" bergel@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