[RFC] Better management of bug to upstream stable patch relationship

Stefan Bader stefan.bader at canonical.com
Wed Jun 2 07:49:41 UTC 2010


On 06/02/2010 01:12 AM, Leann Ogasawara wrote:
> On Tue, 2010-06-01 at 09:51 +0200, Stefan Bader wrote:
>> Another issue that arises from preferring fixes coming though upstream stable
>> is, that often in those patches, there is no reference to Launchpad bugs that
>> are open for that issue.
>> If the patch originated from us, we add a BugLink which is preserved, but if the
>> patch already went upstream for other reasons or is only suggested by us for
>> stable inclusion, there will be no such reference. Still it would be good to
>> have a better view on which bugs should be fixed by a certain upstream stable patch.
>> So the idea again would be to have a tag indicating that there is a fix expected
>> from upstream stable and then probably have a formalized comment (maybe the git
>> log --pretty=short of the patch in Linus tree) to allow automated scripts to
>> find those bug reports and patch references.
>>
>> Comments?
> 
> Would you want to use the 'upstream-stable' tag you proposed in an
> earlier thread [1] or did you have something else in mind?  

I was thinking of a different tag. The upstream stable generically indicating
what you wrote below. This is a tracking bug for an upstream stable release. For
that purpose I did not think it would be necessary to know by tag which one.

> Regardless, this all seems reasonable to me.  In the past I had actually
> used even more granularity and tagged the bugs with the upstream stable
> version that the fix would be landing in, eg. 2.6.32.13 or what have
> you.

The other tag I thought of more saying, this report contains a reference to an
upstream patch which either was sent with "cc: stable.." on the sob line or now
forwarded there for inclusion. So it would get added before the patch lands in
stable or at least needs to be there before applying a batch of upstream stable
that contains it. That way, before actually applying one could do a search to
get a list of expected patches and their bug reports which then could be used to
add additional buglinks (additional to the tracking bug) to the commits.

Stefan

> 
> Thanks,
> Leann
> 
> [1] https://lists.ubuntu.com/archives/kernel-team/2010-May/010842.html
> 





More information about the kernel-team mailing list