As Andreas said, having any sort of separate pre- stream that is not heavily used is useless. A pre- stream's purpose is to generate quick, expert feedback for the stream without breaking things for a lot of people. This worked well when a group of expert fulltime Squeakers we're always using it. I have used a little early on, but then became busy, and did almost no Squeaking at all. Anyway, the way we're working now, it's broken, and merely delays our getting serious feedback from the list.
I think we should definitely convert, for the 3.5 cycle, to one update stream. We already have mechanisms to protect the wary - stop updating when you get to a "Continue updating for 3.5a" question. We could improve one these as mentioned, either using a special marker, or a whole new SM-like update mechanism, but we certainly don't have to wait for either of those.
I think SM based update streams would be great for the packages themselves, and possibly maintainance of the Image release could benefit from this mechanism, but I propose we don't tangle these until such a mechanism is pretty well proven. IOW, I propose we * finish up 3.4 as we have so far, * for 3.5 simply convert to a single update stream, so people can decide their own exposure, * and consider alternatives only for the version after 3.5.
Another technological fix we should consider is some awareness features notifying people when the updatestream changes - mechanizing the [Updates] mails so that people know when something new is in. Real Alpha pilots might also set their image to pull updates every hour...
Daniel
goran.hultgren@bluefish.se wrote:
cg@cdegroot.com (Cees de Groot) wrote:
Doug Way dway@riskmetrics.com said:
(By the way, Scott just posted the various "fixes before 3.4gamma" updates to the internal update stream today.)
I don't know what this internal update stream thingy is or who's output port you have to kiss in order to get access to it, but I think (exactly for these reasons) that it should go.
:-) I agree Cees but a simple explanation might be in order here - it is a remnant that we decided to keep until 3.4 is out the door just because we (or at least I) didn't want to start banging on something and thus disrupting the "quick" release of 3.4. Since Scott is doing most of the legwork currently it was easy to let him continue his work as he is used to.
But we all agree that there should be no "secret" privileged place for updates of course.
A much better alternative would be to have a marker file on the regular update stream indicate the latest 'safe' update (for some value of safe). Cool bl33ding edge hackers could ignore the marker, while regular users (using 'Update from server') would have their updates stop at the number indicated in the marker file.
Then everyone could decide for themselves how bleeding edge they'd like to be, and how much they want to contribute to pre-alpha testing.
The absolutely most vital thing if Squeak's to be a success under the new model of governance is to make it as transparent as possible. No hidden areas for some 'privileged' people, the only privileges we should hand out is decision privileges, not information privileges.
Again I wholeheartedly agree and this is one of the things I really tried to push in the mission statement. That is also one of the reasons we keep all discussions on this list and not off list. Consider this a remnant that will go away very soon.
I think a focused effort to bring about the new Harvesting tool would be the best way to proceed. Hacking the update mechanism just seems like a "hack" that will not give us anything really. We are just about (any day) to open 3.5alpha and IMHO alpha means on the bl33ding goddamn hold-on-it's-gonna-blow edge and when we have that stream open I think we can simply ditch the "secret" internal stream and then just get the new tool out the door before we try to turn 3.5 into beta (at which point such a tool will be much more needed).
Please guys, lets use the new alpha stream as ALPHA is meant to - push stuff into it and let the ALPHA-testers take the hit. We need to let FIXes go into it with much less scrutiny in order to keep up. IMHO, the only scrutiny we really need to do is to verify that it is indeed FIXes and not additions to the bloating image.
regards, Göran
Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Daniel Vainsencher danielv@netvision.net.il wrote: [SNIP]
I think we should definitely convert, for the 3.5 cycle, to one update stream. We already have mechanisms to protect the wary - stop updating when you get to a "Continue updating for 3.5a" question. We could improve one these as mentioned, either using a special marker, or a whole new SM-like update mechanism, but we certainly don't have to wait for either of those.
Agree - we shouldn't wait - a new tool takes time to develop.
I think SM based update streams would be great for the packages themselves, and possibly maintainance of the Image release could benefit from this mechanism, but I propose we don't tangle these until such a mechanism is pretty well proven. IOW, I propose we
- finish up 3.4 as we have so far,
- for 3.5 simply convert to a single update stream, so people can decide
their own exposure,
- and consider alternatives only for the version after 3.5.
Sounds like a plan to me. And then perhaps we can finally get ALPHA to really mean "stuff falling on your head" as it is intended to. Seriously. The Squeak community has often IMHO been far to careful when it comes to letting bugfixes into the stream (enhancements/additions is another story) - as long as we are in alpha I think we should let stuff in without much resistance (one experienced Squeaker approving it based on looking at it (no real testing necessary) should be enough) and then perhaps run a quick "batch review" of all the changesets in the alpha again when we intend to go into beta.
Anyway - in short, lets get rid of the internal stream for 3.5 and tell the community in BLOCK LETTERS that alpha now really means ALPHA.
I also think that the harvesting for 3.5alpha could be sped up significantly if lower the bar for bugfixes as I explained above - a single harvester (=experienced Squeaker) can approve a FIX by simply looking it over. This is just to prevent really "stupid" fixes or obviously inexperienced code sneaking in.
And then if this will let in a few fixes that we need to improve or back out then so be it - no harm done. At least we will have a reasonable chance of keeping up with the onslaught. :-)
regards, Göran
PS. Doing Dolphin right now for a customer - really interesting stuff too, advanced optimization - roughly the CSP (cutting stock) problem. Great fun!
goran.hultgren@bluefish.se appears to have written:
Daniel Vainsencher danielv@netvision.net.il wrote: [SNIP]
I think we should definitely convert, for the 3.5 cycle, to one update stream. We already have mechanisms to protect the wary - stop updating when you get to a "Continue updating for 3.5a" question.
[snip lots] The problem I have with this approach is the high probability of needing to retract changes. How? a) take it out of the update stream and tell people to restart from the last release? Oh, and what about intermediate changes that relied on some parts of the retracted one? b) add another update that undoes it; with the added need to compensate for any intermediate changes that have touched the same area?
I posutlate that we need several holding areas: one (like the current sqfixes page but up to date) for offered changes, another for changes considered of interest by at least one guide and another for changes agreed on by at least two guides. This last would essentially be the internal update stream used for a last opportunity to check things. It _could_ be seen as an alpha stream and made accessible to any brave fools willing to put with whatever is the chosen solution to the above problem.
tim
On Monday, January 13, 2003, at 01:23 PM, Tim Rowledge wrote:
goran.hultgren@bluefish.se appears to have written:
Daniel Vainsencher danielv@netvision.net.il wrote: [SNIP]
I think we should definitely convert, for the 3.5 cycle, to one update stream. We already have mechanisms to protect the wary - stop updating when you get to a "Continue updating for 3.5a" question.
[snip lots] The problem I have with this approach is the high probability of needing to retract changes. How? a) take it out of the update stream and tell people to restart from the last release? Oh, and what about intermediate changes that relied on some parts of the retracted one? b) add another update that undoes it; with the added need to compensate for any intermediate changes that have touched the same area?
I think it would probably have to be option b. That's what SqC has done with changes that made it out to the public stream which then had to be reverted.
Getting rid of the internal update stream sounds okay to me, actually. If the number of "problem" updates (in need of reverting) doubles or triples relative to when SqC handled things, I don't think that would be be a big problem. We would have retractions more frequently. Intermediate changes touching the same area would be reasonably rare.
I posutlate that we need several holding areas: one (like the current sqfixes page but up to date) for offered changes, another for changes considered of interest by at least one guide and another for changes agreed on by at least two guides. This last would essentially be the internal update stream used for a last opportunity to check things. It _could_ be seen as an alpha stream and made accessible to any brave fools willing to put with whatever is the chosen solution to the above problem.
Something equivalent to this might be good for the harvesting tool being written. But do we want to do this in the next month or so before the tool is finished, with the sqfixes pages?
For bug fixes, I tend to agree with Goran that approval by one harvester/guide (who is NOT the author of the fix) is probably sufficient. Perhaps for enhancements, approval by two guides makes more sense. With the harvesting tool, we could do some cool stuff like having approval of the quality of the source code be separate from the approval of the appropriateness of the fix/enhancement.
But in the meantime, we need to figure out what to do in the next few weeks, before any harvesting tool is ready. Should we go ahead and make some sqfixes swiki tables just to get some important fixes/enhancements in over the next few weeks?
- Doug
squeakfoundation@lists.squeakfoundation.org