Ah, you do see my mails, just a matter of timing.
Doug Way wrote:
On Wed, 06 Jul 2005 00:16:43 +0300, "Daniel Vainsencher" danielv@techunix.technion.ac.il said:
There's a Submissions repository world-writable, on source.sqf.org.
We can post things there for people to look at, and occasionally merge it into 3.9a. So one way to begin would be to start creating versions on Submissions that include the patches that have accumulated for 3.9a before, merging them into the 39a repository versions as people think is safe.
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.
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.
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.
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. We make sure that in the image, each package includes its master repository, so things get submitted to the right place. 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.
Daniel Vainsencher