On Sat, 18 Jan 2014 20:15:57 -0800 "W. Trevor King" <wk...@tremily.us> wrote:
> On Sun, Jan 19, 2014 at 02:33:06AM +0100, Tom Wijsman wrote: > > On Sat, 18 Jan 2014 15:24:59 -0800 > > "W. Trevor King" <wk...@tremily.us> wrote: > > > If it doesn't need to get updated, then it probably already > > > started out explaining the consensus ;). > > > > That is a guess, you can look this up in past patches. > > Sure. Will you? If I want to touch some code, and it looks > confusing, I'll use blame to see who wrote it and whay they were > thinking about. If the commit message is not informative, I usually > give up. I have a hard time imaging folks tracking down the thread > that spawned that patch, assuming such a thread even exists, for each > troublesome line they'd like to touch. It's much easier to summarize > any issues the list resolved (because they're likely the same > questions the new dev is asking) in the commit message, where future > developers can find them. How does this make the consensus written after the patch part of it? The person whom commits can be different than the person whom wrote the patch; and hence, that person commits without writing down consensus. If that person were to write it down, it would change the authorship. Hence you made a guess, because I see pushed commits without consensus. > > > You spend time if you want to spend time and add whoever you feel > > > moved to add. > > > > We discuss whether to make it policy to add involved people. > > But “involved” can be hard to pin down, especially by someone who may > be applying v5 of a patch that hasn't been carefully following the > whole discussion in earlier versions. If this would be formalized, then v5 would include all tags until then. > The Linux kernel docs say [1]: > > If this patch fixes a problem reported by somebody else, consider > adding a Reported-by: tag to credit the reporter for their > contribution. > > Note the “consider” wiggle word. They are a bit more formal about > Reviewed-by, but only because it's signing off on their Reviewer's > statement of oversight. In general, if you're not signing some > statement with the tag, formalizing “involved” is hard. Here I like vapier's approach from the other reply in this sub thread, that is to add it whenever people make the effort of providing the tag; which is an approach the Linux kernel upstream takes as well, if you want to be seen as a contributor you need to provide the tags. > > > If you are submitting v2 of a patch, and feel a desire > > > to credit reviewers / testers with this syntax, I think that's > > > considerate of you. If you are committing someone else's patch to > > > master, and want to record the folks who acked it on the list to > > > distribute responsibility, that's fine too. If you want to use > > > another syntax, or not do any of this at all, it's still fine by > > > me ;). However, if a consistent syntax already exists, I see no > > > reason not to use it when it suits your purpose. > > > > We discuss here whether to make it policy to use the same syntax. > > I don't understand the distinction between “here are some guidelines, > apply as and if you see fit” and “make it a policy to …”. Say you > have a situation like this: When the thread starts with words like "ensure", "exercised", "followed", "should", "proposals" then I rather get the impression that this is rather working towards making it part of policy than some random guidelines; even if these words are not mentioned, it is for us to discuss whether we should make this more than just guidelines. > As I understand it, 6 should be: > > 6a. Everyone gets on with their lives. > > I could see a situation where: > > 6b. Charlie reminds Dan that he could have used the tags. Everyone > gets on with their lives. > > Is there another alternative step 6 implied by the “policy” keyword? > Or is the policy workflow even more different somehow? This discussion is based on that second situation 6b, as I think everyone is fine with 6a; but, some will want this to not become policy, others might want to see this to become policy. Hence this leads to a discussion. At the moment people seem fine with them being used optional, thus I agree with what was said here regarding it is a respectful suggestion to consider; at least nobody has strongly opposed to using them at all. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
