Re: [PATCH v3 3/5] doc: remove unnecessary rm instances

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

 



Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> 
> > Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@xxxxxxxxx> writes:
> >> >  * helped-by: 17% (1336)
> >> 
> >> I actually think people use this one to say "person X gave a
> >> valuable input in the review discussion", which is exactly the case
> >> here, and that was why I wondered you needed to invent a completely
> >> new one.
> >
> > I think the opposite: "helped-by" encompasses virtually anything...
> 
> But your own stats disagrees with your opinion, so don't invent a
> new thing, period.

Stats don't have opinions.

You and I have had this discussion before, between the status quo:

	die ("could not find author in commit %s",
	     oid_to_hex(&commit->object.oid));

And:

	die("could not find author in commit %s",
		oid_to_hex(&commit->object.oid));

Eventually you yourself updated the documentation to explicitly state
that it's fine to not align the subsequent lines to the opening
parenthesis: f26443da04 (CodingGuidelines: on splitting a long line,
2014-05-02).

It is wrong to demand something that is not in the guidelines,
especially if later on the guidelines might include the very thing
supposedly frowned upon [*].


In this particular case the guideline is not missing, it actually sides
with me:

  You can also create your own tag or use one that's in common usage
  such as "Thanks-to:", "Based-on-patch-by:", or "Mentored-by:".

If you want to forbid certain commit trailers--or limit the allowed
trailers to a sanctioned list--then update the guidelines first to
reflect that.


But I don't think it makes sense to do that, because commit
trailers--just like words, and hundreds of other things--follow a Zipf's
law, where the 10th most common word appears around 1/10th of the time.

If you graph the frequency of commit trailers vs. a Zipf distrubtion
with a 80:20 rule, it follows it almost perfectly [1]. That means 80% of the
commit trailers appear 20% of the time.

My script can calculate any quantile and for example found out that just
two lines--Acked-by and Reviewed-by--acound for 47% of all the lines.
They are the top 1%.

The top 10% is constituted by 16 lines, and the top 25% are 33.

The median is 1 appearance. That means of the 155 unique lines, half of
them have just 1 appearance, in fact, more than half: 100 of them.

For more details see the mail I just sent [2].

Unsurprisingly commit trailer lines follow the same pattern as income
distribution and musical bands popularity; the rich get richer.

As much as you might despise the poorest among commit trailers, they are
the majority, and they will keep being the majority.

Cheers.

[1] https://i.imgur.com/1wQgSlP.png
[2] https://lore.kernel.org/git/60ad75ac7ffca_2ae08208b@natae.notmuch/

[Footnote]

 * Granted, my patch back then did not match the new guideline
   perfectly, but also it wasn't wrong for reasons stated then.

-- 
Felipe Contreras



[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