2011/10/28 Marcus Denker <[email protected]>:
> 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
>
>
>

Reply via email to