Just a friendly reminder to everyone about their outstanding FIXMEs in Code Review. The following is a list of everyone who has a commit with a fixme on it:
mah - 5 tparscal - 5 jeroendedauw - 4 reedy - 4 siebrand - 4 catrope - 3 werdna - 3 adam - 2 maxsem - 2 neilk - 2 philip - 2 aaron - 1 brion - 1 dale - 1 daniel - 1 demon - 1 devunt - 1 diana - 1 gurch - 1 hartman - 1 ishimatsu - 1 jojo - 1 mgrabovsky - 1 ning - 1 pdhanda - 1 purodha - 1 platonides - 1 shmichael - 1 simetrical - 1 svip - 1 than4213 - 1 thomasv - 1 tisane - 1 tomasz - 1 tstarling - 1 vyznev - 1
TOTAL: 63
Please be sure to ping anyone you know isn't on this mailing list (like some contractors, or people working on special projects maybe?) so we can get everyone informed.
Thanks,
-Chad
Yay, I'm in the top 3! :)
-- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! --
On 9 June 2010 11:02, Chad [email protected] wrote:
Just a friendly reminder to everyone about their outstanding FIXMEs in Code Review. The following is a list of everyone who has a commit with a fixme on it:
mah - 5 tparscal - 5 jeroendedauw - 4 reedy - 4 siebrand - 4 catrope - 3 werdna - 3 adam - 2 maxsem - 2 neilk - 2 philip - 2 aaron - 1 brion - 1 dale - 1 daniel - 1 demon - 1 devunt - 1 diana - 1 gurch - 1 hartman - 1 ishimatsu - 1 jojo - 1 mgrabovsky - 1 ning - 1 pdhanda - 1 purodha - 1 platonides - 1 shmichael - 1 simetrical - 1 svip - 1 than4213 - 1 thomasv - 1 tisane - 1 tomasz - 1 tstarling - 1 vyznev - 1
TOTAL: 63
Please be sure to ping anyone you know isn't on this mailing list (like some contractors, or people working on special projects maybe?) so we can get everyone informed.
Thanks,
-Chad
Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Wed, Jun 9, 2010 at 7:12 PM, Jeroen De Dauw [email protected] wrote:
Yay, I'm in the top 3! :)
-- Jeroen De Dauw
That isn't a good thing. -Peachey
It is. It means that developer solves difficult problems. The bas thing is many "reverted".
On Jun 9, 2010 2:30 PM, "K. Peachey" [email protected] wrote:
On Wed, Jun 9, 2010 at 7:12 PM, Jeroen De Dauw [email protected] wrote: > Yay, I'm in the top... That isn't a good thing. -Peachey
_______________________________________________ Wikitech-l mailing list [email protected]....
Some searchs: http://www.google.com/codesearch?hl=en&lr=&q=package%3Amediawiki+FIX... http://www.google.com/codesearch?hl=en&lr=&q=package%3Amediawiki+TOD... http://www.google.com/codesearch?hl=en&lr=&q=package%3Amediawiki+UGL...
On 9 June 2010 17:27, Victor Vasiliev [email protected] wrote:
It is. It means that developer solves difficult problems. The bas thing is many "reverted".
On Jun 9, 2010 2:30 PM, "K. Peachey" [email protected] wrote:
On Wed, Jun 9, 2010 at 7:12 PM, Jeroen De Dauw [email protected] wrote: > Yay, I'm in the top... That isn't a good thing. -Peachey
On Wed, Jun 9, 2010 at 11:41 AM, Tei [email protected] wrote:
Some searchs: http://www.google.com/codesearch?hl=en&lr=&q=package%3Amediawiki+FIX... http://www.google.com/codesearch?hl=en&lr=&q=package%3Amediawiki+TOD... http://www.google.com/codesearch?hl=en&lr=&q=package%3Amediawiki+UGL...
Those are all fairly old versions.
(Realized I hadn't actually subscribed, so re-sending.)
Chad [email protected] writes:
mah - 5
When a FIXME is fixed, my understanding is that the fixer isn't supposed to un-mark the FIXME. If I'm wrong, I'll toggle a few of these to RESOLVED. Looking at the recent state changes, it isn't clear that the committer is supposed to mark it RESOLVED.
Since I'm at the top of the list:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/62006
Fixed.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/66696
Fixed but failed to commit. Committed.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/66698
Fixed. Six days later (as I started my vacation) Platonides added another item that needed fixing. Fixed just now.
Which leaves these two:
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/61911 http://www.mediawiki.org/wiki/Special:Code/MediaWiki/65152
At least I've moved down the list :)
Mark.
On Thu, Jun 10, 2010 at 11:40 AM, Mark A. Hershberger [email protected] wrote:
(Realized I hadn't actually subscribed, so re-sending.)
Chad [email protected] writes:
mah - 5
When a FIXME is fixed, my understanding is that the fixer isn't supposed to un-mark the FIXME. If I'm wrong, I'll toggle a few of these to RESOLVED. Looking at the recent state changes, it isn't clear that the committer is supposed to mark it RESOLVED.
This is a general note to all committers, since I keep seeing the same question asked. Committers should never set their own revisions to "OK" or "RESOLVED." Even if you review code, review other people's code and let other people review yours :)
-Chad
2010/6/10 Chad [email protected]:
This is a general note to all committers, since I keep seeing the same question asked. Committers should never set their own revisions to "OK" or "RESOLVED." Even if you review code, review other people's code and let other people review yours :)
I do believe it's acceptable to reset the status of a FIXME back to NEW when you've addressed all the comments. It can then be reviewed again.
Roan Kattouw (Catrope)
On Thu, Jun 10, 2010 at 12:22 PM, Roan Kattouw [email protected] wrote:
I do believe it's acceptable to reset the status of a FIXME back to NEW when you've addressed all the comments. It can then be reviewed again.
It would be nice if this weren't necessary, but in practice people set a commit to fixme, then don't set it back when it's fixed. So when my commits are marked fixme and I address the problem, I set them back to whatever it was beforehand, generally. It's only reasonable, if people are going to post lists of how many outstanding fixmes there are for everyone.
On Thu, Jun 10, 2010 at 9:22 AM, Roan Kattouw [email protected]wrote:
2010/6/10 Chad [email protected]:
This is a general note to all committers, since I keep seeing the same question asked. Committers should never set their own revisions to "OK" or "RESOLVED." Even if you review code, review other people's code and let other people review yours :)
I do believe it's acceptable to reset the status of a FIXME back to NEW when you've addressed all the comments. It can then be reviewed again.
In general, moving an issue out of FIXME seems like the right thing to do for issues that the original developer thinks have been addressed, since "fixme" is implicitly assigned to the original committer.
I was going to chime in and say that "new" seems like the right state to go into, but what about the (very common) case where a later checkin fixes the original "fixme"? Can't the committer put the original checkin in "resolved", and redirect any further discussion to the followup checkin (which should remain "new")?
The only time it seems like a checkin should go back into "new" state is when the committer stands by the original commit, and has provided further rationale for it in the comments.
Rob
On Sun, Jun 13, 2010 at 4:47 PM, Rob Lanphier [email protected] wrote:
I was going to chime in and say that "new" seems like the right state to go into, but what about the (very common) case where a later checkin fixes the original "fixme"? Can't the committer put the original checkin in "resolved", and redirect any further discussion to the followup checkin (which should remain "new")?
Often "fixme" is set when there's only one detail of the commit that's bad. In that case, the rest of the commit still needs to be reviewed, and setting it to "resolved" will obscure that. The fix for the bad aspect of the commit needs to be reviewed separately.
Personally, I think we should just ditch "resolved" as a possible status. If there are still parts to review, set to "new". If it was set to "ok" and then the flaw was found and fixed, set back to "ok". If the entire commit was flawed and the new commit supersedes it, set to "reverted". The fix should be "new" in all cases.