From: Junio C Hamano <hidden> Date: 2016-06-15 22:57:00
Felipe Contreras [off-list ref] writes:
But I do not care that much really. The patch is good either way, if
you don't like it, you go ahead and fix it, because I won't. I have
174 remote-helper related patches in my queue, and nobody benefits
from rambling about a one liner that is obviously correct, not you,
not me, not the users, not the developers.
Three random points.
* For this particular patch [1/9], especially because this would
land close to the corresponding remote-hg fixes (e.g. "has_key is
deprecated"), I think it is sufficient to say "port fixes from
corresponding remote-hg patches" (you said it in 0/9 and didn't
say it in 1/9, though) without going into individual details.
Anybody who wonders what these changes were about will have a
clue to check contemporary patches to remote-hg that way.
* You may want to hold onto those 174 patches and polish their
explanation up to save the list audiences' time by avoiding this
kind of useless "why no explanation" exchanges.
* If you do not want to keep a readable history, it would mean that
nobody but you will fix problems discovered in the future in
remote-hg, and there is no point carrying it in my tree for other
Git developers to look at it. The users are better off getting
them from your tree and that will make it clear for them whom to
ask help/fix for when they hit a snag.
Junio of course might disagree and drop this patch, but then he would
need to deal with the fallout of possible conflicts.
A much more sensible thing in such a case for me to do actually is
to drop the whole thing. I do not want to do that unless necessary.
... I think the less-than-perfect commit messages in a
*contrib* script that is extremely recent is a small price to pay for
having nice and workable bzr and mercurial remote-helpers as soon as
possible
I do not share this view at all. The users survived without it long
enough; they can wait for a well maintained version. On the other
hand, shipping something that will not be maintainable is not the
way to help end users. It is being irresponsive to them.
Helping other developers understand your code is a way to ensure
that your code that would help users will be kept maintained. I do
not agree with Ram at all when he says that developers are more
important than users, and I agree with you that the project exists
for users, and not for developers. But you need to help your fellow
developers anyway by spending effort to keep your history readable,
in order to help them help the users.
Do not take the "users matter" mantra to the extreme. You need other
developers to put users first.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:00
On Thu, Apr 25, 2013 at 3:36 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
But I do not care that much really. The patch is good either way, if
you don't like it, you go ahead and fix it, because I won't. I have
174 remote-helper related patches in my queue, and nobody benefits
from rambling about a one liner that is obviously correct, not you,
not me, not the users, not the developers.
Three random points.
* For this particular patch [1/9], especially because this would
land close to the corresponding remote-hg fixes (e.g. "has_key is
deprecated"), I think it is sufficient to say "port fixes from
corresponding remote-hg patches" (you said it in 0/9 and didn't
say it in 1/9, though) without going into individual details.
Anybody who wonders what these changes were about will have a
clue to check contemporary patches to remote-hg that way.
I don't see the value of pointing that out in the particular commit,
since you are the only one that would do anything with that
information, and it seems the message came across.
If there's any issues with that, just drop the patch, and if there's
issues with the rest of the series, just drop them. I'll resend when
the stuff is merged to master.
* You may want to hold onto those 174 patches and polish their
explanation up to save the list audiences' time by avoiding this
kind of useless "why no explanation" exchanges.
That's exactly what I've been doing.
You are extrapolating from this particular patch, which I already
admitted I made a mistake, and it's not really important in any way.
* If you do not want to keep a readable history, it would mean that
nobody but you will fix problems discovered in the future in
remote-hg, and there is no point carrying it in my tree for other
Git developers to look at it. The users are better off getting
them from your tree and that will make it clear for them whom to
ask help/fix for when they hit a snag.
The history *is* readable. If anybody has any problems with the commit
messages, the place to mention such problems is IN THE PATCH REVIEW.
Nobody has done that, because either nobody has any problems, or they
are not interested. Either way, there's nothing I can do about it.
*This* patch is an exception, and I'm not willing to waste time on
this extremely trivial patch. Drop it.
quoted
Junio of course might disagree and drop this patch, but then he would
need to deal with the fallout of possible conflicts.
A much more sensible thing in such a case for me to do actually is
to drop the whole thing. I do not want to do that unless necessary.
You want to drop the whole series because of a cleanup patch with a
less-than-perfect commit message? Even though there quite likely won't
be any conflicts if you drop the single patch. Fine, drop the whole
series.
quoted
... I think the less-than-perfect commit messages in a
*contrib* script that is extremely recent is a small price to pay for
having nice and workable bzr and mercurial remote-helpers as soon as
possible
I do not share this view at all. The users survived without it long
enough; they can wait for a well maintained version. On the other
hand, shipping something that will not be maintainable is not the
way to help end users. It is being irresponsive to them.
Are you saying that because *ONE PATCH*, introduces a fix without
mentioning it in the commit message, *THE WHOLE* project becomes
unmaintainable?
If not, then why are we discussing about something that is not happening?
Helping other developers understand your code is a way to ensure
that your code that would help users will be kept maintained. I do
not agree with Ram at all when he says that developers are more
important than users, and I agree with you that the project exists
for users, and not for developers. But you need to help your fellow
developers anyway by spending effort to keep your history readable,
in order to help them help the users.
And I am. Because I made a mistake in this patch doesn't mean the same
happened in all the patches.
I am helping my fellow developers by replying to the comments they
make when I send the patches for review. Unfortunately, the only
developer other than you that has made any comment at all, Ramkumar
Ramachandra, did so in a bellicose tone, but I replied to all his
comments either way, which where invalid. The only comment where he is
right and I acknowledged making a small mistake, is trivial, does not
cause any issues, and can be easily dropped.
Do not take the "users matter" mantra to the extreme. You need other
developers to put users first.
No, I don't. It would be nice, yes, but not necessary.
Now, let's drop this pointless discussion and deal with the actual
issue. What do you want to do?
1) Drop this patch
2) Drop the whole series
3) I reroll without the change that was not described
Anything else, I'm not interested in doing. There's tasks with actual
value to do.
Cheers.
--
Felipe Contreras
I am helping my fellow developers by replying to the comments they
make when I send the patches for review. Unfortunately, the only
developer other than you that has made any comment at all, Ramkumar
Ramachandra, did so in a bellicose tone, but I replied to all his
comments either way, which where invalid.
I've never wanted to pick fights with anyone, and I don't foresee
having a desire to do so in the future. I was just saying what was on
my mind, which is along the lines of: you have written this patch with
the attitude "I know what I'm doing, my users will benefit, and nobody
else is going to look at this patch anyway"; I'm worried about what
your other patches look like if this is your attitude towards
development. Junio is harping about the same thing: the impedance
mismatch between you and the rest of us.
The history *is* readable. If anybody has any problems with the commit
messages, the place to mention such problems is IN THE PATCH REVIEW.
Nobody has done that, because either nobody has any problems, or they
are not interested. Either way, there's nothing I can do about it.
That's what I've been trying to say over and over again: _why_ are
people not reviewing your patches?
0. Because nobody has any problems with them.
1. Because nobody on the git list cares about remote-hg.
2. Because you're stubborn as a mule, and the resulting thread often
results in long-winded discussions like this one (which wastes
everyone's time). Therefore, the potential reviewer's reasoning is
that their review time is better spent elsewhere, where their review
is actually appreciated.
Hint: it's not (0).
If you're claiming that (1) is the case, then why are you posting to
the git list and hitting everyone's inboxes? Maintain your project
outside git.
I'm claiming that it's (2). In which case, it's you who needs changing.
I'm willing to change my ways when there's reason to change my ways,
and so far, nobody has provided any evidence that my commit messages
are indeed lacking, only *opinions*.
You want a formal mathematical proof? We operate on opinions, and
freeze what we think we all agree with into "community guidelines".
So you're now claiming that we're the ones at fault (Peff, Thomas,
Junio, and me, among others). Okay, so why are you forcing your
changes and opinions down our throats? You're in the wrong community:
join a community of people who are more like you (or start your own
project), and stop wasting our time.
Junio C Hamano wrote:
I do
not agree with Ram at all when he says that developers are more
important than users, and I agree with you that the project exists
for users, and not for developers.
On this.
If Peff were to suddenly stop working on git one day (because he was
frustrated with the community/ development practices), we'd all lose a
lot more than if one random end-user switches to using hg for his tiny
personal projects. I'm _not_ claiming that there's a split between
users and users that are developers (we have one mailing list for
everyone, and I like that). What I'm claiming is that we cannot (and
should not) pay equal attention to every user of git. Some users are
more important than others. Again, that does _not_ mean that we push
a change that benefits one important user but breaks everyone else's
setup.
Ofcourse the project exists for its users; we're not doing research.
However, we don't all have to write tutorials to keep in touch with
end-users who are completely detached from the development process
(our time is better spent elsewhere), or even have an
end-user-friendly bug tracker (where the SNR is very low). We don't
have to consciously reach out to people we're not connected to
directly: if we're all sufficiently connected to the real world, the
itches/ bugs worth working on will always find their way to us. We
live in a connected world.
Yes, I know. You're going to respond to this email arguing about why
you're Right and why I (and everyone else) is Wrong, either by quoting
what Linus (TM) said and twisting it to mean what you want, belaboring
over what you've already said, or something similar.
I've given up on you, and I suspect a lot of other people have too.
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:01
On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Felipe Contreras wrote:
quoted
I am helping my fellow developers by replying to the comments they
make when I send the patches for review. Unfortunately, the only
developer other than you that has made any comment at all, Ramkumar
Ramachandra, did so in a bellicose tone, but I replied to all his
comments either way, which where invalid.
I've never wanted to pick fights with anyone, and I don't foresee
having a desire to do so in the future. I was just saying what was on
my mind, which is along the lines of: you have written this patch with
the attitude "I know what I'm doing, my users will benefit, and nobody
else is going to look at this patch anyway";
That is an assumption, it's wrong, and it's antagonistic. There's no
need for that.
I'm worried about what
your other patches look like if this is your attitude towards
development.
More assumptions and hypotheticals. Why don't we limit ourselves to
facts and reality?
quoted
The history *is* readable. If anybody has any problems with the commit
messages, the place to mention such problems is IN THE PATCH REVIEW.
Nobody has done that, because either nobody has any problems, or they
are not interested. Either way, there's nothing I can do about it.
That's what I've been trying to say over and over again: _why_ are
people not reviewing your patches?
0. Because nobody has any problems with them.
1. Because nobody on the git list cares about remote-hg.
2. Because you're stubborn as a mule, and the resulting thread often
results in long-winded discussions like this one (which wastes
everyone's time). Therefore, the potential reviewer's reasoning is
that their review time is better spent elsewhere, where their review
is actually appreciated.
Hint: it's not (0).
If you're claiming that (1) is the case, then why are you posting to
the git list and hitting everyone's inboxes? Maintain your project
outside git.
I'm claiming that it's (2). In which case, it's you who needs changing.
This is the false dichotomy fallacy, why does it have to be only one
of these reasons? Couldn't it be a mixture of them? Maybe most people
don't care about remote-{bzr,hg}, maybe for the ones that do, most
don't see any problems in the patches, and maybe the ones that do see
problems in the patches don't bring them up, because of various
reasons, like for example, they don't see them as major, and would
rather fix them themselves later after investigation if they are
indeed import problems, or maybe they just don't have time to engage
in discussions.
Yes, there's a possibility that my stubbornness is a factor, and given
their possible lack of time, and possible lack of interested, they
choose to not engage.
But to claim that *everyone* is in (2), and that there are no other
factors that made them land in (2) but my stubbornness is disingenuous
at best.
What would you think of a scientist that says, oh, "I'm not going to
review that paper, because each time I do that, the reviewee defends
it, and we end up with long-winded discussions". This scientist
doesn't have the right spirit.
If you submit a review comment, you should be prepared to do defend
it, just like you do when you submit a patch. And you should be
prepared to accept that your patch has mistakes, just like you should
be prepared to accept that your review has mistakes. In this view,
stubbornness is a good thing, because it brings the best in the
reviewer, and in the reviewee, and in the end everyone benefits by
trying to achieve the higher quality possible. Just like stubbornness
is a good thing in science, if both reviwer and reviewee fight for
their point of view, only the best science wins, and we all benefit.
This is all of course if the stubbornness is warranted, but you
haven't claimed that it wasn't, simply that I was stubborn. Well, so
what? Isn't that good?
Show me where I was unreasonable, show me where I was wrong, not where
I was stubborn. One can be stubborn and be right, in fact, when one is
right, it's when one has all the more right to be stubborn.
If you are not prepared to defend your review, so are others, why to
you blame that on me? If you were right, you would be shown to be
right. Period.
quoted
I'm willing to change my ways when there's reason to change my ways,
and so far, nobody has provided any evidence that my commit messages
are indeed lacking, only *opinions*.
You want a formal mathematical proof? We operate on opinions, and
freeze what we think we all agree with into "community guidelines".
No, we operate in evidence and reason, *not* opinion. Any reasonable
person would say "well, I *think* this commit message needs more
description, but I don't *know*, I don't have *evidence* for it, so
I'm not going to fight to the death, as if I had".
Any reasonable person would know the difference between an opinion,
and an objective fact. And react accordingly when another person
attacks an opinion, which is not a big deal, and when an objective
fact is attacked, which is a big deal.
So you're now claiming that we're the ones at fault (Peff, Thomas,
Junio, and me, among others). Okay, so why are you forcing your
changes and opinions down our throats?
Where am I doing that?
First of all, lets not act like bitching girlfriends arguing about who
didn't throw the trash three years ago. We are talking about
*remote-bzr*, in fact, the subject is "[PATCH 1/9] remote-bzr: trivial
cleanups". *NONE* of this discussion is relevant to that patch.
If we go one step above, to remote-helpers in general, nobody has
commented *ANYTHING* negative on those patches, you are the first to
do so. So how exactly did I managed to shove 71 patches down you
throat if everybody complained all the way?
Ultimately the decision to merge or not to merge comes to Junio, if
you don't like his decision, go complain to him, but I would be
prepared with points in time where people complained about these
patches, and there are no complains, so you have no ammunition at all
whatsoever.
If you are talking about something else, FFS, change the subject line.
If you want to argue about who didn't take out the trash three years
ago, fine, but lets do so clearly in another thread, not this one
about a *single trivial patch*.
You're in the wrong community:
join a community of people who are more like you (or start your own
project), and stop wasting our time.
And this is how communities die. When everybody thinks the same, and
everyone who thinks differently is displaced. A monoculture, a place
full of yes-men where nobody criticizes anybody, a circlejerk where
everyone palms the back of everyone else. Eventually things go south,
and nobody around you understands why.
Diversity in a community is healthy. If you don't like people who
think differently, *you* have a problem. If you don't like standing up
and defending your ideas, *you* have a problem. If you don't like
discussing on the basis of evidence and reason, *you* have a problem.
Cheers.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:01
On Fri, Apr 26, 2013 at 4:32 AM, Ramkumar Ramachandra
[off-list ref] wrote:
Felipe Contreras wrote:
Junio C Hamano wrote:
quoted
I do
not agree with Ram at all when he says that developers are more
important than users, and I agree with you that the project exists
for users, and not for developers.
On this.
If Peff were to suddenly stop working on git one day (because he was
frustrated with the community/ development practices), we'd all lose a
lot more than if one random end-user switches to using hg for his tiny
personal projects.
Yeah but that's not happening is it? This is yet another hypothetical.
Last I checked Peff never threatened to leave the project. Did I miss
a memo?
The last time somebody announced he was going to leave the project we
did what was reasonable; investigate the reasons. And that's what we
would do if Peff threatened to leave.
But fine, lets assume there's a hypothetical Peff, with hypothetical
reasons to leave the project...
I'm _not_ claiming that there's a split between
users and users that are developers (we have one mailing list for
everyone, and I like that). What I'm claiming is that we cannot (and
should not) pay equal attention to every user of git. Some users are
more important than others. Again, that does _not_ mean that we push
a change that benefits one important user but breaks everyone else's
setup.
The importance of users changes all the time. The 15 year old kid in
Sao Paulo might not be important today, but he might be the single
most important contributor ten years from now. Hell, he might even
replace Junio as the maintainer.
Who are you to decide which users are important, and which are not?
Ofcourse the project exists for its users; we're not doing research.
However, we don't all have to write tutorials to keep in touch with
end-users who are completely detached from the development process
(our time is better spent elsewhere),
Maybe we should, and maybe we would see then some areas of
improvement. In fact, I have done so, and I do see lots of areas of
improvement in git's UI.
I agree that there are more important areas, or rather, more fun to
work with, but the fact that most git developers don't pay too much
attention to the pain of newcomers shows, and it's a very common
criticism of git; it's difficult to learn, it doesn't have a
consistent UI, many commands don't make sense. And I happen to agree
with that claim, but it's not an easy problem to solve, specially when
you care about *all* users, both old and new, which we do.
We should keep in mind the problems in git's UI for newcomers. There's
no reason no to.
or even have an
end-user-friendly bug tracker (where the SNR is very low). We don't
have to consciously reach out to people we're not connected to
directly: if we're all sufficiently connected to the real world, the
itches/ bugs worth working on will always find their way to us. We
live in a connected world.
Nobody is claiming we need a bug tracker, there's no point in arguing
about that. The rate at which we fix bugs or our tracking of them is
not a problem.
Yes, I know. You're going to respond to this email arguing about why
you're Right and why I (and everyone else) is Wrong, either by quoting
what Linus (TM) said and twisting it to mean what you want, belaboring
over what you've already said, or something similar.
Where did I twist anything? You can see Linus talk himself:
http://www.youtube.com/watch?v=kzKzUBLEzwk
Point me exactly where does he say some users are more important than
others, in fact, he is saying the opposite, the amount of people that
needed the Linux version compatibility flag was really really small,
yet they did it, why? Because *all* users matter. Not that it matters
what Linus says, what matters is that it's right; the moment you start
balkanizing your user base, the moment you start giving some them
reason to fork the project. When was the last time Linux was forked?
GNOME did exactly that, they said; you, users over there, we don't
care about you anymore, what did they do? Fork. They lost so many
users they had to revert their decision.
Should we willingly and knowingly neglect some git user-base? No, why
would you want them to fork? In a way, git's UI has been so bad, that
some kind-of-forks have happened, that tells us something; the UI
needs some love, fortunately none of those forks worked, which tells
us something too; it's not too atrocious.
That's not to say we shouldn't fix the UI, we should, in a way that
everyone's happy, which is hard, but we will do it, eventually.
Cheers.
--
Felipe Contreras
No, we operate in evidence and reason, *not* opinion. Any reasonable
person would say "well, I *think* this commit message needs more
description, but I don't *know*, I don't have *evidence* for it, so
I'm not going to fight to the death, as if I had".
Don't you think you're taking reason to an extreme here? Reason is a
tool that I use when I want. I don't want reason when I'm browsing
Google Art Project or listening to Gentle Giant. Arguments like "is
this commit message large enough?" are really not worth the time and
effort.
Ultimately the decision to merge or not to merge comes to Junio, if
you don't like his decision, go complain to him, but I would be
prepared with points in time where people complained about these
patches, and there are no complains, so you have no ammunition at all
whatsoever.
I have no desire to "attack" you, Felipe. I respect you as a more
experienced developer than myself, and am trying to offer constructive
criticism.
I don't have an ego (or consider myself important to the community).
Whatever will happen will happen, with or without me.
And this is how communities die. When everybody thinks the same, and
everyone who thinks differently is displaced. A monoculture, a place
full of yes-men where nobody criticizes anybody, a circlejerk where
everyone palms the back of everyone else. Eventually things go south,
and nobody around you understands why.
Diversity in a community is healthy. If you don't like people who
think differently, *you* have a problem. If you don't like standing up
and defending your ideas, *you* have a problem. If you don't like
discussing on the basis of evidence and reason, *you* have a problem.
Diversity is certainly healthy, and I it would be nice to have you in
the community. We just have to find a way to keep the conflict down.
Diversity is certainly healthy, and I it would be nice to have you in
the community. We just have to find a way to keep the conflict down.
After all, what are we asking for? Better commit messages. Why are
you making such a big deal out of it? You want diversity in "length/
form of commit messages"?
I agree, and I have discussed about issues with diff in the past,
unfortunately didn't reach any conclusion. I've tried to follow that
thread, but I don't really know what is actually being proposed
anymore.
If you are so keen in receiving feedback from your fellow developers,
you should eventually send an email summarizing the issues and the
proposal for everyone to understand.
In contrast, I take it you agree this trivial patch is not worth
discussing, which I agreed in my first reply.
quoted
No, we operate in evidence and reason, *not* opinion. Any reasonable
person would say "well, I *think* this commit message needs more
description, but I don't *know*, I don't have *evidence* for it, so
I'm not going to fight to the death, as if I had".
Don't you think you're taking reason to an extreme here? Reason is a
tool that I use when I want. I don't want reason when I'm browsing
Google Art Project or listening to Gentle Giant. Arguments like "is
this commit message large enough?" are really not worth the time and
effort.
Reason is not a tool for appreciating art, reason is a tool for
discovering truth, and if when arguing you are not interested in what
is actually true, I'm not interested in arguing with you.
quoted
Ultimately the decision to merge or not to merge comes to Junio, if
you don't like his decision, go complain to him, but I would be
prepared with points in time where people complained about these
patches, and there are no complains, so you have no ammunition at all
whatsoever.
I have no desire to "attack" you, Felipe. I respect you as a more
experienced developer than myself, and am trying to offer constructive
criticism.
I don't have an ego (or consider myself important to the community).
Whatever will happen will happen, with or without me.
I appreciate your criticism, but that doesn't mean I must agree with
it. And if I do agree, that doesn't mean I must act upon it.
quoted
And this is how communities die. When everybody thinks the same, and
everyone who thinks differently is displaced. A monoculture, a place
full of yes-men where nobody criticizes anybody, a circlejerk where
everyone palms the back of everyone else. Eventually things go south,
and nobody around you understands why.
Diversity in a community is healthy. If you don't like people who
think differently, *you* have a problem. If you don't like standing up
and defending your ideas, *you* have a problem. If you don't like
discussing on the basis of evidence and reason, *you* have a problem.
Diversity is certainly healthy, and I it would be nice to have you in
the community. We just have to find a way to keep the conflict down.
A fine way to start is to not rattle away in trivial inconsequential patches.
Cheers.
--
Felipe Contreras
The importance of users changes all the time. The 15 year old kid in
Sao Paulo might not be important today, but he might be the single
most important contributor ten years from now. Hell, he might even
replace Junio as the maintainer.
Yes, I watched the talk when you posted the link last time. And yes,
I learnt something.
Should we willingly and knowingly neglect some git user-base? No, why
would you want them to fork? In a way, git's UI has been so bad, that
some kind-of-forks have happened, that tells us something; the UI
needs some love, fortunately none of those forks worked, which tells
us something too; it's not too atrocious.
No, we should never neglect. I believe in including everyone. In
fact I take it to an extreme: on many instances, I have pointed out
what I want specifically, and asked for a configuration option if it's
not necessarily a sane default. Git is a toolkit, and should be
loaded with features that even a few users want.
That's not to say we shouldn't fix the UI, we should, in a way that
everyone's happy, which is hard, but we will do it, eventually.
On this, I think the way forward is complete-implicit'ness via
configuration variables. I recently wrote remote.pushdefault to
simply 'git push', and proposed 'git push +ref1 ref2 ref3' to
automatically push to the correct pushdefaults (but that proposal was
rejected).
If you are so keen in receiving feedback from your fellow developers,
you should eventually send an email summarizing the issues and the
proposal for everyone to understand.
Thanks. I'll do that in the morning.
Reason is not a tool for appreciating art, reason is a tool for
discovering truth, and if when arguing you are not interested in what
is actually true, I'm not interested in arguing with you.
There is no great truth to be discovered by arguing about the length
of commit messages, Felipe. There are some "guidelines" or "axioms"
upon which we build reason. If you want to argue till everything
breaks down to Peano's Axioms, do Foundations of mathematics or
Analytical philosophy. From personal experience, it's much more
satisfying than arguing with other humans (who aren't exact
creatures).
I appreciate your criticism, but that doesn't mean I must agree with
it. And if I do agree, that doesn't mean I must act upon it.
Why not? Am I being unreasonable in asking you to justify your
changes, so I can understand what you've done with one quick reading?
I happen to agree with that, specially in the context of the Linux
kernel, but I don't see how that applies here. Linus is talking about
trivial patches from an entry-level developer, who has much to learn,
and this is one the best ways to do that.
But in particular, he is talking about the fact that prominent kernel
developers don't spend too much time on these trivial patches from
these entry-level developers, and that can be frustrating for these
entry-level developers, which can be problematic.
Nothing at all related to what we are facing here.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:01
On Fri, Apr 26, 2013 at 3:28 PM, Ramkumar Ramachandra
[off-list ref] wrote:
quoted
Reason is not a tool for appreciating art, reason is a tool for
discovering truth, and if when arguing you are not interested in what
is actually true, I'm not interested in arguing with you.
There is no great truth to be discovered by arguing about the length
of commit messages, Felipe. There are some "guidelines" or "axioms"
upon which we build reason.
And based on what do you build these guidelines and axioms if not
truth? Do you ask a computer to throw a number randomly from 0 to
infinite and that shall be the new axiom for what the perfect number
of words a commit message should have?
No, you determine that based on experience, and convenience. You find
a number that convenient to write, not hundreds of pages, and a number
that would help the reader if the patch in case a bug in the changes
is found on a later time, and that would help reviewers of code find
issues, and understand it. But most importantly, the number depends on
the complexity of the code changes. Note that I'm not saying on size,
because even one-liners can be extremely complex.
It's not arbitrary.
If you want to argue till everything
breaks down to Peano's Axioms, do Foundations of mathematics or
Analytical philosophy. From personal experience, it's much more
satisfying than arguing with other humans (who aren't exact
creatures).
I do not want to argue the fundamentals of logic and reason, but
unfortunately most people don't have a strong grasp on them.
So let me simply; truth matters, and how we find truth mattes. Which
is why the degree of certainty we have on certain facts matters; you
shouldn't act the same about a claim you are 10% sure it's true, than
with a claim you are 90% sure.
If you are 100% sure my commit messages are too short, then there's no
point in arguing with you. Nor if you think it doesn't matter if it's
90%, or 50%, or even 0%. Because it's an opinion, and an opinion
doesn't need any facts, or certainty, it just needs a person to hold
it, whatever unreasonable or unlikely it is.
quoted
I appreciate your criticism, but that doesn't mean I must agree with
it. And if I do agree, that doesn't mean I must act upon it.
Why not? Am I being unreasonable in asking you to justify your
changes, so I can understand what you've done with one quick reading?
I did justify everything, I just didn't act the way you wanted. I
didn't immediately resend the series with a full description of the
changes, because the changes, as I described before, are trivial. I
simply dropped the change you had a problem with, and moved on. It's
perfectly reasonable.
Cheers.
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2016-06-15 22:57:01
On Fri, Apr 26, 2013 at 3:17 PM, Ramkumar Ramachandra
[off-list ref] wrote:
Felipe Contreras wrote:
quoted
The importance of users changes all the time. The 15 year old kid in
Sao Paulo might not be important today, but he might be the single
most important contributor ten years from now. Hell, he might even
replace Junio as the maintainer.
Yes, they do. Did I say that they don't change?
But you implied we shouldn't care about Thiago (our hypothetical
future overlord), because he is among the users we should't care for
(right now).
quoted
Should we willingly and knowingly neglect some git user-base? No, why
would you want them to fork? In a way, git's UI has been so bad, that
some kind-of-forks have happened, that tells us something; the UI
needs some love, fortunately none of those forks worked, which tells
us something too; it's not too atrocious.
No, we should never neglect. I believe in including everyone. In
fact I take it to an extreme: on many instances, I have pointed out
what I want specifically, and asked for a configuration option if it's
not necessarily a sane default. Git is a toolkit, and should be
loaded with features that even a few users want.
quoted
That's not to say we shouldn't fix the UI, we should, in a way that
everyone's happy, which is hard, but we will do it, eventually.
On this, I think the way forward is complete-implicit'ness via
configuration variables. I recently wrote remote.pushdefault to
simply 'git push', and proposed 'git push +ref1 ref2 ref3' to
automatically push to the correct pushdefaults (but that proposal was
rejected).
Indeed, I learned about that, and I tried to use it, but I think
there's a lot that is missing, and I don't know myself what would be
ideal. I'm starting to think that a branch should have two upstreams;
one that is used for rebasing, and another that is used for pushing.
But I'm not sure.
Eventually, I would like to do 'git push' and I would push different
branches to different repositories in different destination branches
in a way that requires multiple commands right now 'git push github
fc/remote-old/hg:fc/remote/hg', 'git push --prune backup
refs/heads/*:refs/heads/* refs/tags/*:refs/tags/*'. And to figure
things out I'm also helping; I added the --prune option to push, and I
added color to visualize upstream branches in 'git branch'.
But I don't think any of those are as important as having a proper
'git stage' command, and getting rid of --cached and --index, which
will be a huge effort, but would pay even bigger dividends. Step by
step.
Cheers.
--
Felipe Contreras