[gentoo-portage-dev] Signing off patches

[gentoo-portage-dev] Signing off patches

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

We have quite a few dedicated developers now. To ensure that good
taste is exercised, and that best practices are followed, patches
should be signed.

My proposals:
Signed-off-by: Wrote (a substantial portion of) the patch
Reviewed-by: Reviewed the patch thoroughly
Tested-by:  Tested the patch thoroughly
Acked-by: Approved the concept but did not read the patch in detail
(typically used by the maintainer of a specific portion, or our lead)
Suggested-by: Designed the implementation
Reported-by: Reported the bug/feature request

These suggestions all stem from the Linux project.
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLX3JsACgkQRtClrXBQc7VhEQD9FKmFbyf9zxl+hLylkhQN/kv6
o3DSM4xBr9fH4+1eokYA/3MbFLtDpli311d6ZqGD17kGLfz5wNj+5kPRATbiC256
=cJNe
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Signing off patches

[Alec Warner]

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

On Thu, Jan 16, 2014 at 5:20 AM, Alexander Berntsen <alexander@plaimi.net>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> We have quite a few dedicated developers now. To ensure that good
> taste is exercised, and that best practices are followed, patches
> should be signed.
>

I'm confused, are you proposing all patches have all of these fields? Or we
should simply cherry-pick the fields we think are useful?


>
> My proposals:
> Signed-off-by: Wrote (a substantial portion of) the patch
> Reviewed-by: Reviewed the patch thoroughly
> Tested-by:  Tested the patch thoroughly
> Acked-by: Approved the concept but did not read the patch in detail
> (typically used by the maintainer of a specific portion, or our lead)
> Suggested-by: Designed the implementation
> Reported-by: Reported the bug/feature request
>
> These suggestions all stem from the Linux project.
> - --
> Alexander
> alexander@plaimi.net
> http://plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlLX3JsACgkQRtClrXBQc7VhEQD9FKmFbyf9zxl+hLylkhQN/kv6
> o3DSM4xBr9fH4+1eokYA/3MbFLtDpli311d6ZqGD17kGLfz5wNj+5kPRATbiC256
> =cJNe
> -----END PGP SIGNATURE-----
>
>

