Wanted: hotfixes for -mm kernels

Wanted: hotfixes for -mm kernels

[Chuck Ebbert]

Most -mm kernels have small but critical bugs that are found shortly
after release.  Patches for these are posted on linux-kernel but
they aren't made available on kernel.org until the next -mm release.

Would it be possible to create a hotfix/ directory for each -mm
release and put those patches there?  A README could explain that
the fixes are untested.  At least people reading the files could
see an issue exists even if they're not brave enough to try the
patch. :)

-- 
Chuck

Re: Wanted: hotfixes for -mm kernels

[Lee Revell]

On Thu, 2006-02-02 at 15:00 -0500, Chuck Ebbert wrote:
> Most -mm kernels have small but critical bugs that are found shortly
> after release.  Patches for these are posted on linux-kernel but
> they aren't made available on kernel.org until the next -mm release.
> 
> Would it be possible to create a hotfix/ directory for each -mm
> release and put those patches there?  A README could explain that
> the fixes are untested.  At least people reading the files could
> see an issue exists even if they're not brave enough to try the
> patch. :)

I doubt it - mm is an experimental kernel, hotfixes only make sense for
production stuff.  It moves too fast.

A better question is what does -mm give you that mainline does not, that
causes you to want to "stabilize" a specific -mm version?

Lee

Re: Wanted: hotfixes for -mm kernels

[Dmitry Torokhov]

On 2/2/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Thu, 2006-02-02 at 15:00 -0500, Chuck Ebbert wrote:
> > Most -mm kernels have small but critical bugs that are found shortly
> > after release.  Patches for these are posted on linux-kernel but
> > they aren't made available on kernel.org until the next -mm release.
> >
> > Would it be possible to create a hotfix/ directory for each -mm
> > release and put those patches there?  A README could explain that
> > the fixes are untested.  At least people reading the files could
> > see an issue exists even if they're not brave enough to try the
> > patch. :)
>
> I doubt it - mm is an experimental kernel, hotfixes only make sense for
> production stuff.  It moves too fast.
>
> A better question is what does -mm give you that mainline does not, that
> causes you to want to "stabilize" a specific -mm version?
>

Some people just run -mm so the hotfixes/* would help them to get
their boxes running until the next -mm without having to hunt through
LKML for bugs already reported/fixed. This will allow better testing
coverage because most obvious bugs are caught almost immediately and
then people can continue using -mm to find more stuff.

--
Dmitry

Re: Wanted: hotfixes for -mm kernels

[Randy.Dunlap]

On Thu, 2 Feb 2006, Dmitry Torokhov wrote:

> On 2/2/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > On Thu, 2006-02-02 at 15:00 -0500, Chuck Ebbert wrote:
> > > Most -mm kernels have small but critical bugs that are found shortly
> > > after release.  Patches for these are posted on linux-kernel but
> > > they aren't made available on kernel.org until the next -mm release.
> > >
> > > Would it be possible to create a hotfix/ directory for each -mm
> > > release and put those patches there?  A README could explain that
> > > the fixes are untested.  At least people reading the files could
> > > see an issue exists even if they're not brave enough to try the
> > > patch. :)
> >
> > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > production stuff.  It moves too fast.
> >
> > A better question is what does -mm give you that mainline does not, that
> > causes you to want to "stabilize" a specific -mm version?
> >
>
> Some people just run -mm so the hotfixes/* would help them to get
> their boxes running until the next -mm without having to hunt through
> LKML for bugs already reported/fixed. This will allow better testing
> coverage because most obvious bugs are caught almost immediately and
> then people can continue using -mm to find more stuff.

Yep.  I think it's a good idea, although it does move fast, like
Lee says.  I'd be willing to help if e.g. there was some place
where several of us could upload patches to.

-- 
~Randy

Re: Wanted: hotfixes for -mm kernels

[Dmitry Torokhov]

On 2/2/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> On Thu, 2 Feb 2006, Dmitry Torokhov wrote:
>
> > On 2/2/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > > On Thu, 2006-02-02 at 15:00 -0500, Chuck Ebbert wrote:
> > > > Most -mm kernels have small but critical bugs that are found shortly
> > > > after release.  Patches for these are posted on linux-kernel but
> > > > they aren't made available on kernel.org until the next -mm release.
> > > >
> > > > Would it be possible to create a hotfix/ directory for each -mm
> > > > release and put those patches there?  A README could explain that
> > > > the fixes are untested.  At least people reading the files could
> > > > see an issue exists even if they're not brave enough to try the
> > > > patch. :)
> > >
> > > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > > production stuff.  It moves too fast.
> > >
> > > A better question is what does -mm give you that mainline does not, that
> > > causes you to want to "stabilize" a specific -mm version?
> > >
> >
> > Some people just run -mm so the hotfixes/* would help them to get
> > their boxes running until the next -mm without having to hunt through
> > LKML for bugs already reported/fixed. This will allow better testing
> > coverage because most obvious bugs are caught almost immediately and
> > then people can continue using -mm to find more stuff.
>
> Yep.  I think it's a good idea, although it does move fast, like
> Lee says.

One can argue that it doesn't move fast enough - I am pulling from
Linus into my working tree pretty much daily whereas -mm is static for
about a week. SO with Linu's tree I'm getting fixes to abvious
problems/regressions much faster.

>  I'd be willing to help if e.g. there was some place
> where several of us could upload patches to.
>

That's a nice idea too.

--
Dmitry

Re: Wanted: hotfixes for -mm kernels

[Marc Koschewski]

* Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-02-02 16:45:52 -0500]:

> On 2/2/06, Lee Revell <rlrevell@joe-job.com> wrote:
> > On Thu, 2006-02-02 at 15:00 -0500, Chuck Ebbert wrote:
> > > Most -mm kernels have small but critical bugs that are found shortly
> > > after release.  Patches for these are posted on linux-kernel but
> > > they aren't made available on kernel.org until the next -mm release.
> > >
> > > Would it be possible to create a hotfix/ directory for each -mm
> > > release and put those patches there?  A README could explain that
> > > the fixes are untested.  At least people reading the files could
> > > see an issue exists even if they're not brave enough to try the
> > > patch. :)
> >
> > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > production stuff.  It moves too fast.
> >
> > A better question is what does -mm give you that mainline does not, that
> > causes you to want to "stabilize" a specific -mm version?
> >
> 
> Some people just run -mm so the hotfixes/* would help them to get
> their boxes running until the next -mm without having to hunt through
> LKML for bugs already reported/fixed. This will allow better testing
> coverage because most obvious bugs are caught almost immediately and
> then people can continue using -mm to find more stuff.

... that's just why I so often wish to have a -git tree, Andrew. ;)

Marc

Re: Wanted: hotfixes for -mm kernels

[Martin J. Bligh]

> > > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > > production stuff.  It moves too fast.
> > >
> > > A better question is what does -mm give you that mainline does not, that
> > > causes you to want to "stabilize" a specific -mm version?
> > >
> > 
> > Some people just run -mm so the hotfixes/* would help them to get
> > their boxes running until the next -mm without having to hunt through
> > LKML for bugs already reported/fixed. This will allow better testing
> > coverage because most obvious bugs are caught almost immediately and
> > then people can continue using -mm to find more stuff.
> 
> ... that's just why I so often wish to have a -git tree, Andrew. ;)

Why do people always thing a source code control system is magically going
to fix all bugs and wipe their ass for them?

You still have to work out which patches are relevant and merge them. If 
he's just merging a new set of changes constantly, it won't help you a damn. 

What is needed is somebody to do the grunt work, not SCM magic. I'll try to
help with Randy's suggestion of a shared pool of patches in a common dumping 
ground at least - I've needed pretty much the same thing in the past for the 
test.kernel.org stuff ... mainly fixups needed to get the tree to boot so
we can test it.

M.

Re: Wanted: hotfixes for -mm kernels

[Marc Koschewski]

* Martin J. Bligh <mbligh@mbligh.org> [2006-02-04 08:37:52 -0800]:

> 
> > > > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > > > production stuff.  It moves too fast.
> > > >
> > > > A better question is what does -mm give you that mainline does not, that
> > > > causes you to want to "stabilize" a specific -mm version?
> > > >
> > > 
> > > Some people just run -mm so the hotfixes/* would help them to get
> > > their boxes running until the next -mm without having to hunt through
> > > LKML for bugs already reported/fixed. This will allow better testing
> > > coverage because most obvious bugs are caught almost immediately and
> > > then people can continue using -mm to find more stuff.
> > 
> > ... that's just why I so often wish to have a -git tree, Andrew. ;)
> 
> Why do people always thing a source code control system is magically going
> to fix all bugs and wipe their ass for them?
> 
> You still have to work out which patches are relevant and merge them. If 
> he's just merging a new set of changes constantly, it won't help you a damn. 

We talked about hotfixes for -mm. So why not check these into the -mm-git tree
then? This would make sense and would conform fully to my understanding of what
the -mm-git tree should be. I don't want to select 23 patches from LKML to make
the tree compile or work. I want to checkout. Why make it easy when you may get
it difficult.

Besides testing the stuff we would get more far by being able to test stuff faster
(because a patch is applied to -mm and we do a checkout) instead of waiting a
week for this mega-patch to be applied.

What sense does an -mm tree make when there are people that cannot test it because of
known bugs that lead to the -mm tree not being bootable or - even worse - destroying
the system?

git is you friend. Not only for Linus' tree, but as well for Andrew's tree.
It would just make debugging and testing -mm more convenient and less time
consuming for the testers. Instead of 1000 people seeking patches Andrew would
just check in and we all could pull it.

If you agree with me or not - that's what I think.

Marc

Re: Wanted: hotfixes for -mm kernels

[Martin J. Bligh]

> We talked about hotfixes for -mm. So why not check these into the -mm-git tree
> then? This would make sense and would conform fully to my understanding of what
> the -mm-git tree should be. I don't want to select 23 patches from LKML to make
> the tree compile or work. I want to checkout. Why make it easy when you may get
> it difficult.
> 
> Besides testing the stuff we would get more far by being able to test stuff faster
> (because a patch is applied to -mm and we do a checkout) instead of waiting a
> week for this mega-patch to be applied.
> 
> What sense does an -mm tree make when there are people that cannot test it because of
> known bugs that lead to the -mm tree not being bootable or - even worse - destroying
> the system?
> 
> git is you friend. Not only for Linus' tree, but as well for Andrew's tree.
> It would just make debugging and testing -mm more convenient and less time
> consuming for the testers. Instead of 1000 people seeking patches Andrew would
> just check in and we all could pull it.
> 
> If you agree with me or not - that's what I think.

SCMs don't fix anything. The real work is in selecting patches and 
merging them. Frankly,  I test a lot of stuff myself, and the tarballs 
are  a damned sight easier to work with, and have a simple chronological 
timeline to work from.

Yes, of course you don't want to pull 23 separate patches from a mailing 
list. But quilt+tarballs is a crapload simpler than git / bk / cvs / 
subversion, and works just as well, if not better. It just needs a 
script to roll up patches into a consolidated one, and it's not like 
Andrew doesn't have that already.

M.

Re: Wanted: hotfixes for -mm kernels

[Marc Koschewski]

* Martin J. Bligh <mbligh@mbligh.org> [2006-02-04 11:22:59 -0800]:

> 
> >We talked about hotfixes for -mm. So why not check these into the -mm-git 
> >tree
> >then? This would make sense and would conform fully to my understanding of 
> >what
> >the -mm-git tree should be. I don't want to select 23 patches from LKML to 
> >make
> >the tree compile or work. I want to checkout. Why make it easy when you 
> >may get
> >it difficult.
> >
> >Besides testing the stuff we would get more far by being able to test 
> >stuff faster
> >(because a patch is applied to -mm and we do a checkout) instead of 
> >waiting a
> >week for this mega-patch to be applied.
> >
> >What sense does an -mm tree make when there are people that cannot test it 
> >because of
> >known bugs that lead to the -mm tree not being bootable or - even worse - 
> >destroying
> >the system?
> >
> >git is you friend. Not only for Linus' tree, but as well for Andrew's tree.
> >It would just make debugging and testing -mm more convenient and less time
> >consuming for the testers. Instead of 1000 people seeking patches Andrew 
> >would
> >just check in and we all could pull it.
> >
> >If you agree with me or not - that's what I think.
> 
> SCMs don't fix anything. The real work is in selecting patches and 
> merging them. Frankly,  I test a lot of stuff myself, and the tarballs 
> are  a damned sight easier to work with, and have a simple chronological 
> timeline to work from.

To me it would be easier if I could use a repository that get's updated every
day (or several times a day) than wait a week for the patch to be available.

Moreover, a repository in fact _is_ easyier when it comes to debugging than is a
tarball or such. What if one says 'Gimme that driver 6 weeks ago'? See ... with
a repository I could just get it whereas with patches I have to read lots of
mails to get a clue when stuff got applied (in the tree and over here on my hard
disk).

I didn't mean to start a discussion here. I was just telling you what is easier
for me. Anyone has it's own style of coding. Someone likes patches, others
just live with them. My boss doesn't like vi either. So I may not use it? Puh!

Marc

Re: Wanted: hotfixes for -mm kernels

[Adrian Bunk]

On Sat, Feb 04, 2006 at 07:57:39PM +0100, Marc Koschewski wrote:
> * Martin J. Bligh <mbligh@mbligh.org> [2006-02-04 08:37:52 -0800]:
> > 
> > > > > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > > > > production stuff.  It moves too fast.
> > > > >
> > > > > A better question is what does -mm give you that mainline does not, that
> > > > > causes you to want to "stabilize" a specific -mm version?
> > > > >
> > > > 
> > > > Some people just run -mm so the hotfixes/* would help them to get
> > > > their boxes running until the next -mm without having to hunt through
> > > > LKML for bugs already reported/fixed. This will allow better testing
> > > > coverage because most obvious bugs are caught almost immediately and
> > > > then people can continue using -mm to find more stuff.
> > > 
> > > ... that's just why I so often wish to have a -git tree, Andrew. ;)
> > 
> > Why do people always thing a source code control system is magically going
> > to fix all bugs and wipe their ass for them?
> > 
> > You still have to work out which patches are relevant and merge them. If 
> > he's just merging a new set of changes constantly, it won't help you a damn. 
> 
> We talked about hotfixes for -mm. So why not check these into the -mm-git tree
> then? This would make sense and would conform fully to my understanding of what
> the -mm-git tree should be. I don't want to select 23 patches from LKML to make
> the tree compile or work. I want to checkout. Why make it easy when you may get
> it difficult.
>...
> What sense does an -mm tree make when there are people that cannot test it because of
> known bugs that lead to the -mm tree not being bootable or - even worse - destroying
> the system?

That's exactly what Andrew does now implement through the hot-fixes
directory [1].

Git doesn't help for the problem that it's currently empty - it's more 
important that people tell Andrew that this or that patch should be made 
available there.

> git is you friend. Not only for Linus' tree, but as well for Andrew's tree.
> It would just make debugging and testing -mm more convenient and less time
> consuming for the testers. Instead of 1000 people seeking patches Andrew would
> just check in and we all could pull it.
>...

git is the SCM Linus developed to fit his workflow.

Andrew has a completely different workflow, and he has developed the 
tools he needs for his workflow.

As long as they are able to interact (which seems to work without 
problems), there's nothing forcing them to use the same tools.

> Marc

cu
Adrian

[1] ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc1/2.6.16-rc1-mm5/hot-fixes/

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Wanted: hotfixes for -mm kernels

[Marc Koschewski]

* Adrian Bunk <bunk@stusta.de> [2006-02-04 21:41:39 +0100]:

> On Sat, Feb 04, 2006 at 07:57:39PM +0100, Marc Koschewski wrote:
> > * Martin J. Bligh <mbligh@mbligh.org> [2006-02-04 08:37:52 -0800]:
> > > 
> > > > > > I doubt it - mm is an experimental kernel, hotfixes only make sense for
> > > > > > production stuff.  It moves too fast.
> > > > > >
> > > > > > A better question is what does -mm give you that mainline does not, that
> > > > > > causes you to want to "stabilize" a specific -mm version?
> > > > > >
> > > > > 
> > > > > Some people just run -mm so the hotfixes/* would help them to get
> > > > > their boxes running until the next -mm without having to hunt through
> > > > > LKML for bugs already reported/fixed. This will allow better testing
> > > > > coverage because most obvious bugs are caught almost immediately and
> > > > > then people can continue using -mm to find more stuff.
> > > > 
> > > > ... that's just why I so often wish to have a -git tree, Andrew. ;)
> > > 
> > > Why do people always thing a source code control system is magically going
> > > to fix all bugs and wipe their ass for them?
> > > 
> > > You still have to work out which patches are relevant and merge them. If 
> > > he's just merging a new set of changes constantly, it won't help you a damn. 
> > 
> > We talked about hotfixes for -mm. So why not check these into the -mm-git tree
> > then? This would make sense and would conform fully to my understanding of what
> > the -mm-git tree should be. I don't want to select 23 patches from LKML to make
> > the tree compile or work. I want to checkout. Why make it easy when you may get
> > it difficult.
> >...
> > What sense does an -mm tree make when there are people that cannot test it because of
> > known bugs that lead to the -mm tree not being bootable or - even worse - destroying
> > the system?
> 
> That's exactly what Andrew does now implement through the hot-fixes
> directory [1].
> 
> Git doesn't help for the problem that it's currently empty - it's more 
> important that people tell Andrew that this or that patch should be made 
> available there.
> 
> > git is you friend. Not only for Linus' tree, but as well for Andrew's tree.
> > It would just make debugging and testing -mm more convenient and less time
> > consuming for the testers. Instead of 1000 people seeking patches Andrew would
> > just check in and we all could pull it.
> >...
> 
> git is the SCM Linus developed to fit his workflow.
> 
> Andrew has a completely different workflow, and he has developed the 
> tools he needs for his workflow.
> 
> As long as they are able to interact (which seems to work without 
> problems), there's nothing forcing them to use the same tools.

I really didn't mean to 'force' anyone to use a specific tools or even type of
tool such as an 'SCM' generally. I didn't even suggest it. I just wish to have one
as I'm used to it and IMHO it makes thing easier. Applying is easier (where
'patch -p1 < ../file.patch is not really difficult either), getting back to a
specific date is easier, commenting is easier (check-in descriptions).

Moreover, just _one_ more thing which is most important at least to me:
If one can do a checkout on a daily basis with let's say 3 new patches checked
in, one can test these. The other day there are maybe another 2 new patches
applied which are to be tested. This would just speed up the testing cycle
whereas a 3 MB patch with tons of fixes and testing is just like a kick-down
with the hand-brake pulled. Sometimes I#M really overwhelmed by how many patches
came in with the recent -mm. ACPI, ALSA, VM, various FS stuff, ... It's quite
impossible to me to really test the patches in an effective manner due to having
my 2 eyes focussed on too many things at one. I do test ALSA with various types
of in/out operation while my reiserfs partition is on the way to hell. To me
that doesn't sound like effective testing.

This is just about testing and debugging time effectiveness and not about some
religious thing a la SCM vs. patches.

Marc

Re: Wanted: hotfixes for -mm kernels

[Adrian Bunk]

On Sun, Feb 05, 2006 at 10:09:59AM +0100, Marc Koschewski wrote:
> * Adrian Bunk <bunk@stusta.de> [2006-02-04 21:41:39 +0100]:
> > On Sat, Feb 04, 2006 at 07:57:39PM +0100, Marc Koschewski wrote:
>...
> > > We talked about hotfixes for -mm. So why not check these into the -mm-git tree
> > > then? This would make sense and would conform fully to my understanding of what
> > > the -mm-git tree should be. I don't want to select 23 patches from LKML to make
> > > the tree compile or work. I want to checkout. Why make it easy when you may get
> > > it difficult.
> > >...
> > > What sense does an -mm tree make when there are people that cannot test it because of
> > > known bugs that lead to the -mm tree not being bootable or - even worse - destroying
> > > the system?
> > 
> > That's exactly what Andrew does now implement through the hot-fixes
> > directory [1].
>...
> Moreover, just _one_ more thing which is most important at least to me:
> If one can do a checkout on a daily basis with let's say 3 new patches checked
> in, one can test these. The other day there are maybe another 2 new patches
> applied which are to be tested. This would just speed up the testing cycle
> whereas a 3 MB patch with tons of fixes and testing is just like a kick-down
> with the hand-brake pulled. Sometimes I#M really overwhelmed by how many patches
> came in with the recent -mm. ACPI, ALSA, VM, various FS stuff, ... It's quite
> impossible to me to really test the patches in an effective manner due to having
> my 2 eyes focussed on too many things at one. I do test ALSA with various types
> of in/out operation while my reiserfs partition is on the way to hell. To me
> that doesn't sound like effective testing.
> 
> This is just about testing and debugging time effectiveness and not about some
> religious thing a la SCM vs. patches.

Hotfixes are something that can be done.

What you suggest is not really possible.

Your thinko is:
3 new patches a day don't sum up to 3 MB after one week.

As far as I understand it, the big work for Andrew is integrating two 
dozen git repositories and at about thousand patches in a way that:
- everything applies
- the kernel compiles on several architectures
- the kernel actually runs on some machines

Andrew does all this before he releases an -mm kernel (I know due to the 
feedback he sometimes gives for patches I sent), and this is the sole 
reason why most -mm kernels are half-way usable.

Some random snapshot from Andrew's repository wouldn't help anyone, 
either it's good enough that he releases an -mm kernel or it isn't worth 
other people testing it.

> Marc

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Wanted: hotfixes for -mm kernels

[Paul Jackson]

Do we need a place to put hotfix patches, or do we just need a list of
links to lkml postings to said patches.  Such a list has the advantage
of pointing into the discussion surrounding each such fix, and such a
list has the advantage of not holding so much redundant data (these
patches will be redundant with what was posted on lkml).  Redundant
data out of context goes stale, and is less valuable.

I can imagine someone (not me ;) keeping a wiki web page, listing for
each *-mm and Linus release the particular lkml patch postings that one
needs to pick off to get a build and boot.

Just brainstorming ...

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Wanted: hotfixes for -mm kernels

[Marc Koschewski]

* Paul Jackson <pj@sgi.com> [2006-02-04 18:56:46 -0800]:

> Do we need a place to put hotfix patches, or do we just need a list of
> links to lkml postings to said patches.  Such a list has the advantage
> of pointing into the discussion surrounding each such fix, and such a
> list has the advantage of not holding so much redundant data (these
> patches will be redundant with what was posted on lkml).  Redundant
> data out of context goes stale, and is less valuable.
> 
> I can imagine someone (not me ;) keeping a wiki web page, listing for
> each *-mm and Linus release the particular lkml patch postings that one
> needs to pick off to get a build and boot.
> 
> Just brainstorming ...

That would just come closer to a repositories check-in description. I vote for
such a thing. If it is a wiki or not.

Marc

Re: Wanted: hotfixes for -mm kernels

[Martin J. Bligh]

Marc Koschewski wrote:
> * Paul Jackson <pj@sgi.com> [2006-02-04 18:56:46 -0800]:
> 
> 
>>Do we need a place to put hotfix patches, or do we just need a list of
>>links to lkml postings to said patches.  Such a list has the advantage
>>of pointing into the discussion surrounding each such fix, and such a
>>list has the advantage of not holding so much redundant data (these
>>patches will be redundant with what was posted on lkml).  Redundant
>>data out of context goes stale, and is less valuable.
>>
>>I can imagine someone (not me ;) keeping a wiki web page, listing for
>>each *-mm and Linus release the particular lkml patch postings that one
>>needs to pick off to get a build and boot.
>>
>>Just brainstorming ...
> 
> 
> That would just come closer to a repositories check-in description. I vote for
> such a thing. If it is a wiki or not.

Why have a list of pointers to go fishing for things out of an email 
archive, rather than just dump the patchs straight into a directory?
Seeing as Andrew seems to have already created a subdir to do this, the 
point seems somewhat moot by now ;-)

M.

Re: Wanted: hotfixes for -mm kernels

[Paul Jackson]

> point seems somewhat moot by now ;-)

Sure ... whatever.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

Re: Wanted: hotfixes for -mm kernels

[Chuck Ebbert]

In-Reply-To: <1138913633.15691.109.camel@mindpipe>

On Thu, 02 Feb 2006 at 15:53:52 -0500, Lee Revell wrote:

> On Thu, 2006-02-02 at 15:00 -0500, Chuck Ebbert wrote:
> > Most -mm kernels have small but critical bugs that are found shortly
> > after release.  Patches for these are posted on linux-kernel but
> > they aren't made available on kernel.org until the next -mm release.
> > 
> > Would it be possible to create a hotfix/ directory for each -mm
> > release and put those patches there?  A README could explain that
> > the fixes are untested.  At least people reading the files could
> > see an issue exists even if they're not brave enough to try the
> > patch. :)
>
> I doubt it - mm is an experimental kernel, hotfixes only make sense for
> production stuff.  It moves too fast.
>
> A better question is what does -mm give you that mainline does not, that
> causes you to want to "stabilize" a specific -mm version?

I'm talking about patches for problems that keep you from even testing
-mm, or that fix really annoying things you hit while testing.

E.g. in 2.6.16-rc1-mm4 we have:

        - SMP alternatives removes the lock prefix from instructions
          in every loaded module because it wrongly believes you are
          running an SMP kernel on UP.

        - Device-mapper mirroring is using the wrong endianness and will
          try to recover non-existent regions on the device.

        - Compiler spews hundreds of warning messages during build.

        - VGA console scrollback is totally broken because it prints
          a message on every scroll operation.

Patches for all of the above and more have been posted to the list and
I have applied them.  All I want is a place to collect them so they can
be more easily found.
-- 
Chuck

Re: Wanted: hotfixes for -mm kernels

[Andrew Morton]

Chuck Ebbert <76306.1226@compuserve.com> wrote:
>
> E.g. in 2.6.16-rc1-mm4 we have:
> 
>         - SMP alternatives removes the lock prefix from instructions
>           in every loaded module because it wrongly believes you are
>           running an SMP kernel on UP.
> 
>         - Device-mapper mirroring is using the wrong endianness and will
>           try to recover non-existent regions on the device.
> 
>         - Compiler spews hundreds of warning messages during build.
> 
>         - VGA console scrollback is totally broken because it prints
>           a message on every scroll operation.

We suck.

> Patches for all of the above and more have been posted to the list and
> I have applied them.  All I want is a place to collect them so they can
> be more easily found.

OK, I'll create a hot-fixes directory there and will try to remember to put
stuff into it.