Re: The master branch rename, and avoiding another v1.6.0 git-foo fiasco

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

 



I couldn't agree more. We really need to be warning users several versions in advance,
and I mean months or even years. I don't wan't to come up with a number, but I would
guess that maybe 85 %, (or even 95 % ?) of the world-wide Git user base is unaware that any discussion
on that topic ever took place.

Brian mentioned that some people voicing their concern on the list did not abide by the code of conduct.
There was also very vocal disagreement voiced in the Git-for-Windows GitHub project before the
discussion reached the mailing list, of which a lot was also considered to not abide by that project's
code of conduct. While I agree that discussion should be done with respect, and some people that
are driven to react to such important changes might not be aware of any code of conduct they should
follow, because they don't participate in the "day-to-day" life of the project, just the fact that they even
care enough to voice their disagreement should be a big red flag in terms of how this change should be done,
in my opinion.

I had avoided commenting on this whole subject, but the main point you are bringing,
that such a change, if done, should be made with great care to our user base and a lot
more warning, is a very important one.

Thanks for bringing it up.

Philippe.
Not just Git-for-Windows but there is also numerous reddit threads expressing both disbelief that this would even be considered and anger at how it might hurt various workflows as well as issues on gitlab and gitea which were closed as soon as any discussion started normally citing the code of conduct even if no real violations occurred. The one exception was gitlab where it was closed, reopened and allowed for long discussion before being closed again. In the gitlab one certainly user issues were brought up, even if primarily by me, before being discarded as those for the change purely on emotional reasoning. What I find sort of interesting is the constant claim that its a direct reference to slavery also without any proof.

Overall this is a massive change that will affect users, documentation, and classes for years to come if made and should only be made with clear, articulatable, realizable benefits such as the SHA1 change. Breaking years of documentation and books without that clear and obvious benefit is a disservice to users and likely to cause significant harm in the short and long term and a clear tenant of why few projects change things just to change things. The risk of unintended effects is too great once something is well recognized as python and others have found out trying to remove what their perceived as problematic language leading to multiple incompatible versions.

Whinis




[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