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

Doug Way dway at mailcan.com
Wed Jul 6 19:30:15 UTC 2005


On Wed, 06 Jul 2005 02:44:20 +0300, "Daniel Vainsencher"
<danielv at techunix.technion.ac.il> said:
> 
> Doug Way wrote:
> > 
> > The Submissions repository seems like it might be an extra step which is
> > not entirely necessary... we already have these changes stored in the
> > old update stream, or on Mantis, etc.
> [snip]
> > One upside to the Submissions repository is that the UI is available in
> > Squeak via MC, whereas Mantis changesets are not.
> I don't think of it as "show up in Squeak via MC". I think of it as - 
> can be trivially accessed by Squeak code, in a well modeled manner, 
> using MC. On top of that we can build various things, better UI being 
> just one. For example, a test server that runs a test suite on every 
> submitted version, catching regressions before they get into the update 
> stream.

True.  Also, I was thinking mainly in terms of the UI being better
integrated for the person reviewing/incorporating submissions, but this
integrated UI is also better for the submitter.  So maybe it's not such
a bad idea after all. ;)

> > I guess one
> > possibility is still using Mantis to track bugs & fixes, but posting the
> > code in the Submissions repository instead of to Mantis.  
> Yup. Given a common repository for each package, the mantis entry needs 
> only to name the specific version. And as Bert suggested, we could 
> eventually move bug tracking functionality into Squeak.

Ok.  For starters, we could give it a try for some submissions, and also
discuss with the Janitors team.

I'm guessing most/all submissions would be .mcd files.  (I suppose a
complete overhaul/replacement of a package could be an .mcz.)

There might be a few cases which are hard to handle, such as a
submission which requires a DoIt, which requires a changeset (shouldn't
be too common).  Those could be left in Mantis for now.  Or, submissions
which cut across multiple packages couldn't be conveniently bundled into
a single .mcd file, I think.

> > One downside
> > is that the repository could easily get cluttered with hundreds of
> > unordered submissions.
> I think that's a tools issue. That repositories accumulate dead end 
> versions is natural. If this repository does it faster, and pushes 
> SqueakSource and MC to improve how they deal with this, or specialized 
> UIs to appear, that's a good thing.

True.

>  > It seems more relevant as a possibly new fix/enh submissions process,
>  > which is currently done in Mantis, and is partly/mostly handled by the
>  > Janitors group.  You might want to bring up the idea on that list,
>  > although I guess it's worth pondering here for a bit.
> Sure. Seems to me that we want the process to be as seamless as 
> possible, while allowing maintainers control.
> 
> So I propose for each package, things get merged into 39a from its 
> master repository, which can be Submissions if there's nothing else, or 
> the maintainers repository otherwise.

Ok.  (I'm not sure if we have to be rigid about *all* other changes
coming from the Submissions repo, but we can try it.  I guess there are
some advantages to doing that.)

> We make sure that in the image, 
> each package includes its master repository, so things get submitted to 
> the right place.

Absolutely, I forgot to mention this earlier.  For example, the SM-base
package in the 3.9a image should list both the 39a repository and also
Goran's master repository in the Monticello browser.  (And the
Submissions repo for the other ones.)  I will add this to the 3.9a-6676
image, or possibly add it as a DoIt update.

> If the maintainer sees something interesting for his 
> package that got to Submissions by mistake, he merges it (or not), and 
> again, nobody else needs to do anything special - just merge from the 
> maintainer every so often.
> 
> And from everyones point of view (Joe R. Fixit, Maintainer, update 
> stream writer (are those still called harvesters?)), everything is quite 
> uniform. I get my code for a package from one predefined repository, and 
> merge and save what I think is right into another.

Sounds cool. :)

- Doug



More information about the Packages mailing list