Re: [Wikitech-l] Meaning of fixme (Re: code review criticism (Re: Converting to Git?))

2011-03-27 Thread Happy-melon

Platonides platoni...@gmail.com wrote in message 
news:imm5c2$rib$1...@dough.gmane.org...
 Ilmari Karonen wrote:

 I think it might be a good idea to split these two cases into separate
 states.  My suggestion, off the top of my head, would be to leave
 fixme for the latter and add a new broken status for the former.

 +1
 We should also add another state for fixmes that are not about problems
 in the revision itself, but request for improving more code (eg. you
 should fix the same thing -added in MW 1.4- in other 10 locations of the
 code, too).

That sort of thing should be a tag, because it is orthogonal to (and can 
actually change independently of) the status of the revision itself.  It 
would make it impossible to 'ok' the revision without losing the 'extend' 
information, which is exactly the opposite of what we want.

--HM 



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Meaning of fixme (Re: code review criticism (Re: Converting to Git?))

2011-03-27 Thread Platonides
Happy-melon wrote:
 
 Platonides platoni...@gmail.com wrote in message 
 news:imm5c2$rib$1...@dough.gmane.org...
 Ilmari Karonen wrote:

 I think it might be a good idea to split these two cases into separate
 states.  My suggestion, off the top of my head, would be to leave
 fixme for the latter and add a new broken status for the former.

 +1
 We should also add another state for fixmes that are not about problems
 in the revision itself, but request for improving more code (eg. you
 should fix the same thing -added in MW 1.4- in other 10 locations of the
 code, too).
 
 That sort of thing should be a tag, because it is orthogonal to (and can 
 actually change independently of) the status of the revision itself.  It 
 would make it impossible to 'ok' the revision without losing the 'extend' 
 information, which is exactly the opposite of what we want.
 
 --HM 

Right. We should use an improve tag and stop using fixmes for that.


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Meaning of fixme (Re: code review criticism (Re: Converting to Git?))

2011-03-26 Thread Platonides
Ilmari Karonen wrote:
 This made me realize something that's only tangentially related to the 
 existing thread, namely that we're currently using the fixme status in 
 Code Review for two different kinds of commits:
 
   1. commits that are broken and need to be fixed or reverted ASAP, and
   2. commits that do more or less work, but need some followup work.
 
 An example of the first kind of commit would be something that throws 
 PHP fatal errors on a substantial fraction of page views.  An example of 
 the second kind might be something as minor as forgetting to update 
 RELEASE_NOTES.
 
 Of course, there's also a wide range of shades of gray between these two 
 extremes, such as changes that work most of the time but break  some 
 unusual setups or use cases.  Still, I do think that most fixme 
 commits can be fairly cleanly assigned to one or the other of these 
 categories, simply by asking oneself Can I run a usable wiki with this 
 code as it is?
 
 I think it might be a good idea to split these two cases into separate 
 states.  My suggestion, off the top of my head, would be to leave 
 fixme for the latter and add a new broken status for the former.

+1
We should also add another state for fixmes that are not about problems
in the revision itself, but request for improving more code (eg. you
should fix the same thing -added in MW 1.4- in other 10 locations of the
code, too).


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Meaning of fixme (Re: code review criticism (Re: Converting to Git?))

2011-03-25 Thread Chad
On Fri, Mar 25, 2011 at 10:30 AM, Ilmari Karonen nos...@vyznev.net wrote:
 On 03/24/2011 08:00 PM, Roan Kattouw wrote:
 * We need to set a clear policy for reverting problematic revisions
 (fixme's) if they aren't addressed quickly enough (again, let's say
 within a week). Currently we largely leave them be, but I think we
 should go back to something more decisive and closer to the keep
 trunk runnable, or else Brion kicks your ass paradigm and make it a
 bit more formal this time

 This made me realize something that's only tangentially related to the
 existing thread, namely that we're currently using the fixme status in
 Code Review for two different kinds of commits:

  1. commits that are broken and need to be fixed or reverted ASAP, and
  2. commits that do more or less work, but need some followup work.

 An example of the first kind of commit would be something that throws
 PHP fatal errors on a substantial fraction of page views.  An example of
 the second kind might be something as minor as forgetting to update
 RELEASE_NOTES.

 Of course, there's also a wide range of shades of gray between these two
 extremes, such as changes that work most of the time but break  some
 unusual setups or use cases.  Still, I do think that most fixme
 commits can be fairly cleanly assigned to one or the other of these
 categories, simply by asking oneself Can I run a usable wiki with this
 code as it is?

 I think it might be a good idea to split these two cases into separate
 states.  My suggestion, off the top of my head, would be to leave
 fixme for the latter and add a new broken status for the former.

 Of course, we really shouldn't expect to have any broken commits in CR
 at any given time, since they really should be reverted and marked as
 such by the first person who can do so.  But I think that being able to
 mark a commit as broken and needing a revert, even if you can't revert
 it yourself just then for some reason (no time, no svn access,
 whatever), could be a good idea.  It would also make it less likely for
 such commits to get lost (even temporarily) among the less urgent fixmes.

 (Ps. I'd also like to note that I very much agree with what Roan wrote
 in general, and I'd very much like to see us going back to something
 like the system he proposed.  +1.)


+1 to everything Roan said and +1 to everything above.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l