Backporting

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Backporting

John Ralls-2
Is there a catch-all bug for 2.4 backporting? If not, should there be, or shall we just handle our own backports and not worry about it?

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backporting

Derek Atkins
John Ralls <[hidden email]> writes:

> Is there a catch-all bug for 2.4 backporting? If not, should there be,
> or shall we just handle our own backports and not worry about it?

There is not, but we could certainly create one.

> Regards,
> John Ralls

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backporting

Christian Stimming-4
Am Mittwoch, 18. Mai 2011 schrieb Derek Atkins:
> John Ralls <[hidden email]> writes:
> > Is there a catch-all bug for 2.4 backporting? If not, should there be,
> > or shall we just handle our own backports and not worry about it?
>
> There is not, but we could certainly create one.

Exactly.

On another note, I don't think we have yet found again a useful workflow for
back-porting. Marking bugs as dependent on some arbitrary bug number used to
be a somewhat annoying step in the past for me. On the other hand, the "BP"
marker in the commit message gets forgotten easily, too. I don't know, too.

Regards,

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backporting

John Ralls-2

On May 18, 2011, at 11:32 AM, Christian Stimming wrote:

> Am Mittwoch, 18. Mai 2011 schrieb Derek Atkins:
>> John Ralls <[hidden email]> writes:
>>> Is there a catch-all bug for 2.4 backporting? If not, should there be,
>>> or shall we just handle our own backports and not worry about it?
>>
>> There is not, but we could certainly create one.
>
> Exactly.
>
> On another note, I don't think we have yet found again a useful workflow for
> back-porting. Marking bugs as dependent on some arbitrary bug number used to
> be a somewhat annoying step in the past for me. On the other hand, the "BP"
> marker in the commit message gets forgotten easily, too. I don't know, too.
>

Yeah, I know we *can* create one. The question is *should* we create one, or should we use some other method of tracking the backports... or maybe not bother? ISTM the simplest solution is to just double commit (trunk and 2.4) when doing a bug fix.

Is there supposed to be an email for a "BP" commit beyond the [Audit] notation in gnucash-changes?

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backporting

Derek Atkins
John Ralls <[hidden email]> writes:

> On May 18, 2011, at 11:32 AM, Christian Stimming wrote:
>
>> Am Mittwoch, 18. Mai 2011 schrieb Derek Atkins:
>>> John Ralls <[hidden email]> writes:
>>>> Is there a catch-all bug for 2.4 backporting? If not, should there be,
>>>> or shall we just handle our own backports and not worry about it?
>>>
>>> There is not, but we could certainly create one.
>>
>> Exactly.
>>
>> On another note, I don't think we have yet found again a useful workflow for
>> back-porting. Marking bugs as dependent on some arbitrary bug number used to
>> be a somewhat annoying step in the past for me. On the other hand, the "BP"
>> marker in the commit message gets forgotten easily, too. I don't know, too.
>>
>
> Yeah, I know we *can* create one. The question is *should* we create one, or should we use some other method of tracking the backports... or maybe not bother? ISTM the simplest solution is to just double commit (trunk and 2.4) when doing a bug fix.
>
> Is there supposed to be an email for a "BP" commit beyond the [Audit] notation in gnucash-changes?

No.  It's just the audit notation.  The idea at the time was that it
would stand out and draw attention to get other eyes on the changeset.
It was also an idea that we'd let the changeset "bake" a bit before
backporting, because we wanted to be fairly sure the change was
"correct" before it possibly infected the "stable" tree.  So that's an
argument against the double commit (you don't get a chance to bake the
changes before it hits stable).

We don't really have a good procedure in place.

> Regards,
> John Ralls

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backporting

John Ralls-2

On May 19, 2011, at 8:29 AM, Derek Atkins wrote:

> John Ralls <[hidden email]> writes:
>
>> On May 18, 2011, at 11:32 AM, Christian Stimming wrote:
>>
>>> Am Mittwoch, 18. Mai 2011 schrieb Derek Atkins:
>>>> John Ralls <[hidden email]> writes:
>>>>> Is there a catch-all bug for 2.4 backporting? If not, should there be,
>>>>> or shall we just handle our own backports and not worry about it?
>>>>
>>>> There is not, but we could certainly create one.
>>>
>>> Exactly.
>>>
>>> On another note, I don't think we have yet found again a useful workflow for
>>> back-porting. Marking bugs as dependent on some arbitrary bug number used to
>>> be a somewhat annoying step in the past for me. On the other hand, the "BP"
>>> marker in the commit message gets forgotten easily, too. I don't know, too.
>>>
>>
>> Yeah, I know we *can* create one. The question is *should* we create one, or should we use some other method of tracking the backports... or maybe not bother? ISTM the simplest solution is to just double commit (trunk and 2.4) when doing a bug fix.
>>
>> Is there supposed to be an email for a "BP" commit beyond the [Audit] notation in gnucash-changes?
>
> No.  It's just the audit notation.  The idea at the time was that it
> would stand out and draw attention to get other eyes on the changeset.
> It was also an idea that we'd let the changeset "bake" a bit before
> backporting, because we wanted to be fairly sure the change was
> "correct" before it possibly infected the "stable" tree.  So that's an
> argument against the double commit (you don't get a chance to bake the
> changes before it hits stable).
>
> We don't really have a good procedure in place.

Well, let's work one out then.

It's easier to write a procedure if one starts with goals for the procedure to accomplish, and the first goal is obvious: To get bugfixes into the next release. I think a more formal statement of your "baking" analogy is to get bugfixes tested before committing them into the stable branch. Any more?

Regards,
John Ralls

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Backporting

Derek Atkins
John Ralls <[hidden email]> writes:

>> We don't really have a good procedure in place.
>
> Well, let's work one out then.
>
> It's easier to write a procedure if one starts with goals for the
> procedure to accomplish, and the first goal is obvious: To get
> bugfixes into the next release. I think a more formal statement of
> your "baking" analogy is to get bugfixes tested before committing them
> into the stable branch. Any more?

* We want to make sure we don't forget changesets (which I suppose is a
  corellary of your first statement.
* We want to make sure we don't commit extra changesets (no desire to
  add additional cruft to the stable branch)
* We want to keep the stable branch, well, stable.  In a commercial
  environment I would say that perhaps we should require a "make check"
  test that shows the bug and then the patch that fixes it, so we don't
  have a future regression?
* It would be nice to actually have the code audited before committed,
  in addition to it just being tested.  (This is why 'BP' -> "AUDIT")

I'll try to think of more....

> Regards,
> John Ralls

-derek

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel