FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 10-27-2008, 12:26 PM
Tim Gardner
 
Default RFC: Stable kernel updates and the SRU process

I would like to propose the following change in policy with regard to
the Ubuntu kernel and stable tree updates.

In the past our kernels have incorporated stable kernel tree updates up
to the point of kernel freeze. After that point, only those patches that
were specifically referenced by SRU Launchpad reports were applied.

The upstream process for stable tree updates is quite similar in scope
to the SRU process, e.g., each patch has to demonstrably fix a bug, and
each patch is vetted by upstream by originating either directly from
Linus' tree or in a minimally backported form of that patch.

I think we are remiss if we do not take advantage of that upstream
process to improve our kernel. Therefore I propose that we modify our
kernel update policy such that we adopt stable kernel updates at
appropriate points in the release process (avoiding kernel freezes etc)
for as long as upstream continues to provide updates, and that these
stable kernel updates not be subject to the SRU process.

Comments?

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-27-2008, 01:24 PM
Henrik Rydberg
 
Default RFC: Stable kernel updates and the SRU process

> The upstream process for stable tree updates is quite similar in scope
> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
> each patch is vetted by upstream by originating either directly from
> Linus' tree or in a minimally backported form of that patch.

As you say, why not take advantage of a good existing process. Makes even
more sense considering that 2.6.27 has been declared a long-term support
kernel.

Henrik Rydberg


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-27-2008, 01:27 PM
Tim Gardner
 
Default RFC: Stable kernel updates and the SRU process

Martin Pitt wrote:
> Hi Tim,
>
> Tim Gardner [2008-10-27 7:26 -0600]:
>> In the past our kernels have incorporated stable kernel tree updates up
>> to the point of kernel freeze. After that point, only those patches that
>> were specifically referenced by SRU Launchpad reports were applied.
>
> Hm, I thought we already did backport fixes from -stable in SRUs, but
> I might misremember.
>
>> The upstream process for stable tree updates is quite similar in scope
>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>> each patch is vetted by upstream by originating either directly from
>> Linus' tree or in a minimally backported form of that patch.
>
> I agree, they are generally quite sane and also well tested.
>
>> I think we are remiss if we do not take advantage of that upstream
>> process to improve our kernel.
>
> I agree.
>
>> Therefore I propose that we modify our kernel update policy such
>> that we adopt stable kernel updates at appropriate points in the
>> release process (avoiding kernel freezes etc) for as long as
>> upstream continues to provide updates, and that these stable kernel
>> updates not be subject to the SRU process.
>
> They should still be subject to the process in terms of having them in
> -proposed, and document their testing in the associated bug reports.
> Due to the sheer number of SRU bugs, we cannot generally verify each
> and every fix anyway, but have resorted to keeping it in -proposed for
> quite a while, verifying only the bugs we can actually test on our
> systems or which we get feedback from users from, and looking out for
> regression reports.
>

I agree that _all_ kernels should be subject to the -proposed period of
testing, but I would like to avoid the duplication of effort that has
already gone into the stable kernel updates. For example, there are 43
functional commits in the 2.6.27.y tree that have not been applied to
Intrepid. Do _you_ want to write the SRU report for each of those
commits? I sure don't.

> So unless a kernel patch has to go into -updates really quickly, I am
> all for including changes from upstream stable, provided that you read
> over them and check that they don't blatantly conflict with something
> we want to do in Ubuntu, and are otherwise ok.
>
> In a case where an upstream stable update would be the only part of a
> SRU, it should have an LP # which is listing the changelog and
> documenting testing feedback.
>
> Martin
>


--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-27-2008, 05:35 PM
Tim Gardner
 
Default RFC: Stable kernel updates and the SRU process

Martin Pitt wrote:
> Tim Gardner [2008-10-27 8:27 -0600]:
>> For example, there are 43 functional commits in the 2.6.27.y tree
>> that have not been applied to Intrepid. Do _you_ want to write the
>> SRU report for each of those commits? I sure don't.
>
> No, we shouldn't. We don't do this for GNOME point releases either.
>
> That's exactly why I suggested to just have a "collective" bug like
> "update to 2.6.27.x bug fixes" if we don't already have a bunch of SRU
> bugs for our own purposes anyway:
>
>>> So unless a kernel patch has to go into -updates really quickly, I am
>>> all for including changes from upstream stable, provided that you read
>>> over them and check that they don't blatantly conflict with something
>>> we want to do in Ubuntu, and are otherwise ok.
>>>
>>> In a case where an upstream stable update would be the only part of a
>>> SRU, it should have an LP # which is listing the changelog and
>>> documenting testing feedback.

I can handle one collective SRU report for test tracking purposes. I
guess I didn't initially understand your meaning.

rtg
--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-28-2008, 03:07 PM
Stefan Bader
 
Default RFC: Stable kernel updates and the SRU process

