durin42 added a comment.

  In https://phab.mercurial-scm.org/D1551#27331, @grim wrote:
  
  > As an outsider looking in, I can see both points of view here.  But as 
someone maintaining a large code base here I have to say I agree with Sean.  
The whole "we'll fix it later thing" is crap.  It never happens as long as the 
code "works good enough".  Case in point, I'm currently systematically removing 
228 #if 0's from the Pidgin code base, most of which were put there more than a 
decade ago.
  
  
  That is, frankly, the point: smf has been requesting reasonable improvements 
in a thing that is already working and widely deployed that are then resulting 
in us shipping *nothing*.
  
  > In my experience there are two times when code in this situation can/will 
be cleaned up.  Before it's merged or when someone working on a bug fix/feature 
get's completely frustrated with it's state and ends up refactoring the crap 
out of it.  Right now this feature is at the former but this discussion seems 
to be leading to the later, which is actively buying into the long term 
maintenance cost.  Perhaps Mercurial can afford that cost, but this is not 
something I would advise/condone on my own projects.
  
  My expectation is that I have two realistic choices: reject the feature I 
want, or take it with a hope that someday someone improves it to be better than 
it is today. I don't believe there's a path (as you seem to?) that involves 
someone meeting a higher bar to get this feature shared to all hg users in the 
next year.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D1551

To: pulkit, #hg-reviewers, durin42
Cc: grim, smf, durin42, dlax, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to