[PATCH 1/1] UBUNTU: SAUCE: Adopt the use of "BugLink:" lines in git commit messages.
Steve Conklin
steve.conklin at canonical.com
Mon May 4 18:13:06 UTC 2009
On 05/04/2009 09:03 AM, Stefan Bader wrote:
> Steve Conklin wrote:
>> On 05/02/2009 04:16 AM, Andy Whitcroft wrote:
>>> On Fri, May 01, 2009 at 04:21:51PM -0700, Brad Figg wrote:
>>>> Why wouldn't your changes also show up in the output and thus in then
>>>> changelog?
>>> They would indeed. There is a difference in what you and I think we are
>>> trying to achieve here :).
>>>
>>> I thought the overall intent was that we can switch from using the
>>> Bug:#123456 form which has no meaning outside the Ubuntu community to
>>> using the BugLink: http://www.launchpad.net/bug/123456 form which is
>>> meaningful to everyone and we can thus leave in our upstream
>>> submissions. Both giving us Janitor support for patches which pass via
>>> upstream and credit in the community.
>>>
>>> As I understand your change you are putting the following into the
>>> output and therefore the debian/changelog:
>>>
>>> - LP: #123456
>>> - Buglink: http:.../123456
>>>
>>> I don't think we are trying to get the latter line into the
>>> debian/changelog. What I thought we were after was the extraction of
>>> bug numbers from the git changelog from either of the following forms:
>>>
>>> Bug: #123456
>>> or
>>> BugLink: http:..../123456
>>>
>>> But outputing that as just this form for debian/changelog:
>>>
>>> - LP: #123456
>>>
>>> -apw
>>>
>>
>> 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.
>>
>> 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 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.
Steve
More information about the kernel-team
mailing list