emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repo cpnversion progress report


From: David Kastrup
Subject: Re: Repo cpnversion progress report
Date: Sat, 01 Feb 2014 10:38:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

"Eric S. Raymond" <address@hidden> writes:

> Juanma Barranquero <address@hidden>:
>> Well, do you at least agree with him when he says
>> 
>> > I'm ignored already.  You never accepted any argument of mine through
>> > that long and tiresome "discussion".  You are always right and all
>> > those who disagree with you are always wrong.
>> 
>> and
>> 
>> > I never had any influence over that, because you refuse to listen
>> > to any dissenting arguments, and prefer to stubbornly do what you
>> > decided was right ahead of any discussion.
>
> Sigh.  I wasn't going to go there, but....in fact I have already done
> several work items raised specifically by Eli.

That's not my impression.  My impression is that you repeatedly
pronounce having cleared a self-set bar and when people including Eli
point out where you didn't, you make them accountable for setting the
bar.

Unless your plan involved bullshitting everybody including yourself
about the quality of the achieved solution, there is no point in
shouting down those who point out where you don't meet your goals.

If the ultimate transition is to involve history rewriting involving a
change of the existing Git commit ids, and that's the setup you are
aiming for partly in order to get a nice showcase for your repo surgeon,
then any remaining deficiency is going to be permanent.

> I'm a very reasonable person about meeting requirements like that
> which are raised in a genuine attempt to improve the quality of the
> result. It's for sure no one else is going to do them for you.

You'll find that a lot of people have done a lot more work on Emacs than
you did, so it is disingenuous to suggest that there is no alternative
to letting you have your way.  There actually has been a working Git
mirror for quite a few years that was set up (and restarted from scratch
several times in its infancy) and used without your input.  So there
clearly _are_ people who have experience in that area, and it's also
obvious from the exchanges that there are people who have more knowledge
about the kind of labels and references that are in use than you were
able to imagine.

Locking out their feedback might speed up the time until you are able to
declare having finished your task.  But it does not help with you being
on top of it.

> Being reasonable does not, however, mean I will put up with
> obstreperous bullshit.  What I just quoted, from Juanma and Eli both,
> was obstreperous bullshit.  That, I respond to by decreasing my
> willingness to pay attention to the bullshitter.
>
> So let me spell it out: Juanma, if you think you are not being
> listened to, you have only your own bad attitude to blame for that.
> Same goes for you, Eli. After enough pissy, semi-autistic territorial
> grunting I just start tuning all of it out.

There are several perfectly viable solutions that get along without
rewriting the commit history of the existing mirror, by collecting the
respective information in plain files and/or Git labels and/or Git
notes.  Since they work without rewriting, they can be improved and/or
fixed over the course of time.  Consequently, they don't require the
kind of "everything has to be perfect at first try" mind frame that your
preferred solution is built around and that you are sabotaging
confidence in yourself by locking out feedback.

Voting for an "everything has to be perfect at first try" solution
requires a trust in the solution that is hard to achieve when you turn
it into a one-man show in the face of those who are actual permanent and
active contributors to the project.

> Conversely, you can earn my attention and increased willingness to do
> what you want by putting effort into helping with the work.

"to do what you want"?  I don't think that's an accurate
characterization.  Eli does not want to migrate to Git.  He is not
trying to make you "do what he wants" when he points out where your
claims fall flat.  He is helping you doing what _you_ want if he raises
his objections in a timely and detailed manner where you are able to
address them.

The nature of a history rewrite does not make it feasible to address
them once the conversion is done, and you have made abundantly clear
anyway that you only have a limited time window to bother with the
conversion and followup.

If the quality of the conversion will be such that one will have to
revert to auxiliary tools and files created after the conversion to
resolve a sizable number of repository-based questions, then it might be
easier to just continue reusing the existing mirror together with the
auxiliary tools and files one will need anyway.

So if you want Emacs to be a showcase for your toolset and skills, you
better figure in its existing community in your plans to make a
convincing pitch.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]