Tim Gardner wrote:
> I would like to propose the following change in policy with regard to
> the Ubuntu kernel and stable tree updates.
>
> In the past our kernels have incorporated stable kernel tree updates up
> to the point of kernel freeze. After that point, only those patches that
> were specifically referenced by SRU Launchpad reports were applied.
>
> The upstream process for stable tree updates is quite similar in scope
> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
> each patch is vetted by upstream by originating either directly from
> Linus' tree or in a minimally backported form of that patch.
>
> I think we are remiss if we do not take advantage of that upstream
> process to improve our kernel. Therefore I propose that we modify our
> kernel update policy such that we adopt stable kernel updates at
> appropriate points in the release process (avoiding kernel freezes etc)
> for as long as upstream continues to provide updates, and that these
> stable kernel updates not be subject to the SRU process.
>
> Comments?
>
> rtg

I would also be in favor of such a change. In the past there have been several
bug that were fixed by changes in the stable tree which we had to search for
and then pull in. Also the patches in the stable tree are generally small and
it takes a review process to get them in. So why not simplify our workload by
pulling them in by default. I'd also only do one tracking bug per stable release.

Stefan

--

When all other means of communication fail, try words!



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-28-2008, 03:23 PM
Tim Gardner
 
Default RFC: Stable kernel updates and the SRU process

Stefan Bader wrote:
> Tim Gardner wrote:
>> I would like to propose the following change in policy with regard to
>> the Ubuntu kernel and stable tree updates.
>>
>> In the past our kernels have incorporated stable kernel tree updates up
>> to the point of kernel freeze. After that point, only those patches that
>> were specifically referenced by SRU Launchpad reports were applied.
>>
>> The upstream process for stable tree updates is quite similar in scope
>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>> each patch is vetted by upstream by originating either directly from
>> Linus' tree or in a minimally backported form of that patch.
>>
>> I think we are remiss if we do not take advantage of that upstream
>> process to improve our kernel. Therefore I propose that we modify our
>> kernel update policy such that we adopt stable kernel updates at
>> appropriate points in the release process (avoiding kernel freezes etc)
>> for as long as upstream continues to provide updates, and that these
>> stable kernel updates not be subject to the SRU process.
>>
>> Comments?
>>
>> rtg
>
> I would also be in favor of such a change. In the past there have been several
> bug that were fixed by changes in the stable tree which we had to search for
> and then pull in. Also the patches in the stable tree are generally small and
> it takes a review process to get them in. So why not simplify our workload by
> pulling them in by default. I'd also only do one tracking bug per stable release.
>
> Stefan
>

Stefan - I think there are still some 2.6.24.y patches that haven't been
applied to Hardy.

--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-28-2008, 03:40 PM
Ben Collins
 
Default RFC: Stable kernel updates and the SRU process

Stefan Bader wrote:
> Tim Gardner wrote:
>> I would like to propose the following change in policy with regard to
>> the Ubuntu kernel and stable tree updates.
>>
>> In the past our kernels have incorporated stable kernel tree updates up
>> to the point of kernel freeze. After that point, only those patches that
>> were specifically referenced by SRU Launchpad reports were applied.
>>
>> The upstream process for stable tree updates is quite similar in scope
>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>> each patch is vetted by upstream by originating either directly from
>> Linus' tree or in a minimally backported form of that patch.
>>
>> I think we are remiss if we do not take advantage of that upstream
>> process to improve our kernel. Therefore I propose that we modify our
>> kernel update policy such that we adopt stable kernel updates at
>> appropriate points in the release process (avoiding kernel freezes etc)
>> for as long as upstream continues to provide updates, and that these
>> stable kernel updates not be subject to the SRU process.
>>
>> Comments?
>>
>> rtg
>
> I would also be in favor of such a change. In the past there have been several
> bug that were fixed by changes in the stable tree which we had to search for
> and then pull in. Also the patches in the stable tree are generally small and
> it takes a review process to get them in. So why not simplify our workload by
> pulling them in by default. I'd also only do one tracking bug per stable release.
>

I should point out that regardless of the upstream process, we have, in
the past, gotten regressions due to these changes.

Hence the reason we have the current policy.

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-28-2008, 03:40 PM
Stefan Bader
 
Default RFC: Stable kernel updates and the SRU process

