First of all, I like everything that's going on. Some good ideas are getting implemented.
So was any decision made on how stuff gets submitted (FIX/ENH), then included?
One idea that I didn't see mentioned (but I might have just missed it) is to add a ForInclusion project to sources.squeakfoundation.org, with write access for everyone (or Apprentice and up, or whatever). Announce that that is the place for code to be submitted, when (the author thinks) it is ready for inclusion.
Then harvesters would simply merge stuff from that repository into the release repository.
Then whatever tools get coded for improving awareness of new code in an MC repository automatically apply to the harvesting process.
Daniel
Am 28.06.2005 um 18:55 schrieb Daniel Vainsencher:
First of all, I like everything that's going on. Some good ideas are getting implemented.
So was any decision made on how stuff gets submitted (FIX/ENH), then included?
One idea that I didn't see mentioned (but I might have just missed it) is to add a ForInclusion project to sources.squeakfoundation.org, with write access for everyone (or Apprentice and up, or whatever). Announce that that is the place for code to be submitted, when (the author thinks) it is ready for inclusion.
Not a bad idea. Maybe call it "3.9 Patches" or "Submissions"? However, it could get cluttered very easily.
Then harvesters would simply merge stuff from that repository into the release repository.
Then whatever tools get coded for improving awareness of new code in an MC repository automatically apply to the harvesting process.
That's a good point. The SqueakSource server could be extended by adding search facilities, bug reporting, etc ... and then have an in- Squeak MC-based client to manage them. MCBFAV anyone?
- Bert -
Bert Freudenberg wrote:
Am 28.06.2005 um 18:55 schrieb Daniel Vainsencher:
[inclusion queue as a source.sqf.org project]
Not a bad idea. Maybe call it "3.9 Patches" or "Submissions"? However, it could get cluttered very easily.
I'm not sure whether its good or bad to have a single project across versions. Some differences are: -We will meet some scalability issues about as fast as possible. (will force our tools to get faster) -Things that didn't get in last time are still there (better than moving things manually, but we will need some way of ignoring the irrelevant).
Then whatever tools get coded for improving awareness of new code in an MC repository automatically apply to the harvesting process.
That's a good point. The SqueakSource server could be extended by adding search facilities, bug reporting, etc ... and then have an in- Squeak MC-based client to manage them. MCBFAV anyone?
Seems like the only thing the BFAV used to have over what we'd get immediately is the fact that the BFAV would hold bugs/code/reviews in the same place, same UI, in Squeak.
Since we've given up on the integration anyway with the move to Mantis, I think we lose nothing by implementing this with the tool support that currently exists, and then let it get better with time. But we better have a good plan for integration with/migration from Mantis, or some good people will kill us ;-)
A side benefit is that it is a way to help the remaining few dev-Squeakers who haven't already, meet MC/SqS.
Daniel
On 6/28/05, Daniel Vainsencher danielv@techunix.technion.ac.il wrote:
Not a bad idea. Maybe call it "3.9 Patches" or "Submissions"? However, it could get cluttered very easily.
I'm not sure whether its good or bad to have a single project across versions. Some differences are: -We will meet some scalability issues about as fast as possible. (will force our tools to get faster) -Things that didn't get in last time are still there (better than moving things manually, but we will need some way of ignoring the irrelevant).
Yeah, that makes sense. For now I've added a single Submissions project with global write access, http://source.squeakfoundation.org/inbox .
Avi
packages@lists.squeakfoundation.org
-
Avi Bryant -
Bert Freudenberg -
Daniel Vainsencher