public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tom Wijsman <TomWij@gentoo.org>
To: wking@tremily.us, gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Signing off patches
Date: Mon, 20 Jan 2014 03:09:14 +0100	[thread overview]
Message-ID: <20140120030914.2f2f7666@TOMWIJ-GENTOO> (raw)
In-Reply-To: <20140119041557.GI29063@odin.tremily.us>

[-- Attachment #1: Type: text/plain, Size: 4738 bytes --]

On Sat, 18 Jan 2014 20:15:57 -0800
"W. Trevor King" <wking@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" <wking@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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2014-01-20  2:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16 13:20 [gentoo-portage-dev] Signing off patches Alexander Berntsen
2014-01-16 16:41 ` Alec Warner
2014-01-16 17:02   ` Alexander Berntsen
2014-01-16 16:45 ` W. Trevor King
2014-01-16 17:05   ` Alexander Berntsen
2014-01-16 17:11     ` W. Trevor King
2014-01-16 17:37       ` Alexander Berntsen
2014-01-16 17:24 ` Jesus Rivero (Neurogeek)
2014-01-16 17:44   ` Alexander Berntsen
2014-01-16 17:57     ` Jesus Rivero (Neurogeek)
2014-01-16 19:54     ` [gentoo-portage-dev] " Duncan
2014-01-16 20:07       ` W. Trevor King
2014-01-16 21:12         ` Alexander Berntsen
2014-01-18  6:44     ` [gentoo-portage-dev] " Mike Frysinger
2014-01-18 15:02       ` Tom Wijsman
2014-01-18 16:43         ` W. Trevor King
2014-01-18 22:57           ` Tom Wijsman
2014-01-18 23:24             ` W. Trevor King
2014-01-19  1:33               ` Tom Wijsman
2014-01-19  4:15                 ` W. Trevor King
2014-01-20  2:09                   ` Tom Wijsman [this message]
2014-01-20  2:32                     ` W. Trevor King
2014-01-21 15:40                       ` Tom Wijsman
2014-01-21 16:51                         ` W. Trevor King
2014-01-21 16:59                           ` Tom Wijsman
2014-01-21 17:20                             ` W. Trevor King
2014-01-21 18:41                               ` Tom Wijsman
2014-01-21 19:18                                 ` W. Trevor King
2014-01-21 19:22                                   ` Tom Wijsman
2014-01-21 19:45                                     ` W. Trevor King
2014-01-19  8:57             ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140120030914.2f2f7666@TOMWIJ-GENTOO \
    --to=tomwij@gentoo.org \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    --cc=wking@tremily.us \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox