How do you review code in squeak? Because we could have another stream and push between one and the other.
I mean practically? But this is because that the package arrives in MCBrowser that you read it? How do you deal with changes requiring a lot of changes in multiple packages? How do you know that they all work together? Now I often have to fix some more changes when I integrate fixes because it happens that people forget a detail there and there. Stef > Hi, >> >> We started to improve the states defined in the tracker... this now has: >> >> >> FixToInclude = QA has verified that the fix worked, needs to be >> integrated >> FixReviewNeeded = Code is there, but a review is needed >> NoSourcesAvailable = fix proposed, but machine readable code missing >> Workneeded = Next action is defined but not yet completed >> NextActionNeeded = What is the next action? >> Accepted = Problem reproduced / Need acknowledged >> New = Nobody looked at this yet >> OnHold = We will come back later to this issue, no action >> possible now >> >> >> The issue tracker by default sorts the items to show the ones on top that >> have progressed >> the most: >> >> http://code.google.com/p/pharo/issues/list >> >> >> The idea is that the "FixToInclude" status should be integrated very quickly >> (within a day), >> later maybe even automatically. >> >> Marcus >> > > I think this is a good pragmatic list. > > One thing I wonder is whether we can mark our own fix as "FixToInclude" > In theory, we should not because we are bypassing a peer review. > We should not lower quality insurance. > But practically it depends on two things: > - the level of work supported by integrators > - whether you have enough peer reviewers > and how easy or involving is such a review (the reviewer throughput) > > I suppose Marcus would like to be replaced by an automaton and reduce > integrator support. > It shall then be mandatory to tag our own fixes as "FixReviewNeeded". > But if ever you don't have enough reviewer throughput, then the > "FixReviewNeeded" will start accumulating in the tracker. > > If we fail to increase the throughput (with an army of reviewers or > some facilitating tools) then Marcus (and Stef) burden won't lighten. > > I repeat once again, but I prefer the squeak-trunk smooth process were > the changes are published in a mailing list. > They CAN BE reviewed more easily, and I'm sure they ARE reviewed more > efficiently than in Pharo process (I mean by many more eyes). > As a committer, I can then publish directly in trunk without the inbox stage. > It's very like a direct "FixToInclude" > But that does not mean there will be no review. > But maybe I'm tainted ;) > > Nicolas > >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >
