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
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
On 2/2/06, Lee Revell <[email protected]> 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
On Thu, 2 Feb 2006, Dmitry Torokhov wrote:
> On 2/2/06, Lee Revell <[email protected]> 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
On 2/2/06, Randy.Dunlap <[email protected]> wrote:
> On Thu, 2 Feb 2006, Dmitry Torokhov wrote:
>
> > On 2/2/06, Lee Revell <[email protected]> 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
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
Chuck Ebbert <[email protected]> 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.
* Dmitry Torokhov <[email protected]> [2006-02-02 16:45:52 -0500]:
> On 2/2/06, Lee Revell <[email protected]> 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
> > > 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.
* Martin J. Bligh <[email protected]> [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
> 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.
On Sat, Feb 04, 2006 at 07:57:39PM +0100, Marc Koschewski wrote:
> * Martin J. Bligh <[email protected]> [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
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 <[email protected]> 1.925.600.0401
* Martin J. Bligh <[email protected]> [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
* Paul Jackson <[email protected]> [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
* Adrian Bunk <[email protected]> [2006-02-04 21:41:39 +0100]:
> On Sat, Feb 04, 2006 at 07:57:39PM +0100, Marc Koschewski wrote:
> > * Martin J. Bligh <[email protected]> [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
On Sun, Feb 05, 2006 at 10:09:59AM +0100, Marc Koschewski wrote:
> * Adrian Bunk <[email protected]> [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
Marc Koschewski wrote:
> * Paul Jackson <[email protected]> [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.
> point seems somewhat moot by now ;-)
Sure ... whatever.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.925.600.0401