Re: Request to remove Junio C Hamano as the Git Maintainer

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

 



On Tue, Jan 03 2023, demerphq wrote:

> On Sat, 31 Dec 2022 at 19:52, Filip Lipien <aaa@xxxxxxx> wrote:
>>
>> There are more than one million questions on Stackoverflow related to the usage of Git.
>> This is not normal.
>>
>> Git is in its current state not a tool that's made for humans.
>
> Any tool sufficiently advanced to be useful to experts will from time
> to time surprise beginners who lack context knowledge. That is normal.
> Designing tools to be unsurprising for beginners usually just ends up
> limiting, frustrating or surprising the experts.
>
>> It's realistic to assume, that millions of working hours were wasted due to his ignorance of developer experience.
>> The financial damage goes into the billions.
>
> Yeah, business has adopted it wholesale because it loses them
> billions. That makes sense. Not.
>
>>
>> I hereby request the removal of Junio C Hamano 濱野純 as the Git Maintainer.
>
> That is just rude. Having a free meal in a restaurant does not give
> you the right to demand the head-cook steps down because you didn't
> like the way it was laid out on the plate.  Whatever it was you
> intended to achieve with this post, this is not the way to go about
> it.
>
> Normally I would ignore a post like this as trolling, but others have
> engaged, and I wanted to express some support for Junio as I know
> these kind of things can get even the thickest skinned hacker down.
>
> So to Junio: Thank you for your contributions. I give you strength to
> ignore the trolls.  I have stated this previously, but thanks again
> for add --interactive, that is a super useful tool which I use and
> appreciate pretty much every single day.

Yes, thanks Junio!

I agree on the "trolling" front, and just to concede part of that
ill-phrased point: As a long-term user & contributor of git I agree that
there's lots of cases where git's UX is bad.

Some have noted in this thread that it's partially inherent complexity,
that's also true. Any tool supporting a DVCS workflow will probably
always be more complex than a CVCS (although I'd argue that's largely an
illusion, as it just pushes complexity for e.g. conflicts outside of the
system).

But part of it is just that git's UX is crappy in places. Often there's
a good reason (e.g. backwards compatibility), but often there isn't.

Now, is that the fault of Junio or this development community? I don't
think so. I think it would be possible to have a maintainer (e.g. with
some BOFH attitude) that would be unreasonably hostile to user
friendlyness.

But it's really not that, it's just more mundane reasons.

E.g.:

* Much of the interface being organically grown (and some committee
  design would have had its own issues, or never gotten off the
  ground).

  Fixing inconsistencies is possible, but runs into backwards
  compatibility, creating more confusion by change etc.

* Lots of cases where the UX could be improved, even trivially. Some
  places where we could add advise(), or otherwise improve/fix messaging
  come to mind (those almost never impact backwards compatibility). But
  working on all of those requires volunteer time etc.

I'd also like Git's UX improved, and don't want anyone to get the
impression that such changes aren't welcome here.

As someone who's pushed for much of that (from the i18n subsystem, to
various new advise() etc.) my experience is that Junio's been very
receptive to those sort of changes, and helpful in getting them accepted
& released.




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

  Powered by Linux