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

Alexandre Bergel bergel at
Wed Jul 6 15:45:28 UTC 2005

Sure, I will work on it next week, once we're back.


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 at> 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 or 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

Alexandre Bergel  

More information about the Packages mailing list