Detecting exploding batteries, part 2

Richard Hughes hughsient at gmail.com
Mon Sep 25 03:25:58 PDT 2006


On 25/09/06, Bastien Nocera <hadess at hadess.net> wrote:
> On Mon, 2006-09-25 at 11:02 +0100, Richard Hughes wrote:
> > On 25/09/06, Danny Kukawka <danny.kukawka at web.de> wrote:
> > > On Monday 25 September 2006 09:19, Richard Hughes wrote:
> > > > 1. Vendors (Redhat/Suse) can send out updates to a HAL package in a
> > > > matter of days.
> > >
> > > 1.) take a look at the release cycle of HAL
> > > 2.) take a look at the release cycle of the distributions (6 months - 1 year
> > > or more for business products)
> > > 3.) take a look at the rules for updates of the distributions. For SUSE e.g.
> > > we only offer official updates for (security) bugs and not for such stuff. No
> > > distribution send out a update for such stuff.
> >
> > Well, that's SuSe policy. I can tell you for 100% certainty that
> > *every* affected user will not have realised before the 6 months
> > next-release of HAL (and that's if the distro can't roll a trivial
> > update).
>
> I agree with Danny on some points. I think whether the batteries need a
> recall, and this sort of thing shouldn't be in HAL.
>
> But I would certainly agree that putting the serial number of the
> batteries in HAL, and the "policy" code (what to do with the battery
> serial) in g-p-m is a good idea.

David, up to you.

I figured sticking this in HAL rather than g-p-m gave other policy
daemons a chance to grab the data, and it would reuse the existing xml
matching code in HAL (rather than add this to g-p-m as well).

I'm happy to do this either way.

Richard.


More information about the hal mailing list