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

[Steve Conklin]

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