[PATCH 1/1] UBUNTU: SAUCE: Adopt the use of "BugLink:" lines in git commit messages.

[Steve Conklin]

On 05/04/2009 01:55 PM, Amit Kucheria wrote:
> On Mon, May 04, 2009 at 01:13:06PM -0500, Steve Conklin wrote:
> 
>>>> Here's a further request for comment -
>>>>
>>>> I'm in the process of cleaning up the patches that we are carrying in
>>>> the hardy netbook-lpia branch. These get reapplied to the hardy
>>>> distro when we periodically rebase them. I'm already removing
>>>> whitespace errors in these so that they apply cleanly each time.
>>>> Tim suggested that I also add whitespace to the commit text on these
>>>> where needed to prevent junk like "OriginalAuthor" from being
>>>> appended to the Subject lines by git.
>>>>
>>>> My intent was to add a hook in the rebasing script optionally
>>>> run a script against all the patches to be rebased, before
>>>> they are applied. This will allow me to fix the problems
>>>> above, but would also allow me to to make the BugLink changes
>>>> desribed above to all the patches we are carrying during the
>>>> rebase. This should also apply easily to other possible uses.
> 
> Couldn't you just replace the rebase command in the script with a call to an interactive rebase? That will allow you to edit your commits if you want.
> 
>>>> Any scripts run against the tree as part of a rebase should be
>>>> added and committed, with a commit text describing that they
>>>> were run as part of a certain rebase. I don't think it's good
>>>> to automatically call the same script for every rebase, as these
>>>> are designed to make one-time sets of changes. Committing them
>>>> will preserve the history of what was done.
> 
> What kind of changes do you make repeatedly on a rebase? I thought the whitespace cleanup is a one-off thing.
> 
>>>> What does the team think of this approach in general, and
>>>> specifically about being used to add the BugLink lines?
>>>>
>>>> Steve
>>>>
>>>>
>>> The approach itself might be helpful. I am just not sure how important
>>> the BugLink is for patches in any Hardy as we won't push upstream from
>>> there, or do we?
>>>
>>> Stefan
>>>
>>>
>> One of the things I plan to do as soon as I can is to review all
>> the netbook-lpia patches to see which need to go upstream or to
>> stable, or into our own distros as sauce patches. I suspect that
>> there aren't too many, and that most of those will be quirks
>> for various I/O devices.
> 
> But quirks by themselves should be going upstream lest we causes regressions in future releases when the semantics of a quirk change.
> 

Sorry if I was unclear, but we are in agreement. Quirks should be going upstream. I'm going to make sure that they have.

Steve