Re: [PATCH 00/13] remote-hg: general updates

On Sat, Apr 6, 2013 at 8:09 AM, Philip Oakley [off-list ref] wrote:

From: "Felipe Contreras" <redacted>
Sent: Saturday, April 06, 2013 1:45 AM

quoted

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

quoted

   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.

quoted

 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