Re: [PATCH v1 07/25] contrib: remove 'git-jump'

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

 



Jeff King wrote:
> On Thu, May 08, 2014 at 09:12:36PM -0500, Felipe Contreras wrote:
> 
> > Jeff King wrote:
> > > On Thu, May 08, 2014 at 07:58:18PM -0500, Felipe Contreras wrote:
> > > 
> > > > No activity, no tests.
> > > 
> > > Like diff-highlight, I don't think "no activity" is a useful indicator.
> > > I use this daily, and several people have commented off-list to me that
> > > they use it, too.
> > 
> > Add tests then.
> 
> I don't really feel like spending time on it right now. There are better
> uses of my time.
> 
> I thought on this for a while before responding. Am I simply being lazy
> and a bad programmer not to write tests?

It depends how you define "lazy". Some people think laziness is a good
quality in a programmer.

> Am I propagating a double standard where I do not have to write tests?

Only if you are imposing those standards onto others. It doesn't seem
like you are doing it, but Junio is.

> Here's the conclusion I came to. Sure, some tests are better than no
> tests. But the code works, empirically; I use it every day. It is not
> changing, so the chances of regression are low. I can spend an hour
> writing tests that demonstrate what I already know. I can even spend
> several hours trying to come up with torture cases that might
> demonstrate a potential failure that nobody in the real world
> experiences. But why?
> 
> Because YOU, who have no interest whatsoever in either this script or
> diff-highlight, have decided to demand that I write them, or spend time
> spinning the code into its own repository. Sorry, but I have more useful
> things to do than appease you.

Nobody is forcing you to do anything. If you don't want to write tests,
move the code out of git.git, there's hundreads of tools out there
out-of-tree, and they don't have tests either.

The purpose of contrib is very clearly defined in contrib/README, and
nowhere does it say that tools belong there if Peff uses them. You need
more than that to belong in contrib.

> I have no problem with cleaning up cruft in contrib that is broken and
> nobody uses; it is a potential hazard and time-waster for people who
> look in that directory. But when people say "no, this is maintained, I
> use it, and it works", I really don't see the point in you arguing with
> them. Nobody benefits.

Then you need to talk to Junio, because it really doesn't make sense to
have such abismally different double standards.

> > It this is never meant to move to the core, then it should go
> > out-of-tree anyway.
> 
> "should" in your opinion. I know, I know, you will quote contrib/README
> at me.  If Junio wants to enforce "contrib is only for things which are
> meant to graduate" in his tree, then I will abide by that and maintain
> these scripts out-of-tree. But I would rather see an actual decision
> from the maintainer on that, and not an 8-year-old README which clearly
> has not been followed in the intervening years.

Exactly. Junio has to decide what is the standard for contrib, and what
is the standard for the core. And right now we have incredibly crappy
and unmaintained tools in contrib that nobody uses, as well as
production ready which are in better shape than some tools in the core.

This huge discrepancy should not be.

> And speaking of wasted time, I do not plan on responding further to you
> in this thread. I am telling you ahead of time that this is the case,
> because elsewhere[1] I saw you complaining that Junio did not respond to
> your emails,

Respond or not, the issue about the discrepancy of standards remains.

> which you seemed to think was because he cannot admit that he was
> wrong.

Why he didn't do it is irrelevant, the fact is that he didn't do it.
Other people wonder what is the reponse to these questions. If he
doesn't do it, that's on him.

-- 
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]