On Sat, Apr 6, 2013 at 8:09 AM, Philip Oakley <philipoakley@xxxxxxx> wrote: > From: "Felipe Contreras" <felipe.contreras@xxxxxxxxx> > Sent: Saturday, April 06, 2013 1:45 AM >> Ultimately this is not about people, this is about the code. > > > In the case of helper functions this is not the case. > > The question would be better framed: > "Does this, or that, helper function make users (people) feel helped, or > frustrated (or somewhere in limbo)?". And that question is ultimately answered by code. > I've called IT help desks and often felt frustrated, and some times I've got > one of the good girls/guys who worked with me to improve my situation (often > despite official policies). I get back to those folks (even if they > 'failed'). That is not an issue when you don't have a situation that needs support, when everything just works. Having one issue with bad support is better than having 5 issues with good support. > It's not a binary black/white issue when real users need help. It's no good > keeping with the faith (e.g. the Git ideal, the coders ideal, ..) when the > users (a mixed group) environmental doctine differs. And neither Max or Jed are users, so this doesn't apply to them. As for actual users, well show me, which remote-hg users have had bad support? https://github.com/felipec/git/issues >> A sensible person that is not emotionally attached to any code, > > [I'm thinking users here, they are emotionally attached to their original > problem, and sense doesn't come into it] That's irrelevant, a sensible developer would maximize the amount of issues that do **not** hit the users. >> would simply look at the code, > > Unfortunately, even for reasonable coders, looking at the code isn't usually > the case because of lack of time, unfamiliarity with the code, extent of the > code, availablity of the code (they may be simply running a > packaged/compiled 'app'), this is not that likely to happen. We should be > thankful when folk do look. If this sensible developer doesn't have time to look at remote-hg code, he has less time to make a possibly inferior alternative work on par or better. Thus a sensible developer would either look at remote-hg code, or do not develop. > It's hard enough to get "good" bug reports from fellow coders (they are only > human / no more human than us) that tell us what _we_ want to know (rather > than what _they_ remember, or was important to them). ;-) Nobody is asking for that. > I don't use Hg, but as I read the discussion, there are incomaptibilities > between Git, and Hg. Thus neither helper can ever be perfect. The winners > will be those who solve a user need with enough documentation and error > capture to make them (their user group) feel happy. At the moment it looks > like the discussion is stratifying into various "it worked for me" camps, > each with their own problem children repos that won't respond to parental > advice, even with a --force from social services. I don't think so. The discussion has been about hypothetical, not real users. The one person that did claim was hit by a bug, had no evidence for it nor cared, so it hardly matters. The rest is in pondering such as if the user does this and that, and somebody else in the team does that, and then the user does this, and the team has that policy, they might end in a bit of a kerfuffle. Not something that has _actually_ happened. And I'm confident that with time it will be shown that in terms of real issues, remote-hg would have less, and be fixed faster. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html