On Wed, 06 Jul 2005 02:44:20 +0300, "Daniel Vainsencher" danielv@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