[-- Attachment #2: Type: text/html, Size: 1972 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/14 17:41, Alec Warner wrote:
>> I'm confused, are you proposing all patches have all of these
>> fields? Or we should simply cherry-pick the fields we think are
>> useful?
Nearly all patches should have Signed-off-by. The others are situational.

We should strive to always have an Acked-by from the team lead.
Reviewed-by should be present on all non-trivial patches.
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLYEJEACgkQRtClrXBQc7XuQgD/dGEgjCpW+CgqOYvgkwK2OaU6
+auzTl4uAwhhZnM/7ukA/0+E5g9jZd/MtDMLL5qyFnTwMJqRZmPVyGj6N/GVoz7U
=lVht
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Thu, Jan 16, 2014 at 02:20:27PM +0100, Alexander Berntsen wrote:
> Signed-off-by: Wrote (a substantial portion of) the patch
> …
> These suggestions all stem from the Linux project.

I love Signed-off-by, but in all projects where I've seen it used it
means the signer is agreeing to some form of a Developer's Certificate
of Origin [1].  Without such a DCO, I think the usual commit author is
sufficient.  Co-authors can be listed with:

  Assisted-by:

or something.

Two cents from an outsider,
Trevor

[1]: https://www.kernel.org/doc/Documentation/SubmittingPatches

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/14 17:45, W. Trevor King wrote:
> I love Signed-off-by, but in all projects where I've seen it used
> it means the signer is agreeing to some form of a Developer's 
> Certificate of Origin [1].  Without such a DCO, I think the usual 
> commit author is sufficient.
I agree. However, it might be prudent to introduce a DCO. After all,
copyright is assigned to the Gentoo Foundation.

> Co-authors can be listed with Assisted-by:
Sure.
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLYEW4ACgkQRtClrXBQc7WMaAD6Ar5ut5Xs6i1Z3XISV0xXdHQg
F/TCNHyJVB6ORe1ZsCIA/0hesVEs4DB0QnIcRIthUniQfiBUG8qn+L9EvWmrsq8r
=rfUr
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Thu, Jan 16, 2014 at 06:05:50PM +0100, Alexander Berntsen wrote:
> On 16/01/14 17:45, W. Trevor King wrote:
> > I love Signed-off-by, but in all projects where I've seen it used
> > it means the signer is agreeing to some form of a Developer's
> > Certificate of Origin [1].  Without such a DCO, I think the usual
> > commit author is sufficient.
>
> I agree. However, it might be prudent to introduce a DCO. After all,
> copyright is assigned to the Gentoo Foundation.

If you add a DCO (and I'd certainly think that would be prudent if you
require copyright assignment), then you probably don't need a separate
Assisted-by.  Anyone with enough co-authorship to matter will be using
a Signed-off-by.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/14 18:11, W. Trevor King wrote:
> If you add a DCO, then you probably don't need a separate 
> Assisted-by.  Anyone with enough co-authorship to matter will be
> using a Signed-off-by.
I agree.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLYGMAACgkQRtClrXBQc7XBTQD/a6vdlJaU8KZDSRV5hcrijx8N
+8Ds5oA7sImXBw+xVq4BAK2FdQSqxit9hGpgMSFC8t9VGx6sYcFkUq+HTH+eui5b
=QaiH
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Signing off patches

[Jesus Rivero (Neurogeek)]

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

On Thu, Jan 16, 2014 at 8:20 AM, Alexander Berntsen <alexander@plaimi.net>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> We have quite a few dedicated developers now. To ensure that good
> taste is exercised, and that best practices are followed, patches
> should be signed.
>
> My proposals:
> Signed-off-by: Wrote (a substantial portion of) the patch
> Reviewed-by: Reviewed the patch thoroughly
> Tested-by:  Tested the patch thoroughly
> Acked-by: Approved the concept but did not read the patch in detail
> (typically used by the maintainer of a specific portion, or our lead)
> Suggested-by: Designed the implementation
> Reported-by: Reported the bug/feature request
>
> These suggestions all stem from the Linux project.
> - --
> Alexander
> alexander@plaimi.net
> http://plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlLX3JsACgkQRtClrXBQc7VhEQD9FKmFbyf9zxl+hLylkhQN/kv6
> o3DSM4xBr9fH4+1eokYA/3MbFLtDpli311d6ZqGD17kGLfz5wNj+5kPRATbiC256
> =cJNe
> -----END PGP SIGNATURE-----
>
>
So, how would this work with emails to this list, exactly? An email should
be sent any time one of those fields is changed?
I think that would be overkill in our specific context. That makes much
more sense if we had a CR tool, where changes to a patch could be seen in
one place, and email passes to be only a 'notification tool'.

Do you have a more detailed plan on how would this work?

Cheers,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer

[-- Attachment #2: Type: text/html, Size: 2357 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote:
> So, how would this work with emails to this list, exactly? An
> email should be sent any time one of those fields is changed?
That's not necessary, in my opinion. We already send emails, "looks OK
to me" and similar. And most patches don't really need more than one
review and an ACK by the lead.

> Do you have a more detailed plan on how would this work?
Not really. We're small enough to do this organically and on a
per-case basis.

But basically, if someone authors a non-trivial patch, that person
should *never* push themselves. Whoever reviews it should push it,
adding the Reviewed-by field. The reviewer should also get an ACK by
the team lead (via IRC or whatever) and add that to the commit before
pushing.

In a bigger project (or with a team lead with a lot of free time...),
I would argue that the reviewer should send the new commit, with the
Reviewed-by field added, to the team lead, which then adds the
Acked-by field themselves, before pushing. I'm not convinced the
benefits of this extra step outweighs the drawback in the overhead of
this small community of ours.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLYGpkACgkQRtClrXBQc7WA4AEAmghIHMkNxiqJ79CONZzs/k/u
t0QoASddzlSruejiVaQA+QFOdbgMaA59hf9DInPAgpG7Kc6fbFENgkZn4jEY9NAq
=CrCK
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Signing off patches

[Jesus Rivero (Neurogeek)]

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

On Thu, Jan 16, 2014 at 12:44 PM, Alexander Berntsen
<alexander@plaimi.net>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote:
> > So, how would this work with emails to this list, exactly? An
> > email should be sent any time one of those fields is changed?
> That's not necessary, in my opinion. We already send emails, "looks OK
> to me" and similar. And most patches don't really need more than one
> review and an ACK by the lead.
>
> > Do you have a more detailed plan on how would this work?
> Not really. We're small enough to do this organically and on a
> per-case basis.
>
> But basically, if someone authors a non-trivial patch, that person
> should *never* push themselves. Whoever reviews it should push it,
> adding the Reviewed-by field. The reviewer should also get an ACK by
> the team lead (via IRC or whatever) and add that to the commit before
> pushing.
>

Gotcha!, that makes sense to me.

>
> In a bigger project (or with a team lead with a lot of free time...),
> I would argue that the reviewer should send the new commit, with the
> Reviewed-by field added, to the team lead, which then adds the
> Acked-by field themselves, before pushing. I'm not convinced the
> benefits of this extra step outweighs the drawback in the overhead of
> this small community of ours.
>
> - --
> Alexander
> alexander@plaimi.net
> http://plaimi.net/~alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iF4EAREIAAYFAlLYGpkACgkQRtClrXBQc7WA4AEAmghIHMkNxiqJ79CONZzs/k/u
> t0QoASddzlSruejiVaQA+QFOdbgMaA59hf9DInPAgpG7Kc6fbFENgkZn4jEY9NAq
> =CrCK
> -----END PGP SIGNATURE-----
>
>
Thanks,

-- 
Jesus Rivero (Neurogeek)
Gentoo Developer

[-- Attachment #2: Type: text/html, Size: 2686 bytes --]

[gentoo-portage-dev] Re: Signing off patches

[Duncan]

Alexander Berntsen posted on Thu, 16 Jan 2014 18:44:57 +0100 as excerpted:

> On 16/01/14 18:24, Jesus Rivero (Neurogeek) wrote:
>> So, how would this work with emails to this list, exactly? An email
>> should be sent any time one of those fields is changed?
> That's not necessary, in my opinion. We already send emails, "looks OK
> to me" and similar. And most patches don't really need more than one
> review and an ACK by the lead.
> 
>> Do you have a more detailed plan on how would this work?
> Not really. We're small enough to do this organically and on a per-case
> basis.
> 
> But basically, if someone authors a non-trivial patch, that person
> should *never* push themselves. Whoever reviews it should push it,
> adding the Reviewed-by field. The reviewer should also get an ACK by the
> team lead (via IRC or whatever) and add that to the commit before
> pushing.

On the btrfs list, comments on patches often have wording to the effect:

"After taking care of those issues, you can add my reviewed-by."

"Looks fine to me, reviewed-by" (or acked-by if more appropriate).

If it's a preliminary review/ack, meanwhile, those will be missing.  
Also, presumably (I don't do IRC) people can get acks (or reviews if 
there has been more detailed correspondence previously) on IRC.

Obviously reported-by doesn't need explicit permission, and tested-by 
(from a reporter's angle) the same, if it is said to work with the 
patch.  Tested-by done by folks running the regression tests, etc, 
obviously get explicit permission in the form of their reports on those 
tests.

If there were issues and there's a v2, v3, etc, these include the various 
bylines as part of the revision.  If the patch is considered ready to go 
as-is, they'll be added at the final commit, which can be made by the 
author if they have commit access, or a dev with access if not.

And one final note: A signed-off-by is a useful indicator of a patch that 
an author considers ready to go, pending review, etc.  Lack of that (from 
a seasoned submitter who is familiar with the process) can be an 
indication that the author believes the patch is or may be preliminary, 
and they're not yet ready for integration-tree inclusion or final review, 
tho they usually say as much in the patch description as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-portage-dev] Re: Signing off patches

[W. Trevor King]

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

On Thu, Jan 16, 2014 at 07:54:57PM +0000, Duncan wrote:
> And one final note: A signed-off-by is a useful indicator of a patch that 
> an author considers ready to go, pending review, etc.  Lack of that (from 
> a seasoned submitter who is familiar with the process) can be an 
> indication that the author believes the patch is or may be preliminary, 
> and they're not yet ready for integration-tree inclusion or final review, 
> tho they usually say as much in the patch description as well.

You can also use:

  $ git format-patch --subject-prefix RFC …

to mark preliminary patches with [RFC] tags in the subject.  It also
works with versions:

  $ git format-patch --subject-prefix RFC -v2 …

will generate [RFC v2] tags.  Once you think it's mergable, drop the
--subject-prefix to get [PATCH] tags.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Re: Signing off patches

[Alexander Berntsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/01/14 21:07, W. Trevor King wrote:
>   $ git format-patch --subject-prefix RFC …
>   $ git format-patch --subject-prefix RFC -v2 …
We use send-email. The --subject-prefix option exists there as well.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLYS0YACgkQRtClrXBQc7W2EgD9HxoPigVOy+trtpffaA3ozNoI
bpr5vagGK/WTmaZJ9TYA/0Plqidt07NT8XmmCPGPCbrydKSiMfXYOLblLVlSPBVP
=zWxk
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Signing off patches

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 617 bytes --]

On Thursday 16 January 2014 12:44:57 Alexander Berntsen wrote:
> But basically, if someone authors a non-trivial patch, that person
> should *never* push themselves. Whoever reviews it should push it,
> adding the Reviewed-by field. The reviewer should also get an ACK by
> the team lead (via IRC or whatever) and add that to the commit before
> pushing.

err, what ?  that level of process really doesn't make sense here.  the 
project isn't large enough or have enough active people to require it.

any dev with commit access is trusted to do the right thing and to shepherd 
their work through.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

On Sat, 18 Jan 2014 01:44:46 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> On Thursday 16 January 2014 12:44:57 Alexander Berntsen wrote:
> > But basically, if someone authors a non-trivial patch, that person
> > should *never* push themselves. Whoever reviews it should push it,
> > adding the Reviewed-by field. The reviewer should also get an ACK by
> > the team lead (via IRC or whatever) and add that to the commit
> > before pushing.
> 
> err, what ?  that level of process really doesn't make sense here.
> the project isn't large enough or have enough active people to
> require it.
> 
> any dev with commit access is trusted to do the right thing and to
> shepherd their work through.
> -mike

Yes, adding these annotations could cause more overhead than necessary;
because either a patch has been reviewed here on the ML or the patch is
too trivial for review. In the former case you can find whom agreed on
the list (and also relevant discussion), in the latter case there was
no need for agreement.

It feels like spending time on adding all these fields the correct way
would cost more than the benefit it would cause; it can be good taste
and best practice, but if it doesn't actually gain us something then it
is doubtful whether we should spend effort on that.

Commits already have an author and committer listed, if we just keep
those fields correct; then we already have 1) the person whom written
the patch (could be bug reporter, could be one of us) and 2) the person
whom reviewed / acked (must do before committing) and added the patch.

Commenting on them one by one:

 - Signed-off-by: Wrote (a substantial portion of) the patch

   As it is rarely written by multiple authors, the author field
   suffices.

 - Reviewed-by: Reviewed the patch thoroughly

   What extra information does this tell us? This can be seen on ML.

 - Tested-by:  Tested the patch thoroughly

   This might make sense for the most important / big patches, but the
   occasional patch I'm in doubt about; you can't foresee everything in
   your testing anyway and it could be that errors are caught only
   after the patch has been committed.

   For an upstream project like the kernel such patch getting accepted
   into Git is critical, as a lot of kernel developers run from Git;
   however, downstream here at Portage the story is quite different.

 - Acked-by: Approved the concept but did not read the patch in detail
   (typically used by the maintainer of a specific portion, or our lead)

   It sounds odd to acknowledge the patch but not read it. I think
   Acked-by and/or Reviewed-by reflect the committer that is listed.

 - Suggested-by: Designed the implementation

   This would be rather rarely used; and when we need to use it, we
   probably forget this annotation exist.

 - Reported-by: Reported the bug/feature request

   This is occasionally mentioned in the commit message.

We can however add these out of respect for the people involved; the
alternative is to add them to the commit message, it kind of depends
on how (in)formal we want to deal with this. The advantage of using
annotations here is that you can quickly summarize ones involvement:

eg. Person X has reported X bugs, reviewed Y patches, ...

It feels like a bad practice, good taste thing for a smaller project.

As a final remark I'd like to suggest to keep matters like review on the
ML as much as possible; if we do too much on IRC, we'll lose track of
things like "Why is your patch not the one you have send to the ML?".

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Sat, Jan 18, 2014 at 04:02:02PM +0100, Tom Wijsman wrote:
>  - Reviewed-by: Reviewed the patch thoroughly
> 
>    What extra information does this tell us? This can be seen on ML.

I think the idea is that you shouldn't need to refer to an external
resource like the mailing list to understand the idea behind the
patch, or the amount of review it received.  The body of the commit
message should summarize the consensus reached on the mailing list,
and these tags are basically standardized thank-you notes crediting
non-authors who were involved in that process.  They don't have to go
on every patch, but if you want to mention somebody:

  Reviewed-by: Random J Developer <random@developer.example.org>
  Reviewed-by: Other R Developer <other@developer.example.org>

at the end of the commit message is easier to write and read than:

  This patch was reviewed Random J Developer
  <random@developer.example.org> and Other R Developer
  <other@developer.example.org>.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

On Sat, 18 Jan 2014 08:43:12 -0800
"W. Trevor King" <wking@tremily.us> wrote:

> On Sat, Jan 18, 2014 at 04:02:02PM +0100, Tom Wijsman wrote:
> I think the idea is that you shouldn't need to refer to an external
> resource like the mailing list to understand the idea behind the
> patch,

Either someone cares about the background of a patch or he/she doesn't.

"The idea" is not documented by these annotations, hence if one wants to
know the reasoning behind the certain way it is implemented he/she will
have to go to the mailing list to know that. That is if the existing
comments / commit message were insufficient for what one wonders about.

> or the amount of review it received.

The amount of review is a statistic; as there is no requirement for a
minimal amount of review(er)s, knowing that amount brings us no gain.

> The body of the commit message should summarize the consensus reached
> on the mailing list,

That message is written as part of the patch that is reviewed; it
rarely gets updated with the consensus, unless we suggest / require
people to do that. However, similar to vapier's response, I'd think
introducing such processes feel like unnecessary efforts.

> and these tags are basically standardized thank-you notes crediting
> non-authors who were involved in that process.  They don't have to go
> on every patch, but if you want to mention somebody:
> 
>   Reviewed-by: Random J Developer <random@developer.example.org>
>   Reviewed-by: Other R Developer <other@developer.example.org>
> 
> at the end of the commit message is easier to write and read than:
> 
>   This patch was reviewed Random J Developer
>   <random@developer.example.org> and Other R Developer
>   <other@developer.example.org>.

Exactly: Do we want to spend time on this or not? Do we add everyone
involved? Or do we just add people whom are not on the Portage team?

People in the team can be expected to be respectful and thankful, thus
I prefer the latter effort (non-Portage team only) if possible. 

Unless we intend to introduce this for statistics, although I think
that prior annotation history missing as well as people that will
casually forgot to add these annotations will make the statistics a
misrepresentation. At least as long as humans instead of a system add
these annotations, it be more nice to have a review system that adds
these for us; but well, that would be over-engineering for Portage...

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Sat, Jan 18, 2014 at 11:57:38PM +0100, Tom Wijsman wrote:
> On Sat, 18 Jan 2014 08:43:12 -0800 Trevor King wrote:
> > The body of the commit message should summarize the consensus
> > reached on the mailing list,
> 
> That message is written as part of the patch that is reviewed; it
> rarely gets updated with the consensus, unless we suggest / require
> people to do that. However, similar to vapier's response, I'd think
> introducing such processes feel like unnecessary efforts.

If it doesn't need to get updated, then it probably already started
out explaining the consensus ;).

> > and these tags are basically standardized thank-you notes crediting
> > non-authors who were involved in that process.  They don't have to go
> > on every patch, but if you want to mention somebody:
> > 
> >   Reviewed-by: Random J Developer <random@developer.example.org>
> >   Reviewed-by: Other R Developer <other@developer.example.org>
> > 
> > at the end of the commit message is easier to write and read than:
> > 
> >   This patch was reviewed Random J Developer
> >   <random@developer.example.org> and Other R Developer
> >   <other@developer.example.org>.
> 
> Exactly: Do we want to spend time on this or not? Do we add everyone
> involved? Or do we just add people whom are not on the Portage team?

You spend time if you want to spend time and add whoever you feel
moved to add.  I think the spirit of Alexander's original proposal [1]
was “here is a common syntax for crediting collaborators, we might
want to use it” not “ye non-conformers will be hounded unto the ends
of the Earth”.  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.

> Unless we intend to introduce this for statistics, although I think
> that prior annotation history missing as well as people that will
> casually forgot to add these annotations will make the statistics a
> misrepresentation.

I agree that statistics based on these tags are not meaningful.  

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.linux.gentoo.portage.devel/3948

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

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.

> 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.

> I think the spirit of Alexander's original proposal [1]
> was “here is a common syntax for crediting collaborators, we might
> want to use it” not “ye non-conformers will be hounded unto the ends
> of the Earth”.

Alexander is clear that best practices could be followed and that it is
a proposal, note the use of the particular words "should be"; discussing
spirits is more appropriate in another place than this mailing list.

> 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.

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

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.

> > 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.  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.

> > 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:

  1. Alice submits a bug-report to bugs.g.o.
  2. Bob codes up a Portage patch and sends it to the list.
  3. Charlie responds to Bob's patch on the list with "Reviewed-by".
  4. Dan responds to Bob's patch on the list with "Reviewed-by", and
     asks for any opposition.

     … time passes, and nobody speaks up …

  5. Dan applies Bob's patch to the master branch, but neglects:

       Submitted-by: Alice <a@example.net>
       Reviewed-by: Charlie <c@example.net>
       Reviewed-by: Dan <d@example.net>

  6. ?

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?

Cheers,
Trevor

[1]: https://www.kernel.org/doc/Documentation/SubmittingPatches

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Mon, Jan 20, 2014 at 03:09:14AM +0100, Tom Wijsman wrote:
> On Sat, 18 Jan 2014 20:15:57 -0800 W. Trevor King 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 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.

If the initial submission does not express the consensus, you can
either ask for a resubmission that does, or say “Alice, is it ok if I
change your commit message to read ‘…’? when I commit it?”.

> Hence you made a guess, because I see pushed commits without
> consensus.

No policy/suggestion/goal is going to be followed 100% of the time.
If most commits, especially those that were contentious enough to go
through a few rounds of revision, have a commit message with a good
summary, then the future developer using blame has good odds of
finding something useful.  I think that's a good goal to shoot for,
even if you don't hit it all the time.

Even if you only consider the present, improving your commit message
to address tricky implementation details or unclear motivation before
submitting the next revision on a patch series will help reviewers
understand your patch better in the first place.

> 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.

Sounds fair to me.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

On Sun, 19 Jan 2014 18:32:35 -0800
"W. Trevor King" <wking@tremily.us> wrote:

> If the initial submission does not express the consensus, you can
> either ask for a resubmission that does, or say “Alice, is it ok if I
> change your commit message to read ‘…’? when I commit it?”.

This assumes the committer would ask that, which barely happens.

Also, history rewriting is not acceptable as far as I know...

> No policy/suggestion/goal is going to be followed 100% of the time.

This way, it seems preferable to use the mailing list when blaming.

> If most commits, especially those that were contentious enough to go
> through a few rounds of revision, have a commit message with a good
> summary, then the future developer using blame has good odds of
> finding something useful.  I think that's a good goal to shoot for,
> even if you don't hit it all the time.

The only realistic way to obtain this is to make it policy, or at
least make it checked as part of the review process; now neither
appears present, hence using blame has good odds of something useless.

> Even if you only consider the present, improving your commit message
> to address tricky implementation details or unclear motivation before
> submitting the next revision on a patch series will help reviewers
> understand your patch better in the first place.

+1

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote:
> On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote:
> > If the initial submission does not express the consensus, you can
> > either ask for a resubmission that does, or say “Alice, is it ok
> > if I change your commit message to read ‘…’? when I commit it?”.
> 
> This assumes the committer would ask that, which barely happens.

If neither the committer nor the author feel like checking for this,
it's probably not going to happen ;).

> Also, history rewriting is not acceptable as far as I know...

It's not rewriting history if the patch hasn't been pushed to a stable
branch yet.  When you commit the patch, adjusting it in ways that the
author has agreed to shouldn't count as “rewriting history”.  It's
only rewriting after you've pushed the original patch into a stable
branch.

> > No policy/suggestion/goal is going to be followed 100% of the time.
> 
> This way, it seems preferable to use the mailing list when blaming.

Unless some of the discussion happened on IRC.  There are several
possible channels for patch discussion, but only one commit message
per patch.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

On Tue, 21 Jan 2014 08:51:14 -0800
"W. Trevor King" <wking@tremily.us> wrote:

> On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote:
> > On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote:
> > > If the initial submission does not express the consensus, you can
> > > either ask for a resubmission that does, or say “Alice, is it ok
> > > if I change your commit message to read ‘…’? when I commit it?”.
> > 
> > This assumes the committer would ask that, which barely happens.
> 
> If neither the committer nor the author feel like checking for this,
> it's probably not going to happen ;).
> 
> > Also, history rewriting is not acceptable as far as I know...
> 
> It's not rewriting history if the patch hasn't been pushed to a stable
> branch yet.  When you commit the patch, adjusting it in ways that the
> author has agreed to shouldn't count as “rewriting history”.  It's
> only rewriting after you've pushed the original patch into a stable
> branch.
> 
> > > No policy/suggestion/goal is going to be followed 100% of the
> > > time.
> > 
> > This way, it seems preferable to use the mailing list when blaming.
> 
> Unless some of the discussion happened on IRC.  There are several
> possible channels for patch discussion, but only one commit message
> per patch.

