Issue tracker states
Locked
 
|
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 |
|
Administrator
|
Thanks for the explanation. I was wondering...
Cheers,
Sean |
Re: Issue tracker states
|
|
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 <[hidden email]> wrote: Thanks for the explanation. I was wondering... -- 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 <[hidden email]> wrote: THanks Marcus :) |
|
|
In reply to this post by Sean P. DeNigris
On Oct 28, 2011, at 7:03 PM, Mariano Martinez Peck wrote: > THanks Marcus :) > Maybe we should put that explanation somewhere? > For example, in http://www.pharo-project.org/community/issue-tracking Yes, I will add it. Marcus -- Marcus Denker -- http://marcusdenker.de |
|
|
In reply to this post by Marcus Denker-4
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 > > |
|
|
In reply to this post by Marcus Denker-4
2011/10/28 Marcus Denker <[hidden email]>:
> 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 >> >> >> > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |