[Pharo-project] Issue tracker states
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 -- Marcus Denker -- http://marcusdenker.de
Thanks for the explanation. I was wondering... -- View this message in context: http://forum.world.st/Issue-tracker-states-tp3948297p3948360.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
THanks Marcus :) Maybe we should put that explanation somewhere? For example, in http://www.pharo-project.org/community/issue-tracking On Fri, Oct 28, 2011 at 5:59 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Thanks for the explanation. I was wondering...
-- View this message in context: http://forum.world.st/Issue-tracker-states-tp3948297p3948360.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
there was a issue work flow in that page, but now it has disappeared. On Fri, Oct 28, 2011 at 2:03 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
THanks Marcus :) Maybe we should put that explanation somewhere? For example, in http://www.pharo-project.org/community/issue-tracking
On Fri, Oct 28, 2011 at 5:59 PM, Sean P. DeNigris <sean@clipperadams.com>wrote:
Thanks for the explanation. I was wondering...
-- View this message in context: http://forum.world.st/Issue-tracker-states-tp3948297p3948360.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Mariano http://marianopeck.wordpress.com
Yes I like that list Stef On Oct 28, 2011, at 5:42 PM, Marcus Denker wrote:
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
-- Marcus Denker -- http://marcusdenker.de
2011/10/28 Marcus Denker <marcus.denker@inria.fr>:
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
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
participants (6)
-
Bernardo Ezequiel Contreras -
Marcus Denker -
Mariano Martinez Peck -
Nicolas Cellier -
Sean P. DeNigris -
Stéphane Ducasse