Exactly, without knowledge codification all that will continue to be
a "feel like", "probably not", "shouldn't", "unless some".

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Tue, Jan 21, 2014 at 05:59:54PM +0100, Tom Wijsman wrote:
> On Tue, 21 Jan 2014 08:51:14 -0800 W. Trevor King wrote:
> > On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote:
> > > On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote:
> > > > No policy/suggestion/goal is going to be followed 100% of the
> > > > time.
> > > 
> > > This way, it seems preferable to use the mailing list when
> > > blaming.
> > 
> > Unless some of the discussion happened on IRC.  There are several
> > possible channels for patch discussion, but only one commit
> > message per patch.
> 
> Exactly, without knowledge codification all that will continue to be
> a "feel like", "probably not", "shouldn't", "unless some".

I don't see that as a problem.  I guess I just have more faith that
current devs will put in a reasonable best-effort without codification
beyond “here are some conventions you may want to use”, and that
future devs will be competent enough to still be productive in the
face of unhelpful commit messages.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

On Tue, 21 Jan 2014 09:20:04 -0800
"W. Trevor King" <wking@tremily.us> wrote:

> On Tue, Jan 21, 2014 at 05:59:54PM +0100, Tom Wijsman wrote:
> > On Tue, 21 Jan 2014 08:51:14 -0800 W. Trevor King wrote:
> > > On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote:
> > > > On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote:
> > > > > No policy/suggestion/goal is going to be followed 100% of the
> > > > > time.
> > > > 
> > > > This way, it seems preferable to use the mailing list when
> > > > blaming.
> > > 
> > > Unless some of the discussion happened on IRC.  There are several
> > > possible channels for patch discussion, but only one commit
> > > message per patch.
> > 
> > Exactly, without knowledge codification all that will continue to be
> > a "feel like", "probably not", "shouldn't", "unless some".
> 
> I don't see that as a problem.  I guess I just have more faith that
> current devs will put in a reasonable best-effort without codification
> beyond “here are some conventions you may want to use”, and that
> future devs will be competent enough to still be productive in the
> face of unhelpful commit messages.

If they are just mentioned at random all the time, perhaps half of them
get remembered or so; the half of what is remembered gets given through
to the next generation of future devs, this up to the point that it
would have been a better idea to write this down than to have faith.

