proposal to stop using "backport: " in commit logs

proposal to stop using "backport: " in commit logs

[Ken Dreyer]

A while ago this came up in #ceph-devel and I wanted to bring it to a
wider audience.

Should we stop the convention of adding the "backport: " tags in Git?

Loic brought up the point that this data is essentially immutable after
we merge it, and it's better to point at a Redmine tracker where we can
alter the "backport" field.

This makes it easier to adjust the "backport" data after the code's been
merged to master. It also makes it easier for whoever is corralling the
backport efforts, because the person only have one place to look
(Redmine) instead of two (Redmine + git commit logs).

For what it's worth I agree with Loic on this.

Any objections?

- Ken

Re: proposal to stop using "backport: " in commit logs

[Sage Weil]

On Mon, 13 Apr 2015, Ken Dreyer wrote:
> A while ago this came up in #ceph-devel and I wanted to bring it to a
> wider audience.
> 
> Should we stop the convention of adding the "backport: " tags in Git?
> 
> Loic brought up the point that this data is essentially immutable after
> we merge it, and it's better to point at a Redmine tracker where we can
> alter the "backport" field.
> 
> This makes it easier to adjust the "backport" data after the code's been
> merged to master. It also makes it easier for whoever is corralling the
> backport efforts, because the person only have one place to look
> (Redmine) instead of two (Redmine + git commit logs).
> 
> For what it's worth I agree with Loic on this.

Yeah, this sounds better to me!

sage

Re: proposal to stop using "backport: " in commit logs

[Gregory Farnum]

On Mon, Apr 13, 2015 at 9:48 AM, Ken Dreyer <kdreyer@redhat.com> wrote:
> A while ago this came up in #ceph-devel and I wanted to bring it to a
> wider audience.
>
> Should we stop the convention of adding the "backport: " tags in Git?
>
> Loic brought up the point that this data is essentially immutable after
> we merge it, and it's better to point at a Redmine tracker where we can
> alter the "backport" field.
>
> This makes it easier to adjust the "backport" data after the code's been
> merged to master. It also makes it easier for whoever is corralling the
> backport efforts, because the person only have one place to look
> (Redmine) instead of two (Redmine + git commit logs).
>
> For what it's worth I agree with Loic on this.
>
> Any objections?

Why don't we just treat the backport commit tag as an expected value,
and any corresponding redmine data as the canonical one? I find the
backport tags to be useful when reviewing commits and I think the
authorial intention matters. For instance, it's not uncommon in some
parts of the codebase to discover and fix bugs as part of a feature
branch (because it's doing new things that weren't previously
exercised), tag the bug fix as a backport, and then generate tickets
later (assuming we're behaving).
-Greg

Re: proposal to stop using "backport: " in commit logs

[Loic Dachary]

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


Hi Greg,

On 13/04/2015 19:04, Gregory Farnum wrote:
> On Mon, Apr 13, 2015 at 9:48 AM, Ken Dreyer <kdreyer@redhat.com> wrote:
>> A while ago this came up in #ceph-devel and I wanted to bring it to a
>> wider audience.
>>
>> Should we stop the convention of adding the "backport: " tags in Git?
>>
>> Loic brought up the point that this data is essentially immutable after
>> we merge it, and it's better to point at a Redmine tracker where we can
>> alter the "backport" field.
>>
>> This makes it easier to adjust the "backport" data after the code's been
>> merged to master. It also makes it easier for whoever is corralling the
>> backport efforts, because the person only have one place to look
>> (Redmine) instead of two (Redmine + git commit logs).
>>
>> For what it's worth I agree with Loic on this.
>>
>> Any objections?
> 
> Why don't we just treat the backport commit tag as an expected value,
> and any corresponding redmine data as the canonical one? 

That's what we currently do, I think.

> I find the
> backport tags to be useful when reviewing commits and I think the
> authorial intention matters. 

A git-notes could be added for that purpose instead. 

> For instance, it's not uncommon in some
> parts of the codebase to discover and fix bugs as part of a feature
> branch (because it's doing new things that weren't previously
> exercised), tag the bug fix as a backport, and then generate tickets
> later (assuming we're behaving).

Cheers

> -Greg
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


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

Re: proposal to stop using "backport: " in commit logs

[Gregory Farnum]

On Mon, Apr 13, 2015 at 10:28 AM, Loic Dachary <loic@dachary.org> wrote:
>
> Hi Greg,
>
> On 13/04/2015 19:04, Gregory Farnum wrote:
>> On Mon, Apr 13, 2015 at 9:48 AM, Ken Dreyer <kdreyer@redhat.com> wrote:
>>> A while ago this came up in #ceph-devel and I wanted to bring it to a
>>> wider audience.
>>>
>>> Should we stop the convention of adding the "backport: " tags in Git?
>>>
>>> Loic brought up the point that this data is essentially immutable after
>>> we merge it, and it's better to point at a Redmine tracker where we can
>>> alter the "backport" field.
>>>
>>> This makes it easier to adjust the "backport" data after the code's been
>>> merged to master. It also makes it easier for whoever is corralling the
>>> backport efforts, because the person only have one place to look
>>> (Redmine) instead of two (Redmine + git commit logs).
>>>
>>> For what it's worth I agree with Loic on this.
>>>
>>> Any objections?
>>
>> Why don't we just treat the backport commit tag as an expected value,
>> and any corresponding redmine data as the canonical one?
>
> That's what we currently do, I think.
>
>> I find the
>> backport tags to be useful when reviewing commits and I think the
>> authorial intention matters.
>
> A git-notes could be added for that purpose instead.

Huh, I'm not previously familiar with that mechanism. Is there any
particular reason you didn't use that for tracking backport states to
begin with? It looks like it's sort of designed for this purpose.

Re: proposal to stop using "backport: " in commit logs

[Loic Dachary]

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



On 13/04/2015 20:53, Gregory Farnum wrote:
> On Mon, Apr 13, 2015 at 10:28 AM, Loic Dachary <loic@dachary.org> wrote:
>>
>> Hi Greg,
>>
>> On 13/04/2015 19:04, Gregory Farnum wrote:
>>> On Mon, Apr 13, 2015 at 9:48 AM, Ken Dreyer <kdreyer@redhat.com> wrote:
>>>> A while ago this came up in #ceph-devel and I wanted to bring it to a
>>>> wider audience.
>>>>
>>>> Should we stop the convention of adding the "backport: " tags in Git?
>>>>
>>>> Loic brought up the point that this data is essentially immutable after
>>>> we merge it, and it's better to point at a Redmine tracker where we can
>>>> alter the "backport" field.
>>>>
>>>> This makes it easier to adjust the "backport" data after the code's been
>>>> merged to master. It also makes it easier for whoever is corralling the
>>>> backport efforts, because the person only have one place to look
>>>> (Redmine) instead of two (Redmine + git commit logs).
>>>>
>>>> For what it's worth I agree with Loic on this.
>>>>
>>>> Any objections?
>>>
>>> Why don't we just treat the backport commit tag as an expected value,
>>> and any corresponding redmine data as the canonical one?
>>
>> That's what we currently do, I think.
>>
>>> I find the
>>> backport tags to be useful when reviewing commits and I think the
>>> authorial intention matters.
>>
>> A git-notes could be added for that purpose instead.
> 
> Huh, I'm not previously familiar with that mechanism. Is there any
> particular reason you didn't use that for tracking backport states to
> begin with? It looks like it's sort of designed for this purpose.

My thoughts exactly. But I figure that out only recently. The cross referencing script  which currently creates a web page should be changed to update / verify git notes in a namespace dedicated to backporting, in a json format that is rigid and meant to be consistent and reliable. And the web page should be a display of these git notes instead of what it currently is. The default git notes name space could be used by developers to store human edited notes about commits such as the Backport field etc. because there is value in loosely maintained information.

Cheers

-- 
Loïc Dachary, Artisan Logiciel Libre


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

Re: proposal to stop using "backport: " in commit logs

[Joao Eduardo Luis]

On 04/13/2015 07:53 PM, Gregory Farnum wrote:
> On Mon, Apr 13, 2015 at 10:28 AM, Loic Dachary <loic@dachary.org> wrote:
>>
>> Hi Greg,
>>
>> On 13/04/2015 19:04, Gregory Farnum wrote:
>>> On Mon, Apr 13, 2015 at 9:48 AM, Ken Dreyer <kdreyer@redhat.com> wrote:
>>>> A while ago this came up in #ceph-devel and I wanted to bring it to a
>>>> wider audience.
>>>>
>>>> Should we stop the convention of adding the "backport: " tags in Git?
>>>>
>>>> Loic brought up the point that this data is essentially immutable after
>>>> we merge it, and it's better to point at a Redmine tracker where we can
>>>> alter the "backport" field.
>>>>
>>>> This makes it easier to adjust the "backport" data after the code's been
>>>> merged to master. It also makes it easier for whoever is corralling the
>>>> backport efforts, because the person only have one place to look
>>>> (Redmine) instead of two (Redmine + git commit logs).
>>>>
>>>> For what it's worth I agree with Loic on this.
>>>>
>>>> Any objections?
>>>
>>> Why don't we just treat the backport commit tag as an expected value,
>>> and any corresponding redmine data as the canonical one?
>>
>> That's what we currently do, I think.
>>
>>> I find the
>>> backport tags to be useful when reviewing commits and I think the
>>> authorial intention matters.
>>
>> A git-notes could be added for that purpose instead.
> 
> Huh, I'm not previously familiar with that mechanism. Is there any
> particular reason you didn't use that for tracking backport states to
> begin with? It looks like it's sort of designed for this purpose.

I agree.  git-notes seem like the way to go for this -- also, mind blown
at finding about git-notes, looks amazing!

  -Joao

Re: proposal to stop using "backport: " in commit logs

[Loic Dachary]

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



On 13/04/2015 18:48, Ken Dreyer wrote:
> A while ago this came up in #ceph-devel and I wanted to bring it to a
> wider audience.
> 
> Should we stop the convention of adding the "backport: " tags in Git?
> 
> Loic brought up the point that this data is essentially immutable after
> we merge it, and it's better to point at a Redmine tracker where we can
> alter the "backport" field.
> 
> This makes it easier to adjust the "backport" data after the code's been
> merged to master. It also makes it easier for whoever is corralling the
> backport efforts, because the person only have one place to look
> (Redmine) instead of two (Redmine + git commit logs).
> 
> For what it's worth I agree with Loic on this.

I agree with myself ;-)

> 
> Any objections?
> 
> - Ken
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


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