This is just a notice to everyone that Adrian is going to now be taking
over the 2.6.16-stable kernel branch, for him to maintain for as long as
he wants to.
He will still be following the same -stable rules that are documented in
the Documentation/stable_kernel_rules.txt file, but just doing this for
the 2.6.16 kernel tree for a much longer time than the current stable
team is willing to do (we have moved on to the 2.6.17 kernel now.)
So, if you have any patches that meet the -stable requirements for the
2.6.16 kernel, please send them to him, and not the [email protected]
account, as we will just delete them.
And I'd like to offer my best wishes to Adrian for doing this work.
Personally I don't think it can be done for all that long of an amount
of time, and I will be very happy to see him prove me wrong :)
thanks,
greg k-h
On 8/3/06, Greg KH <[email protected]> wrote:
> This is just a notice to everyone that Adrian is going to now be taking
> over the 2.6.16-stable kernel branch, for him to maintain for as long as
> he wants to.
Adrian, could you provide a bit of rationale as to why you want to do
this? I'm just curious.
josh
>> This is just a notice to everyone that Adrian is going to now be taking
>> over the 2.6.16-stable kernel branch, for him to maintain for as long as
>> he wants to.
>
> Adrian, could you provide a bit of rationale as to why you want to do
> this? I'm just curious.
Competition against the "LTS" of Ubuntu, perhaps? :-)
Jan Engelhardt
--
On Thu, Aug 03, 2006 at 09:43:06PM -0500, Josh Boyer wrote:
> On 8/3/06, Greg KH <[email protected]> wrote:
> >This is just a notice to everyone that Adrian is going to now be taking
> >over the 2.6.16-stable kernel branch, for him to maintain for as long as
> >he wants to.
>
> Adrian, could you provide a bit of rationale as to why you want to do
> this? I'm just curious.
A long-term maintained stable series was missing in the current
development model.
The 2.6 series itself is theoretically a stable series, but the amount
of regressions is too big for some users.
> josh
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Sat, Aug 05, 2006 at 01:00:17AM +0200, Adrian Bunk wrote:
> On Thu, Aug 03, 2006 at 09:43:06PM -0500, Josh Boyer wrote:
> > On 8/3/06, Greg KH <[email protected]> wrote:
> > >This is just a notice to everyone that Adrian is going to now be taking
> > >over the 2.6.16-stable kernel branch, for him to maintain for as long as
> > >he wants to.
> >
> > Adrian, could you provide a bit of rationale as to why you want to do
> > this? I'm just curious.
>
> A long-term maintained stable series was missing in the current
> development model.
>
> The 2.6 series itself is theoretically a stable series, but the amount
> of regressions is too big for some users.
Greg is electing new official maintainers, but Greg is doing other
weird things as well:
http://www.cpushare.com/blog/andrea/article/42/
I'm certainly not happy with you as an official maintainer of a kernel
that could potentially be used by lot of people (I say potentially
because I doubt many would use it) given that recently you claimed to
be happy with ext2, and you discredited the great work of many people
that are testing new features and reporting feedback. I also don't
trust you to act in the interest of all parties involved in the kernel
community (given that most of them are funded by companies filing lots
of US software patents). I don't need to comment on your signature
since that's explicit enough without me needing to add anything.
On Sun, Aug 06, 2006 at 02:46:34AM +0200, Andrea Arcangeli wrote:
> On Sat, Aug 05, 2006 at 01:00:17AM +0200, Adrian Bunk wrote:
> > On Thu, Aug 03, 2006 at 09:43:06PM -0500, Josh Boyer wrote:
> > > On 8/3/06, Greg KH <[email protected]> wrote:
> > > >This is just a notice to everyone that Adrian is going to now be taking
> > > >over the 2.6.16-stable kernel branch, for him to maintain for as long as
> > > >he wants to.
> > >
> > > Adrian, could you provide a bit of rationale as to why you want to do
> > > this? I'm just curious.
> >
> > A long-term maintained stable series was missing in the current
> > development model.
> >
> > The 2.6 series itself is theoretically a stable series, but the amount
> > of regressions is too big for some users.
>
> Greg is electing new official maintainers
Greg didn't "elect" anyone, Adrian volunteered to maintain something
that had been dropped by the -stable developers and no one else was
going to maintain.
> , but Greg is doing other
> weird things as well:
>
> http://www.cpushare.com/blog/andrea/article/42/
I'm only repeating what a whole lot of lawyers told me, nothing else.
thanks,
greg k-h
Hi Adrian,
On Sat, Aug 05, 2006 at 01:00:17AM +0200, Adrian Bunk wrote:
> On Thu, Aug 03, 2006 at 09:43:06PM -0500, Josh Boyer wrote:
> > On 8/3/06, Greg KH <[email protected]> wrote:
> > >This is just a notice to everyone that Adrian is going to now be taking
> > >over the 2.6.16-stable kernel branch, for him to maintain for as long as
> > >he wants to.
> >
> > Adrian, could you provide a bit of rationale as to why you want to do
> > this? I'm just curious.
>
> A long-term maintained stable series was missing in the current
> development model.
>
> The 2.6 series itself is theoretically a stable series, but the amount
> of regressions is too big for some users.
Well, I really wish you success on this project. I completely agree on the
need of a 2.4-like model to stabilize one branch of 2.6, and you probably
remember that we've been talking about this 1 or 2 years ago, when I found
it too hard to be started alone. It takes a very long time but apparently
succeeds in the long term. I think it will quickly become a hard work because
patches will get harder and harder to apply, and sometimes you'll have to
adapt them a lot. But there's nothing impossible, I've been backporting
fixes from 2.6 to 2.4 for a long time, so 2.6 to 2.6 should be feasible.
However, I hope that you realize that (if you succeed), your work might
become a basis for some distros, as well as for some admins who will try
to switch from 2.4 to 2.6. I mean, people will be *relying* on you to get
fixes.
But for this, you will have to be seen as a serious person, and avoid
childish fighting with other kernel developpers, such as this :
> Gentoo kernels are 42 times more popular than SUSE kernels among
> KLive users (a service by SUSE contractor Andrea Arcangeli that
> gathers data about kernels from many users worldwide).
People who know the history will take this a as the teenager trying to
take revenge on the other guy who stole his girlfriend, and people not
aware of the history will take this for Gentoo advertisement based on
the work of your good friend Andrea who is so much honnest that he doesn't
mind publishing such results. In both cases, I think this is not what
you're looking for, and it does not make you look like the serious guy
on whom we can rely to get a stable kernel. At best, it will be used to
show that Andrea is unbiased, which is exactly what is expected for the
role you're taking.
And BTW, you'll look ridiculous when you'll post changelogs which will
start with fixes from Andrea and will end with this signature ! Or maybe
you'll decide to refuse his patches, which is a dangerous game when the
original goal is to stabilize some code. I hope that everyone will grow
up in order not to tarnish linux's image. There are already a few debian
extremists to make us look like immature geeks in enterprise contexts,
I think we don't need more of this.
Best wishes with 2.6.16,
Willy
Hi!
Thanks for doing this.
I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
it still queued or should I resend?
Pavel
--
Thanks for all the (sleeping) penguins.
On Mon, Aug 07, 2006 at 12:40:44PM +0000, Pavel Machek wrote:
> Hi!
>
> Thanks for doing this.
>
> I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> it still queued or should I resend?
Nothing is queued in the 2.6.16-stable tree right now, Adrian is
starting with a blank list.
I'd suggest resending it to him.
thanks,
greg k-h
On Mon, Aug 07, 2006 at 12:40:44PM +0000, Pavel Machek wrote:
> Hi!
>
> Thanks for doing this.
>
> I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> it still queued or should I resend?
Is this "pdflush: handle resume wakeups"?
> Pavel
cu
Adrian
--
Gentoo kernels are 42 times more popular than SUSE kernels among
KLive users (a service by SUSE contractor Andrea Arcangeli that
gathers data about kernels from many users worldwide).
There are three kinds of lies: Lies, Damn Lies, and Statistics.
Benjamin Disraeli
On Mon 2006-08-07 19:59:39, Adrian Bunk wrote:
> On Mon, Aug 07, 2006 at 12:40:44PM +0000, Pavel Machek wrote:
>
> > Hi!
> >
> > Thanks for doing this.
> >
> > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > it still queued or should I resend?
>
> Is this "pdflush: handle resume wakeups"?
Yes. Do you have it somewhere or should I dig it up?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Aug 08, 2006 at 01:30:46AM +0200, Pavel Machek wrote:
> On Mon 2006-08-07 19:59:39, Adrian Bunk wrote:
> > On Mon, Aug 07, 2006 at 12:40:44PM +0000, Pavel Machek wrote:
> >
> > > Hi!
> > >
> > > Thanks for doing this.
> > >
> > > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > > it still queued or should I resend?
> >
> > Is this "pdflush: handle resume wakeups"?
>
> Yes. Do you have it somewhere or should I dig it up?
I've applied it.
> Pavel
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
In-Reply-To: <[email protected]>
On Tue, 8 Aug 2006 21:55:10 +0200, Adrian Bunk wrote:
> > > > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > > > it still queued or should I resend?
> > >
> > > Is this "pdflush: handle resume wakeups"?
> >
> > Yes. Do you have it somewhere or should I dig it up?
>
> I've applied it.
Umm, is there some place we can check to see what you've applied?
I sent you "tty: serialize flush_to_ldisc" and I've got a few more
but I don't want to duplicate what you already have.
--
Chuck
On Wed, Aug 09, 2006 at 05:45:53PM -0400, Chuck Ebbert wrote:
> In-Reply-To: <[email protected]>
>
> On Tue, 8 Aug 2006 21:55:10 +0200, Adrian Bunk wrote:
>
> > > > > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > > > > it still queued or should I resend?
> > > >
> > > > Is this "pdflush: handle resume wakeups"?
> > >
> > > Yes. Do you have it somewhere or should I dig it up?
> >
> > I've applied it.
>
> Umm, is there some place we can check to see what you've applied?
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> I sent you "tty: serialize flush_to_ldisc" and I've got a few more
> but I don't want to duplicate what you already have.
Sorry that I hadn't answered your email.
That patch is in 2.6.17.8, and I will look at it since I'm currently
going through all 2.6.17.7 and 2.6.17.8 patches looking for patches I
should apply.
> Chuck
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
On Thu, Aug 10, 2006 at 12:00:49AM +0200, Adrian Bunk wrote:
> On Wed, Aug 09, 2006 at 05:45:53PM -0400, Chuck Ebbert wrote:
> > In-Reply-To: <[email protected]>
> >
> > On Tue, 8 Aug 2006 21:55:10 +0200, Adrian Bunk wrote:
> >
> > > > > > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > > > > > it still queued or should I resend?
> > > > >
> > > > > Is this "pdflush: handle resume wakeups"?
> > > >
> > > > Yes. Do you have it somewhere or should I dig it up?
> > >
> > > I've applied it.
> >
> > Umm, is there some place we can check to see what you've applied?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
No, I would not use the main git tree to queue patches up. What happens
when you want to rip the middle one out because in review it turns out
that it is incorrect?
Please use a quilt tree of patches instead, and then only commit the
patches when you do a release. It's much simpler that way.
thanks,
greg k-h
On Wed, Aug 09, 2006 at 03:18:54PM -0700, Greg KH wrote:
> On Thu, Aug 10, 2006 at 12:00:49AM +0200, Adrian Bunk wrote:
> > On Wed, Aug 09, 2006 at 05:45:53PM -0400, Chuck Ebbert wrote:
> > > In-Reply-To: <[email protected]>
> > >
> > > On Tue, 8 Aug 2006 21:55:10 +0200, Adrian Bunk wrote:
> > >
> > > > > > > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > > > > > > it still queued or should I resend?
> > > > > >
> > > > > > Is this "pdflush: handle resume wakeups"?
> > > > >
> > > > > Yes. Do you have it somewhere or should I dig it up?
> > > >
> > > > I've applied it.
> > >
> > > Umm, is there some place we can check to see what you've applied?
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
>
> No, I would not use the main git tree to queue patches up. What happens
> when you want to rip the middle one out because in review it turns out
> that it is incorrect?
git-revert
> Please use a quilt tree of patches instead, and then only commit the
> patches when you do a release. It's much simpler that way.
The way I'm doing it it's more the way the 2.4 and 2.6 trees work than
how the -stable tree works.
I prefer it the way I'm doing it.
If it turns out I was wrong I can always switch to a quilt tree.
> thanks,
>
> greg k-h
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
On Thu, Aug 10, 2006 at 12:45:29AM +0200, Adrian Bunk wrote:
> On Wed, Aug 09, 2006 at 03:18:54PM -0700, Greg KH wrote:
> > On Thu, Aug 10, 2006 at 12:00:49AM +0200, Adrian Bunk wrote:
> > > On Wed, Aug 09, 2006 at 05:45:53PM -0400, Chuck Ebbert wrote:
> > > > In-Reply-To: <[email protected]>
> > > >
> > > > On Tue, 8 Aug 2006 21:55:10 +0200, Adrian Bunk wrote:
> > > >
> > > > > > > > I believe I had 'fix pdflush after suspend' queued in Greg's tree. Is
> > > > > > > > it still queued or should I resend?
> > > > > > >
> > > > > > > Is this "pdflush: handle resume wakeups"?
> > > > > >
> > > > > > Yes. Do you have it somewhere or should I dig it up?
> > > > >
> > > > > I've applied it.
> > > >
> > > > Umm, is there some place we can check to see what you've applied?
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> >
> > No, I would not use the main git tree to queue patches up. What happens
> > when you want to rip the middle one out because in review it turns out
> > that it is incorrect?
>
> git-revert
Ok, fair enough, but it messes with the changelogs a bunch.
> > Please use a quilt tree of patches instead, and then only commit the
> > patches when you do a release. It's much simpler that way.
>
> The way I'm doing it it's more the way the 2.4 and 2.6 trees work than
> how the -stable tree works.
>
> I prefer it the way I'm doing it.
>
> If it turns out I was wrong I can always switch to a quilt tree.
Ok, it's your tree, you can mess with it as you like, just trying to
pass along a little advice from someone who has been there before... :)
good luck,
greg k-h
* Greg KH ([email protected]) wrote:
> On Thu, Aug 10, 2006 at 12:45:29AM +0200, Adrian Bunk wrote:
> > > No, I would not use the main git tree to queue patches up. What happens
> > > when you want to rip the middle one out because in review it turns out
> > > that it is incorrect?
> >
> > git-revert
>
> Ok, fair enough, but it messes with the changelogs a bunch.
You can always keep it all on a "pending" branch, and cherrypick if
needed (instead of straight merge if you needed to drop something) to
keep the final changelogs sane.
thanks,
-chris
Greg KH schrieb:
> On Thu, Aug 10, 2006 at 12:00:49AM +0200, Adrian Bunk wrote:
>> On Wed, Aug 09, 2006 at 05:45:53PM -0400, Chuck Ebbert wrote:
>>> Umm, is there some place we can check to see what you've applied?
>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
>
> No, I would not use the main git tree to queue patches up. What happens
> when you want to rip the middle one out because in review it turns out
> that it is incorrect?
You can have multiple branches in one git repository. E.g. git's own
repository has a "master" branch containing all committed changes, a
"next" branch which is similar to a release candidate and is regularly
merged back into "master" if ready, and a "pu" branch which contains the
more experimental stuff. The latter doesn't even have a continuous history.
And it has other branches containing different stuff, e.g. "man" is a
special branch containing the generated manpages. You could also have
topic branches or one branch per submitter, or whatever.
> Please use a quilt tree of patches instead, and then only commit the
> patches when you do a release. It's much simpler that way.
There's even a quilt clone based on git (http://www.procode.org/stgit/).
I have never used it, though, so I can't comment on it.
That said, it's a good idea to keep the master branch continuous, i.e.
never delete it or reset it to some previous commit. So, as you
suggest, have a staging area for patches and only commit the good ones
to your master branch. You can use a branch in the same repo as staging
area, though.
You can do quite a lot of different things with just one git repository.
:-D
Ren?
Adrian Bunk wrote:
...
> I'm currently
> going through all 2.6.17.7 and 2.6.17.8 patches looking for patches I
> should apply.
Suggested updates for drivers/ieee1394/:
(from 2.6.17.2)
Fix broken suspend/resume in ohci1394
should be applicable as-is. This does not add full suspend/resume
functionality to ohci1394 but it fixes fatal side effects on other
on-board hardware after resume.
(from 2.6.17.8)
ieee1394: sbp2: enable auto spin-up for Maxtor disks
doesn't apply to 2.6.16 as-is.
https://bugzilla.novell.com/show_bug.cgi?id=183011#c6 has an adapted
version. I will mail it to you with proper description and signed-off-by
later today. While I am at it, I will resend that ohci1394 patch too.
I have a related question about your plans with Linux 2.6.16.yy.
Documentation/stable_kernel_rules.txt says:
- It must fix a problem that causes a build error (but not for things
marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
security issue, or some "oh, that's not good" issue. In short,
something critical.
I plan to submit a patch of the kind "fix recognition of a quirky
device" for 2.6.18. That patch does not fix an oops, hang, data
corruption, or security hole. (The patch will fulfill all other criteria
from stable_kernel_rules.) Do you consider "can't use that shiny device
under Linux" as "oh, that's not good" in the context of Linux 2.6.16.yy?
(I will not submit that patch for 2.6.17.y. I suppose I also wouldn't
submit it for 2.6.18.1 if it came too late for 2.8.18. One reason for me
to hesitate is because people who are able to patch their kernel can
already get fully up-to-date ieee1394 drivers from me for kernels as old
as 2.6.14.)
--
Stefan Richter
-=====-=-==- =--- -=-=-
http://arcgraph.de/sr/
Date: Mon, 22 May 2006 16:57:16 -0600
From: Robert Hancock <[email protected]>
Subject: Fix broken suspend/resume in ohci1394 (Was: ACPI suspend problems revisited)
I've been experimenting to track down the cause of suspend/resume problems
on my Compaq Presario X1050 laptop:
http://bugzilla.kernel.org/show_bug.cgi?id=6075
Essentially the ACPI Embedded Controller and keyboard controller would
get into a bizarre, confused state after resume.
I found that unloading the ohci1394 module before suspend and reloading it
after resume made the problem go away. Diffing the dmesg output from
resume, with and without the module loaded, I found that with the module
loaded I was missing these:
PM: Writing back config space on device 0000:02:00.0 at offset 1. (Was 2100080, writing 2100007)
PM: Writing back config space on device 0000:02:00.0 at offset 3. (Was 0, writing 8008)
PM: Writing back config space on device 0000:02:00.0 at offset 4. (Was 0, writing 90200000)
PM: Writing back config space on device 0000:02:00.0 at offset 5. (Was 1, writing 2401)
PM: Writing back config space on device 0000:02:00.0 at offset f. (Was 20000100, writing 2000010a)
The default PCI driver performs the pci_restore_state when no driver is
loaded for the device. When the ohci1394 driver is loaded, it is supposed
to do this, however it appears not to do so.
I created the patch below and tested it, and it appears to resolve the
suspend problems I was having with the module loaded. I only added in the
pci_save_state and pci_restore_state - however, though I know little of
this hardware, surely the driver should really be doing more than this when
suspending and resuming? Currently it does almost nothing, what if there
are commands in progress, etc?
Signed-off-by: Robert Hancock <[email protected]>
Signed-off-by: Stefan Richter <[email protected]>
---
This patch also appeared in 2.6.17.2 and 2.6.18. There is still some
functionality missing for full resume capability in ohci1394.
Index: linux-2.6.16.27/drivers/ieee1394/ohci1394.c
===================================================================
--- linux-2.6.16.27.orig/drivers/ieee1394/ohci1394.c 2006-08-10 18:10:13.000000000 +0200
+++ linux-2.6.16.27/drivers/ieee1394/ohci1394.c 2006-08-10 18:11:45.000000000 +0200
@@ -3536,6 +3536,7 @@ static int ohci1394_pci_resume (struct p
}
#endif /* CONFIG_PPC_PMAC */
+ pci_restore_state(pdev);
pci_enable_device(pdev);
return 0;
@@ -3555,6 +3556,8 @@ static int ohci1394_pci_suspend (struct
}
#endif
+ pci_save_state(pdev);
+
return 0;
}
At least Maxtor OneTouch III require a "start stop unit" command after
auto spin-down before the next access can proceed. This patch activates
the responsible code in scsi_mod for all Maxtor SBP-2 disks.
https://bugzilla.novell.com/show_bug.cgi?id=183011
Maybe that should be done for all SBP-2 disks, but better be cautious.
Signed-off-by: Stefan Richter <[email protected]>
---
This patch also appeared in 2.6.17.8 and 2.6.18.
Index: linux-2.6.16.27/drivers/ieee1394/sbp2.c
===================================================================
--- linux-2.6.16.27.orig/drivers/ieee1394/sbp2.c 2006-08-10 18:10:13.000000000 +0200
+++ linux-2.6.16.27/drivers/ieee1394/sbp2.c 2006-08-10 18:18:54.000000000 +0200
@@ -2505,6 +2505,9 @@ static int sbp2scsi_slave_configure(stru
SBP2_INFO("enabling iPod workaround: decrement disk capacity");
sdev->fix_capacity = 1;
}
+ if (scsi_id->ne->guid_vendor_id == 0x0010b9 && /* Maxtor's OUI */
+ (sdev->type == TYPE_DISK || sdev->type == TYPE_RBC))
+ sdev->allow_restart = 1;
return 0;
}
On Thu, Aug 10, 2006 at 01:57:13PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> ...
> > I'm currently
> > going through all 2.6.17.7 and 2.6.17.8 patches looking for patches I
> > should apply.
>
> Suggested updates for drivers/ieee1394/:
>
> (from 2.6.17.2)
> Fix broken suspend/resume in ohci1394
> should be applicable as-is. This does not add full suspend/resume
> functionality to ohci1394 but it fixes fatal side effects on other
> on-board hardware after resume.
>
> (from 2.6.17.8)
> ieee1394: sbp2: enable auto spin-up for Maxtor disks
> doesn't apply to 2.6.16 as-is.
> https://bugzilla.novell.com/show_bug.cgi?id=183011#c6 has an adapted
> version. I will mail it to you with proper description and signed-off-by
> later today. While I am at it, I will resend that ohci1394 patch too.
Thanks, I've applied them both.
> I have a related question about your plans with Linux 2.6.16.yy.
> Documentation/stable_kernel_rules.txt says:
>
> - It must fix a problem that causes a build error (but not for things
> marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> security issue, or some "oh, that's not good" issue. In short,
> something critical.
>
> I plan to submit a patch of the kind "fix recognition of a quirky
> device" for 2.6.18. That patch does not fix an oops, hang, data
> corruption, or security hole. (The patch will fulfill all other criteria
> from stable_kernel_rules.) Do you consider "can't use that shiny device
> under Linux" as "oh, that's not good" in the context of Linux 2.6.16.yy?
>...
If the device doesn't work, it's an "oh, that's not good" issue. ;-)
More seriously:
I consider stable_kernel_rules.txt as a more formal description of
"avoid regressions".
If the patch is tested, unlikely to break anything and included in
Linus' tree it's a candidate for 2.6.16.
> Stefan Richter
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
On Sat, Aug 05, 2006 at 09:52:34PM -0700, Greg KH wrote:
> Greg didn't "elect" anyone, Adrian volunteered to maintain something
> that had been dropped by the -stable developers and no one else was
> going to maintain.
Did you ever call for a maintainer list of volunteers?
To me an official 2.6.16-stable in the hands of the only guy who
proposed himself as maintainer, sounds worse than no stable tree at
all. People won't know anymore if to run Greg's 2.6.18-stable or
2.6.16-stable.
If a 2.6-real-stable tree has to happen because 2.6-stable is not
really stable/trustable enough, then give it up with your
2.6.18-stable and start doing 2.7 and leave 2.6 in the hands of
somebody else.
An official kernel needs a critical mass to have a value, it's simply
a wasted effort to open yet another official tree that will actually
fragment the "production" userbase even more.
If 2.6.18-stable is sustainable with the current model, with the
distro folks being the only ones forking off a real-stable tree, then
you should drop 2.6.16-stable. If instead it's 2.6.18-stable that is
not good enough for production usage and people really needs
2.6.16-stable, you should open 2.7, and not fragment the userbase like
this.
I think it would be great to have the users choosing their preferred
maintainer to end the era of maintainers being decided by other
maintainers like you actually did. A simple website on kernel.org can
achieve it, where users can registers for voting and the maintainers
willing to maintain 2.6-stable can registers themself too. That's at
least less random than the current status if what you said above is
true and if 2.6.16-stable is meant to reach any critical mass.
Ar Llu, 2006-08-21 am 00:30 +0200, ysgrifennodd Andrea Arcangeli:
> On Sat, Aug 05, 2006 at 09:52:34PM -0700, Greg KH wrote:
> > Greg didn't "elect" anyone, Adrian volunteered to maintain something
> > that had been dropped by the -stable developers and no one else was
> > going to maintain.
>
> Did you ever call for a maintainer list of volunteers?
That isn't the normal way of doing things around here. Linus has always
taken the approach of picking who he trusts to hand stuff onto, as have
others when handing on further.
> To me an official 2.6.16-stable in the hands of the only guy who
> proposed himself as maintainer, sounds worse than no stable tree at
> all.
2.6.16-stable is in the hands of someone that Greg (2.6.17-stable, ex
2.6.16-stable, 2.6 head temporary chief maintainer) thinks is a good
person to do the job. That sounds to me quite sensible selection
criteria, and Adrian is certainly up to the job.
Alan
On Mon, 21 Aug 2006 00:30:46 +0200
Andrea Arcangeli <[email protected]> wrote:
> I think it would be great to have the users choosing their preferred
> maintainer to end the era of maintainers being decided by other
> maintainers like you actually did. A simple website on kernel.org can
> achieve it, where users can registers for voting and the maintainers
> willing to maintain 2.6-stable can registers themself too. That's at
> least less random than the current status if what you said above is
> true and if 2.6.16-stable is meant to reach any critical mass.
There's no need for a vote. Users already vote for a maintainer when
they decide to use a paticular kernel tree.
No user is forced to follow a particular maintainer. And anyone can step
up and declare that they are also offering a maintained tree.
And this situation is already self correcting; if no users follow, it's
unlikely that a maintainer will continue doing the required work. And
if a maintainer doesn't do a satisfactory job, it's very unlikely many
people will choose to use that tree.
Sean
On Sun, Aug 20, 2006 at 06:51:23PM -0400, Sean wrote:
> There's no need for a vote. Users already vote for a maintainer when
> they decide to use a paticular kernel tree.
>
> No user is forced to follow a particular maintainer. And anyone can step
> up and declare that they are also offering a maintained tree.
I never said that 2.6.16-stable is going to succeed, all I'm saying is
that all testing done on it will be a wasted effort, that's why there
are no infinite competing trees. So one would hope that an official
maintainer isn't choosed by random.
> And this situation is already self correcting; if no users follow, it's
The real ironic thing, is that the only feedback he has to know if
users follow or not, is KLive. Which I'm going to shutdown anyway if
nothing changes w.r.t. 2.6.16-stable since I'm not out to fight with
anyone, I don't even have a degree in statistics, so it's up to the
thousands getting a degree in statistics every year to argue with the
-stable maintainers, certainly not me.
On Mon, Aug 21, 2006 at 12:05:02AM +0100, Alan Cox wrote:
> That isn't the normal way of doing things around here. Linus has always
> taken the approach of picking who he trusts to hand stuff onto, as have
> others when handing on further.
That doesn't make it right or better than what I proposed. Furthermore
if Greg is so sure that nobody else will be willing to maintain
2.6.16-stable what I proposed will lead to the very same result of the
current model, and then obviously there would be nothing left to argue
about.
On Mon, Aug 21, 2006 at 01:15:10AM +0200, Andrea Arcangeli wrote:
> On Sun, Aug 20, 2006 at 06:51:23PM -0400, Sean wrote:
>...
> > And this situation is already self correcting; if no users follow, it's
>
> The real ironic thing, is that the only feedback he has to know if
> users follow or not, is KLive.
>...
If I was interested in statistics, I could also use [1] that shows
statistics about running kernels automatically submitted my nearly ten
times as many machines than in KLive.
2.6.16.27 is the latest 2.6.16 kernel, available for more than one month.
KLive says no KLive user is using 2.6.16.27.
[1] says 0.2% of the machines reporting there are using 2.6.16.27.
If I was believing in such statistics, there was no 2.6.16 branch.
The important feedback are emails from people reporting a bug or saying
"thank you".
This branch is an offer.
If it runs on millions of computers that's OK.
If it's used only by few people that's OK.
cu
Adrian
[1] http://counter.li.org/reports/systemstats.php
--
"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
On Mon, Aug 21, 2006 at 01:15:10AM +0200, Andrea Arcangeli wrote:
> On Sun, Aug 20, 2006 at 06:51:23PM -0400, Sean wrote:
> > There's no need for a vote. Users already vote for a maintainer when
> > they decide to use a paticular kernel tree.
> >
> > No user is forced to follow a particular maintainer. And anyone can step
> > up and declare that they are also offering a maintained tree.
>
> I never said that 2.6.16-stable is going to succeed, all I'm saying is
> that all testing done on it will be a wasted effort, that's why there
> are no infinite competing trees.
Andrea, I don't agree with you on this.
If 2.6.16 succeeds, some people who currently cannot rely on 2.6 due
to its code changing too fast will be able to make the move. Also, those
who need a good reliability will be able to check in one year if they
consider it reliable enough for their use, based on other user's feedback.
Once those users depend on this kernel, they will probably send fixes
back when they'll find a bug. Right now, many people using 2.6 just
run it off the CD of their pet distro, and when something goes wrong,
they decide the distro is broken and they change to anything else
(which might have a different kernel version). Do not believe that
everyone has enough knowledge to send valuable bug reports and/or
fix bugs. Basically, you have them all reading this list on a somewhat
regular basis.
> So one would hope that an official
> maintainer isn't choosed by random.
>
> > And this situation is already self correcting; if no users follow, it's
>
> The real ironic thing, is that the only feedback he has to know if
> users follow or not, is KLive. Which I'm going to shutdown anyway if
> nothing changes w.r.t. 2.6.16-stable since I'm not out to fight with
> anyone, I don't even have a degree in statistics, so it's up to the
> thousands getting a degree in statistics every year to argue with the
> -stable maintainers, certainly not me.
Well, you've been fighting over opinions. Both of you have been a bit
rude with the other one. Adrian has finally removed his mocking (and
IMHO childish) signature. Why don't you consider the problem solved
and keep your project online ?
Willy
From: Alan Cox <[email protected]>
Date: Mon, 21 Aug 2006 00:05:02 +0100
> Ar Llu, 2006-08-21 am 00:30 +0200, ysgrifennodd Andrea Arcangeli:
> > To me an official 2.6.16-stable in the hands of the only guy who
> > proposed himself as maintainer, sounds worse than no stable tree at
> > all.
>
> 2.6.16-stable is in the hands of someone that Greg (2.6.17-stable, ex
> 2.6.16-stable, 2.6 head temporary chief maintainer) thinks is a good
> person to do the job. That sounds to me quite sensible selection
> criteria, and Adrian is certainly up to the job.
Totally agreed.
This voting idea is absolute nonsense.
There is a tree of trust, and responsibilities like this are
simply handed down.
On Sun, Aug 20, 2006 at 11:21:21PM -0700, David S. Miller wrote:
> There is a tree of trust, and responsibilities like this are
> simply handed down.
That works as long as you trust and you are ok with every leaf of the
tree. I'm not, both a developer and more important as an user.
I beg to remind you why Marcelo was picked, not only for his skills,
but also because he was so universally friendly, and easy to talk
with. I couldn't imagine Marcelo wanting to hurt anyone. To me that's
important, I could never disagree with the Marcelo pick. But this is
basically the opposite in my view. A maintainer needs qualities that
go beyond technical skills. I think it's Greg's fault of course, I'm
not blaming anybody else, but this clearly shows that the tree of
trust has its limits, hence I'd like a different system to elect the
new maintainers that has a better chance to work.
On Mon, Aug 21, 2006 at 02:05:00AM +0200, Willy Tarreau wrote:
> [..] Adrian has finally removed his mocking (and
> IMHO childish) signature. Why don't you consider the problem solved
> and keep your project online ?
http://marc.theaimsgroup.com/?l=linux-kernel&m=115611817104179&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=115592383000732&w=2
Here also a link sent to me from a KLive supporter:
http://en.wikipedia.org/wiki/W._Edwards_Deming
If I was to follow my emotions and my financial interest, KLive would
be down already.
Andrea Arcangeli schrieb am 2006-08-21:
> I beg to remind you why Marcelo was picked, not only for his skills,
> but also because he was so universally friendly, and easy to talk
> with. I couldn't imagine Marcelo wanting to hurt anyone. To me that's
> important, I could never disagree with the Marcelo pick. But this is
> basically the opposite in my view. A maintainer needs qualities that
> go beyond technical skills. I think it's Greg's fault of course, I'm
> not blaming anybody else, but this clearly shows that the tree of
> trust has its limits, hence I'd like a different system to elect the
> new maintainers that has a better chance to work.
I still liked your semi-technical reasons better than the personal.
--
Matthias Andree
On Mon 2006-08-21 11:35:38, Andrea Arcangeli wrote:
> On Sun, Aug 20, 2006 at 11:21:21PM -0700, David S. Miller wrote:
> > There is a tree of trust, and responsibilities like this are
> > simply handed down.
>
> That works as long as you trust and you are ok with every leaf of the
> tree. I'm not, both a developer and more important as an user.
As an user, that's not your problem.
As a developer, if you don't like Adrian doing that, perhaps you
should have volunteered to maintain it yourself. Or you can work with
Adrian to make sure he does nothing strange.
But I think Adrian is very good person to do this, and with strong
review process in place we currently have.... I don't see what the
problem is.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html