Tim Gardner wrote:
> Stefan Bader wrote:
>> Tim Gardner wrote:
>>> I would like to propose the following change in policy with regard to
>>> the Ubuntu kernel and stable tree updates.
>>>
>>> In the past our kernels have incorporated stable kernel tree updates up
>>> to the point of kernel freeze. After that point, only those patches that
>>> were specifically referenced by SRU Launchpad reports were applied.
>>>
>>> The upstream process for stable tree updates is quite similar in scope
>>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>>> each patch is vetted by upstream by originating either directly from
>>> Linus' tree or in a minimally backported form of that patch.
>>>
>>> I think we are remiss if we do not take advantage of that upstream
>>> process to improve our kernel. Therefore I propose that we modify our
>>> kernel update policy such that we adopt stable kernel updates at
>>> appropriate points in the release process (avoiding kernel freezes etc)
>>> for as long as upstream continues to provide updates, and that these
>>> stable kernel updates not be subject to the SRU process.
>>>
>>> Comments?
>>>
>>> rtg
>> I would also be in favor of such a change. In the past there have been several
>> bug that were fixed by changes in the stable tree which we had to search for
>> and then pull in. Also the patches in the stable tree are generally small and
>> it takes a review process to get them in. So why not simplify our workload by
>> pulling them in by default. I'd also only do one tracking bug per stable release.
>>
>> Stefan
>>
>
> Stefan - I think there are still some 2.6.24.y patches that haven't been
> applied to Hardy.
>

I think there are still quite a few of them. My list might be a bit outdated by
now but there could be around 130 of them still not being applied. If we
change our policy, they should definitely go in.


--

When all other means of communication fail, try words!



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-28-2008, 03:44 PM
Stefan Bader
 
Default RFC: Stable kernel updates and the SRU process

Ben Collins wrote:
> Stefan Bader wrote:
>> Tim Gardner wrote:
>>> I would like to propose the following change in policy with regard to
>>> the Ubuntu kernel and stable tree updates.
>>>
>>> In the past our kernels have incorporated stable kernel tree updates up
>>> to the point of kernel freeze. After that point, only those patches that
>>> were specifically referenced by SRU Launchpad reports were applied.
>>>
>>> The upstream process for stable tree updates is quite similar in scope
>>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>>> each patch is vetted by upstream by originating either directly from
>>> Linus' tree or in a minimally backported form of that patch.
>>>
>>> I think we are remiss if we do not take advantage of that upstream
>>> process to improve our kernel. Therefore I propose that we modify our
>>> kernel update policy such that we adopt stable kernel updates at
>>> appropriate points in the release process (avoiding kernel freezes etc)
>>> for as long as upstream continues to provide updates, and that these
>>> stable kernel updates not be subject to the SRU process.
>>>
>>> Comments?
>>>
>>> rtg
>>
>> I would also be in favor of such a change. In the past there have been
>> several
>> bug that were fixed by changes in the stable tree which we had to
>> search for
>> and then pull in. Also the patches in the stable tree are generally
>> small and
>> it takes a review process to get them in. So why not simplify our
>> workload by
>> pulling them in by default. I'd also only do one tracking bug per
>> stable release.
>>
>
> I should point out that regardless of the upstream process, we have, in
> the past, gotten regressions due to these changes.
>
> Hence the reason we have the current policy.

Still I think it would be better to revert selectively if there are regressions
found than only to select a few patches and miss fixes until we get bitten by them.

--

When all other means of communication fail, try words!



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 10-28-2008, 04:13 PM
Ben Collins
 
Default RFC: Stable kernel updates and the SRU process

Stefan Bader wrote:
> Ben Collins wrote:
>> Stefan Bader wrote:
>>> Tim Gardner wrote:
>>>> I would like to propose the following change in policy with regard to
>>>> the Ubuntu kernel and stable tree updates.
>>>>
>>>> In the past our kernels have incorporated stable kernel tree updates up
>>>> to the point of kernel freeze. After that point, only those patches that
>>>> were specifically referenced by SRU Launchpad reports were applied.
>>>>
>>>> The upstream process for stable tree updates is quite similar in scope
>>>> to the SRU process, e.g., each patch has to demonstrably fix a bug, and
>>>> each patch is vetted by upstream by originating either directly from
>>>> Linus' tree or in a minimally backported form of that patch.
>>>>
>>>> I think we are remiss if we do not take advantage of that upstream
>>>> process to improve our kernel. Therefore I propose that we modify our
>>>> kernel update policy such that we adopt stable kernel updates at
>>>> appropriate points in the release process (avoiding kernel freezes etc)
>>>> for as long as upstream continues to provide updates, and that these
>>>> stable kernel updates not be subject to the SRU process.
>>>>
>>>> Comments?
>>>>
>>>> rtg
>>> I would also be in favor of such a change. In the past there have been
>>> several
>>> bug that were fixed by changes in the stable tree which we had to
>>> search for
>>> and then pull in. Also the patches in the stable tree are generally
>>> small and
>>> it takes a review process to get them in. So why not simplify our
>>> workload by
>>> pulling them in by default. I'd also only do one tracking bug per
>>> stable release.
>>>
>> I should point out that regardless of the upstream process, we have, in
>> the past, gotten regressions due to these changes.
>>
>> Hence the reason we have the current policy.
>
> Still I think it would be better to revert selectively if there are regressions
> found than only to select a few patches and miss fixes until we get bitten by them.

Then I think this should be accompanied by an extended bit of time in
-proposed when such a blanket merge is done with the .y tree.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 11:31 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org