Tim Rowledge tim@sumeru.stanford.edu wrote:
"Andreas Raab" andreas.raab@gmx.de appears to have written:
The point here is not about whether an "internal" update stream _can_ be useful. The point is that in order to be useful it has to be _put_ to use, e.g., someone has to actually run the stuff that's in it. If noone does, then it's only getting into the way of both, testing and the release process in general (e.g., "is this update included?").
Exactly so. My problem is that I don't see anything in the internal stream and without an uptodate sqfixes page (or suitable substitute) it's hard to keep track of what to look into. I haven't been keeping every email that could possibly relate to changes; perhaps I should.
I think we just need to get some organisation into place. Now that assorted holiday type distractions are over maybe we can do so?
Yes, agree with Andreas on his points. I am not sure what Tim means by "...I don't see anything in the internal stream..." because I have seen stuff in there before it went out, but whatever.
The REAL solution is of course to follow up on the proposed tool that Doug and I and Luciano have been discussing - a sort of Harvesting tool using some similar mechanisms as SM does but in a package centric way.
The idea is that harvesters have the ability to review/comment and move fixes forward in a kindof "assembly line" fashion into different stages and finally out into an update stream. This "assembly line" will be viewable by all (and kept up to date similarly to SM) so there will be no doubt where a FIX has gone and what status it has.
And further we have been thinking of:
1. Adding Monticello to the mix like a "workbench" so that a FIX can be "lifted" temporarily off the assembly line onto the workbench (a Monticello shared repo) so that multiple developers can work on it "at the same time" banging it into shape and then when it looks good lift it back onto the assembly line.
2. When FIXes have gotten good reviews etc and passed whatever criteria/stages we want to have it moves into the final "release queue" which batchwise is published onto the update stream(s). Note the "s" here which signifies that this tool should be "package aware". Perhaps by having multiple assembly lines, a line for every package that wants it, and/or possibly multiple release queues (for different packages)
Anyway, that is the gist of it. The idea is to reuse the architecture of SM for much of it (but this is a completely separate tool of course), add a Morphic UI of course and then off we go.
IMHO anyone can start working on this - I am pressed for time but can surely help out regarding the SM base. Doug is good on the UI side and also has the knowledge about the "Harvesting needs". Luciano was very interested to help out and has looked into the SM code.
Furthermore Doug has written this on the subject - he is the man in charge (sorry for blabbering):
http://swiki.squeakfoundation.org/squeakfoundation/86
regards, Göran