git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/9] remote-bzr: trivial cleanups

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Apr 26, 2013, 09:32 UTC
Message-ID
<CALkWK0mRfj1FGYymDrBqQ=d02mhPkevJKr5Ozhgurp8DMhiNjQ@mail.gmail.com>
In-Reply-To
<CAMP44s1RdZ19y8v+_=gwBzq1Tg5v8+TWAYCAVR-ZzNwZ0_m_Ng@mail.gmail.com>
Felipe Contreras wrote:
Show 5 quoted lines
> 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".

> Other people are perfectly fine with them:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?qt=author&q=felipe.contreras

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.
Previous: Ramkumar RamachandraNext: Felipe Contreras
Message 24 of 49 in “remote-helpers: fixes and cleanups”
  1. 0/9 remote-helpers: fixes and cleanupsFelipe Contreras, Apr 25, 2013
  2. 1/9 remote-bzr: trivial cleanupsFelipe Contreras, Apr 25, 2013
  3. Ramkumar RamachandraApr 25, 2013
  4. Felipe ContrerasApr 25, 2013
  5. Thomas RastApr 25, 2013
  6. Felipe ContrerasApr 25, 2013
  7. Junio C HamanoApr 25, 2013
  8. Felipe ContrerasApr 25, 2013
  9. Junio C HamanoApr 25, 2013
  10. Felipe ContrerasApr 25, 2013
  11. Junio C HamanoApr 25, 2013
  12. Felipe ContrerasApr 25, 2013
  13. Junio C HamanoApr 25, 2013
  14. Felipe ContrerasApr 26, 2013
  15. Ramkumar RamachandraApr 26, 2013
  16. Felipe ContrerasApr 26, 2013
  17. Ramkumar RamachandraApr 26, 2013
  18. Felipe ContrerasApr 26, 2013
  19. Ramkumar RamachandraApr 26, 2013
  20. Felipe ContrerasApr 26, 2013
  21. Junio C HamanoApr 26, 2013
  22. Felipe ContrerasApr 26, 2013
  23. Ramkumar RamachandraApr 26, 2013
  24. Ramkumar RamachandraApr 26, 2013
  25. Felipe ContrerasApr 26, 2013
  26. Ramkumar RamachandraApr 26, 2013
  27. Ramkumar RamachandraApr 26, 2013
  28. Felipe ContrerasApr 26, 2013
  29. Ramkumar RamachandraApr 26, 2013
  30. Felipe ContrerasApr 26, 2013
  31. Ramkumar RamachandraApr 26, 2013
  32. Felipe ContrerasApr 26, 2013
  33. Felipe ContrerasApr 26, 2013
  34. Ramkumar RamachandraApr 26, 2013
  35. Felipe ContrerasApr 26, 2013
  36. Stefano LattariniApr 25, 2013
  37. Felipe ContrerasApr 25, 2013
  38. 2/9 remote-hg: remove extra checkFelipe Contreras, Apr 25, 2013
  39. Ramkumar RamachandraApr 25, 2013
  40. Felipe ContrerasApr 25, 2013
  41. 3/9 remote-bzr: fix bad state issueFelipe Contreras, Apr 25, 2013
  42. 4/9 remote-bzr: add support to push URLsFelipe Contreras, Apr 25, 2013
  43. 5/9 remote-hg: use hashlib instead of hg sha1 utilFelipe Contreras, Apr 25, 2013
  44. Ramkumar RamachandraApr 25, 2013
  45. Felipe ContrerasApr 25, 2013
  46. 6/9 remote-bzr: store converted URLFelipe Contreras, Apr 25, 2013
  47. 7/9 remote-hg: use python urlparseFelipe Contreras, Apr 25, 2013
  48. 8/9 remote-bzr: tell bazaar to be quietFelipe Contreras, Apr 25, 2013
  49. 9/9 remote-bzr: strip extra newlineFelipe Contreras, Apr 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.