Where we are going with partitioning and harvesting etc.

goran at krampe.se goran at krampe.se
Thu Jun 23 13:08:33 UTC 2005

Hi folks!

"Doug Way" <dway at mailcan.com> wrote:
> Also, keep in mind that this is just putting package sets on SM from the
> 3.9 "release repository".  Each package should still have its own master
> repository, where core package development happens.  The package owner
> might also be putting package versions from there on SM as well.

Mmm. That essentially means I should add the branch function to SM. But

> (Hopefully there will not be issues with versioning numbering in MC with
> the two types of repositories.  I haven't really used MC working across
> multiple repositories to know how it's handled.  If it matters, I guess
> the based-on-iSqueak 3.9alpha image would list two repositories for
> every package in the MC Browser, the master repository and the release
> repository.)

I think MC handles it fine. What I need to do with SM though is add the
capability of branching I think. Otherwise things can get a bit
confusing when upstream releases are mixed with tweaked versions from
the "release repository".

> > A situation where we have two different kinds of packages seems quite
> > bad to me.
> > 
> > Use case: I want to see what versions of packages I have in my image, I
> > go to the SqueakMap Package Loader and select "installed". Now, if there
> > are *other* packages that don't show up then seems quite silly.
> Good point.  We would not be adding brand-new named packages to the
> release repository (3.9alpha update stream) without also adding them to
> SM.  (By this I mean a entirely new package, not a package version.)


> So, the only issue here would be that the SM Package Loader could
> possibly show an incorrect older version of a package that was updated
> via MC.  But if you have the SM package point to the PI, perhaps the SM
> Loader could try to be "smart" about what is really in the image? 
> Although, if the particular package version was a development version
> only in the MC release repository and not in SM, the SM Loader couldn't
> show an SM version, of course, perhaps it would just show the MC
> version.  (The SM version numbers may end up mirroring the MC version
> numbers anyway.)

Yes, I will fix this ASAP. SMLoader should then show the MC version and
some visual que that the installed version is NOT an SM release. Hmmmm,
let me think for a second... yes. Something like that.

> > I can come up with tons of use cases where this division is A-packages
> > and B-packages is bad.
> > 
> > And note that all I want is:
> > 
> > 	- That each PI package in the image has a corresponding SM package.
> > 	- That we "tie" it using the PI name field (trivial).
> > 	- That we do make SM releases at least at some points in time.
> Agreed 100%.  If we tie them together using the PI name field in the SM
> packages, that should work.  (I don't think we want the PI itself to
> point to the SM package.)

Not sure exactly what that means (not having the "PI point to the SM

> So we agree on this.
> As a side note, I'm not sure if this means that we may not need Ned's PI
> additions (for filing out PI's), if we're always using MC... I'm trying
> to remember exactly what the additions were.  Although if they are
> generally useful and harmless, we could just add them.

You mean PackageInfo-Extras? That package includes several cool new menu
actions for the changesorters of which I am proud of a few. :) They are
very useful in a world of packages.

Hmmm, just playing with it and it seems I need to mail some FIXes to Ned
(the mail to maintainers fails currently and I know why).

But anyway, really cool stuff in there! (After looking some more it
seems Ned missed a few things when he integrated my stuff, I think I
will have to sit down and do something about this.)

The coolest is that you can do cross package ENHs/FIXes in a single .cs
and then just do "mail to maintainers including splits" in the
changesorter and it will:

	- Split the changeset by copying parts of it into separate changesets,
one for each PI.
	- Locate SM packages for each PI and all maintainers (including
	- Compose an email with both the original cs and all splits (one for
each PI) and with the To: field filled with all
maintainers/co-maintainers of all affected SM packages.

This way the maintainers of each affected package can view the full .cs
to understand it and also see exactly what changes goes into their own
package (and the others).

Now, *that* is cool, but after I posted this ENH a while back noone
seems to have looked at it. ;)

> > Doing intermediate MC releases during the whole development phase is
> > perfectly fine. And I would also like to add a "Repository" field to
> > SMPackage that points to the repository where other non-released
> > versions can be found.
> Sure.  I guess this would point to the "master repository" for the
> package, not the release repository.

Well... ehum. Right. I guess we need TWO such fields then. One for
"upstream" (master) and one optional one for the "release" repo. Ok.

> > ...
> > > Actually, maybe there is a way to work SqueakMap into this process, to
> > > unify things a bit more.  Then perhaps the latest 3.9alpha
> > > "configuration" could be an SM universe instead, without requiring a
> > > special MC repository.  As long as this was done in a way which did not
> > > affect the MC tools or make the development/integration process any more
> > > difficult, that might be good.  That might be something to work on after
> > > we get this going.
> > 
> > Yes, something like that. But as you say, nothing we need to decide now
> > UNLESS the plan aims to use MC "configurations" or whatever - because
> > then we are sidestepping SM in this area.
> Er, ah, um.  Well, the update stream example Andreas gave did use
> MCConfiguration, so perhaps there is some duplication of effort here. 
> Although that is only needed when a "config map" changeset needs to be
> added to the update stream to bring us up to a certain set of packages,
> in order to execute a DoIt changeset (to massage instances in the image
> for example), or if something must be loaded in a certain order.
> But still, these configurations would only be within the
> alpha-development MC release repository, I believe.  I'm not sure they
> could be extended to the world of packages out there, and in that sense
> I'm not sure they could compete with SM configurations.
> Perhaps there is a way we eventually could replace the MCConfiguration
> command in the example update with an equivalent SqueakMap command, if
> all development package versions were on SqueakMap.  But I'm not sure if
> it's worth the effort.
> Stephane emailed me earlier saying that he was in favor of this MC
> partitioning plan, and that he thought of MC as more appropriate for
> package development, and SM for package deployment, which seems roughly
> right to me.  And I think we're really talking about development here. 
> But yeah, the concept of configurations/dependencies can apply to both,
> so there is some potential overlap.  (I don't mind mentioning Stephane's
> private email on the list here as he is known to do the same thing. ;-)
> )

Well, we will see where it goes.

regards, Göran

More information about the Packages mailing list