It is a competence that's far from becoming a core competence that way.

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Tue, Jan 21, 2014 at 07:41:21PM +0100, Tom Wijsman wrote:
> On Tue, 21 Jan 2014 09:20:04 -0800 W. Trevor King wrote:
> > On Tue, Jan 21, 2014 at 05:59:54PM +0100, Tom Wijsman wrote:
> > > On Tue, 21 Jan 2014 08:51:14 -0800 W. Trevor King wrote:
> > > > On Tue, Jan 21, 2014 at 04:40:19PM +0100, Tom Wijsman wrote:
> > > > > On Sun, 19 Jan 2014 18:32:35 -0800 W. Trevor King wrote:
> > > > > > No policy/suggestion/goal is going to be followed 100% of
> > > > > > the time.
> > > > > 
> > > > > This way, it seems preferable to use the mailing list when
> > > > > blaming.
> > > > 
> > > > Unless some of the discussion happened on IRC.  There are
> > > > several possible channels for patch discussion, but only one
> > > > commit message per patch.
> > > 
> > > Exactly, without knowledge codification all that will continue
> > > to be a "feel like", "probably not", "shouldn't", "unless some".
> > 
> > I don't see that as a problem.  I guess I just have more faith
> > that current devs will put in a reasonable best-effort without
> > codification beyond “here are some conventions you may want to
> > use”, and that future devs will be competent enough to still be
> > productive in the face of unhelpful commit messages.
> 
> If they are just mentioned at random all the time, perhaps half of
> them get remembered or so; the half of what is remembered gets given
> through to the next generation of future devs, this up to the point
> that it would have been a better idea to write this down than to
> have faith.

I'm all for recording suggested conventions in DEVELOPING, but I don't
think it's worth the trouble to over-specify the conditions under
which each tag should be used, or to lay out consequences for cases
where they're forgotten.  The faith part is trusting devs to
understand and apply the written suggestions, not in determining what
the suggestions are.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Tom Wijsman]

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

On Tue, 21 Jan 2014 11:18:39 -0800
"W. Trevor King" <wking@tremily.us> wrote:

> I'm all for recording suggested conventions in DEVELOPING, but I don't
> think it's worth the trouble to over-specify the conditions under
> which each tag should be used, or to lay out consequences for cases
> where they're forgotten.  The faith part is trusting devs to
> understand and apply the written suggestions, not in determining what
> the suggestions are.

Which brings me back to my very first words of this sub thread:

Either someone cares about the background of a patch or he/she doesn't.

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

Re: [gentoo-portage-dev] Signing off patches

[W. Trevor King]

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

On Tue, Jan 21, 2014 at 08:22:31PM +0100, Tom Wijsman wrote:
> On Tue, 21 Jan 2014 11:18:39 -0800 W. Trevor King wrote:
> > I'm all for recording suggested conventions in DEVELOPING, but I
> > don't think it's worth the trouble to over-specify the conditions
> > under which each tag should be used, or to lay out consequences
> > for cases where they're forgotten.  The faith part is trusting
> > devs to understand and apply the written suggestions, not in
> > determining what the suggestions are.
> 
> Which brings me back to my very first words of this sub thread:
> 
> Either someone cares about the background of a patch or he/she
> doesn't.

That's certainly true.  My initial impression was that you were
against suggesting these conventions in DEVELOPING.  Perhaps I
missunderstood.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-portage-dev] Signing off patches

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 945 bytes --]

On Saturday 18 January 2014 17:57:38 Tom Wijsman wrote:
> On Sat, 18 Jan 2014 08:43:12 -0800 "W. Trevor King" wrote:
> > On Sat, Jan 18, 2014 at 04:02:02PM +0100, Tom Wijsman wrote:
> > I think the idea is that you shouldn't need to refer to an external
> > resource like the mailing list to understand the idea behind the
> > patch,
> 
> Either someone cares about the background of a patch or he/she doesn't.

full details to understand the change must be in the commit message.  saying 
"go find it in the mailing list" is not a workable solution.

this doesn't mean you have to copy & paste the entire discussion, but it does 
mean you have to distill things down.  for topics that go on for a while, 
adding a tag linking to the mailing list archive is certainly OK.

when it comes to tags, i only copy in what other people have bothered posting.  
so if someone posts their Reviewed-by or Acked-by, i'll use them.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]