Re: Linux 2.6.0 (ACPI)

Re: Linux 2.6.0 (ACPI)

[Len Brown]

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt

We have 88 open bugs against ACPI (out of 216 total).  They fall into
two broad categories -- boot/configuration (eg. interrupt issues); and
run-time features (eg. acpi events -- power-down, fan control etc). 
#1038 mentioned here has sort of grown out of control into "anything at
all wrong with anybody's IBM T40", so I'm not sure it will ever be
completely closed;-)

I agree with Andy Grover's comments in this file that fixing the bugs
one by one in the current design is the highest priority; and I think
that strategy is showing positive results.

>   fixes appear in Andrew Morton's "-mm" tree, at
> 
>         ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
> 

Now that you're back, we should probably pull the current 2.6.0 ACPI
patch into the mm tree, since 2.6 without it is now somewhat behind
2.4.23.

I understand that consolidated plain patches are preferred for the mm
tree.  I assume that the actual pull into the release tree can still be
done using bk so that we can preserve the individual csets and their
comments?

> Some active subsystem mailing lists
>   are:

>         linux-acpi@intel.com

acpi-devel@lists.sourceforge.net is preferred -- it includes the Intel
alias above plus the rest of planet ACPI.

thanks,
-Len

Re: Linux 2.6.0 (ACPI)

[Jeff Garzik]

Len Brown wrote:
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt
> 
> 
> We have 88 open bugs against ACPI (out of 216 total).  They fall into
> two broad categories -- boot/configuration (eg. interrupt issues); and
> run-time features (eg. acpi events -- power-down, fan control etc). 
> #1038 mentioned here has sort of grown out of control into "anything at
> all wrong with anybody's IBM T40", so I'm not sure it will ever be
> completely closed;-)


hehe

Pete Zaitcev gave me some great advice, when I joined Red Hat.  Manage 
your bugs aggressively, sometimes with a sharp and pointy stick. 
Otherwise they will become unkillable nine-headed hydra with a life of 
their own, as the bugs drift further and further away from the original 
bug reporter's bug.  ;-)  Open new bugs if a poster's issue seems 
remotely different from the base bug.  Bugzilla can do fancy stuff like 
linking bugs into dependency chains, and also marking bugs as 
duplicates.  The power is yours :)

	Jeff

Re: Linux 2.6.0 (ACPI)

[Andrew Morton]

Len Brown <len.brown@intel.com> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/must-fix/should-fix-7.txt
> 
> We have 88 open bugs against ACPI (out of 216 total).

Poor Len ;)

> They fall into
> two broad categories -- boot/configuration (eg. interrupt issues); and
> run-time features (eg. acpi events -- power-down, fan control etc). 
> #1038 mentioned here has sort of grown out of control into "anything at
> all wrong with anybody's IBM T40", so I'm not sure it will ever be
> completely closed;-)
> 
> I agree with Andy Grover's comments in this file that fixing the bugs
> one by one in the current design is the highest priority; and I think
> that strategy is showing positive results.

Great.

> >   fixes appear in Andrew Morton's "-mm" tree, at
> > 
> >         ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
> > 
> 
> Now that you're back, we should probably pull the current 2.6.0 ACPI
> patch into the mm tree, since 2.6 without it is now somewhat behind
> 2.4.23.
> 
> I understand that consolidated plain patches are preferred for the mm
> tree.

They're easiest for me, but a bitkeeper pull is OK too.

>  I assume that the actual pull into the release tree can still be
> done using bk so that we can preserve the individual csets and their
> comments?

Well..  If you have isolated patches which are confirmed to fix the problem
then there is no benefit in staging these changes in -mm: just merge them
up.   It depends upon your confidence level, really.