Re: RE: Re: making progress with ACPI was: ACPI small patch up date

Re: RE: Re: making progress with ACPI was: ACPI small patch up date

[joerg.beyer-htSm2yLGOjU]

Huw Hawkins <hrhawk-JGs/UdohzUI@public.gmane.org> schrieb am 30.10.02 02:22:01:
> 
> I've given this some though. What you're trying to say, basically, is
> the sf bugtracker isn't suitable because you need at least a DSDT/dmesg
> with the bug report and preferably access to ask further questions, so
> unless someone has that implimented in a bug-track system (with hosting
> to match) it's a nightmarish task.  

sourceforges bug tracker allows to attach files to a report.  The submitter
is know with it's email address.

    yours
    Joerg



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: making progress with ACPI was: ACPI small patch up date

[Valette Eric]

joerg.beyer-htSm2yLGOjU@public.gmane.org wrote:
> Huw Hawkins <hrhawk-JGs/UdohzUI@public.gmane.org> schrieb am 30.10.02 02:22:01:
> 
>>I've given this some though. What you're trying to say, basically, is
>>the sf bugtracker isn't suitable because you need at least a DSDT/dmesg
>>with the bug report and preferably access to ask further questions, so
>>unless someone has that implimented in a bug-track system (with hosting
>>to match) it's a nightmarish task.  
> 
> 
> sourceforges bug tracker allows to attach files to a report.  The submitter
> is know with it's email address.
> 
>     yours
>     Joerg


look at bugzilla and how it is used for the development of mozilla...

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: valette-GANU6spQydw@public.gmane.org








-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Re: making progress with ACPI was: ACPI small patch up date

[Grover, Andrew]

> From: Valette Eric [mailto:eric.valette-GANU6spQydw@public.gmane.org] 
> I complained about that in the list in the past and got an 
> answer saying 
> politely to shut up, to *not* use sourceforge tool, and post 
> problem to 
> the mailling list. Fortunately dominik spend some time 
> helping me until 
> it worked.
> 
> I also complained about acpi patches beeing done for 2.4 pre releases 
> and not applying cleanly on 2.4.X official kernels.

If we have a prayer of ever getting into official 2.4, we need to track the
pre kernels. People in the past have done backports to the non-pre kernels,
but that really depends on what other people are willing to do.

> > I strongly believe that the ACPI project would make much 
> more progress
> > if Andy and Robert put a little effort into tracking bugs and making
> > releases.
> 
> I do agree. The more people do not want other to look/critic 
> their code, 
> the more they pretend what they do is a kind of black art, and do not 
> document it or make design document :-) Fixing bug is 
> annoying, making a 
> new release and advising to report a problem on it is so more fun.

We can fix bugs, the problem is *diagnosing* the issue. There's only so much
diagnosis that can be done without the hardware. If you say "line 444 of
ec.c is acquiring a semaphore at interrupt level" that's probably enough. If
you post a patch, we'll apply it. If you just say "my system hangs" then
it's a lot harder. Sometimes the dmesg or DSDT are enough that other people
can suss out what might be the problem -- sometimes not.

Part of this whole open source "gift" economy is that it's polite to not
turn one's nose up a gift. Even if it wasn't all that you wanted. And
especially if you haven't reciprocated.

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: making progress with ACPI was: ACPI small patch up date

[J]

On Wed, 30 Oct 2002 07:50, Grover, Andrew wrote:
> > and not applying cleanly on 2.4.X official kernels.
>
> If we have a prayer of ever getting into official 2.4, we need to track the
> pre kernels. People in the past have done backports to the non-pre kernels,
> but that really depends on what other people are willing to do.

At present I will only use what's in 2.4. What I do for my machines doesn't 
matter a whole lot, but when I maintain machines for others I _much_ prefer 
to use standard source code supplied by my vendor inless there's a good 
reason for something else.

Best too, I think, if I use the platforms I support for others.

> > > I strongly believe that the ACPI project would make much
> >
> > more progress
> >
> > > if Andy and Robert put a little effort into tracking bugs and making
> > > releases.
> >
> > I do agree. The more people do not want other to look/critic
> > their code,
> > the more they pretend what they do is a kind of black art, and do not
> > document it or make design document :-) Fixing bug is
> > annoying, making a
> > new release and advising to report a problem on it is so more fun.
>
> We can fix bugs, the problem is *diagnosing* the issue. There's only so
> much diagnosis that can be done without the hardware. If you say "line 444
> of ec.c is acquiring a semaphore at interrupt level" that's probably
> enough. If you post a patch, we'll apply it. If you just say "my system
> hangs" then it's a lot harder. Sometimes the dmesg or DSDT are enough that
> other people can suss out what might be the problem -- sometimes not.
>
>
> Part of this whole open source "gift" economy is that it's polite to not
> turn one's nose up a gift. Even if it wasn't all that you wanted. And
> especially if you haven't reciprocated.
>
>
> Regards -- Andy

This can be taken two ways.

It's becoming apparent to me this project is in need of some management. I 
think Jan was hinting he might provide some management, maybe only in the 
short term, but who knows? He has some problems he wants fixed, and if he 
finds it enjoyable being part of the team he'll probably stick around. Why 
turn up your nose at the gift?

If you don't like the sourceforge bug tracking system, then how about 
Bugzilla? As a user I don't like it a lot, but it does handle some sizable 
projects so it can't be all bad. Probably someone here could host it.

Even a weblog (or spreadsheet for that matter!) would serve to keep bugs 
visible until they're resolved. I have the impression from what others have 
said that losing track of them is a problem.







-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

RE: Re: making progress with ACPI was: ACPI small patch up date

[Huw Hawkins]

> We can fix bugs, the problem is *diagnosing* the issue. There's only so much
> diagnosis that can be done without the hardware. If you say "line 444 of
> ec.c is acquiring a semaphore at interrupt level" that's probably enough. If
> you post a patch, we'll apply it. If you just say "my system hangs" then
> it's a lot harder. Sometimes the dmesg or DSDT are enough that other people
> can suss out what might be the problem -- sometimes not.

I've given this some though. What you're trying to say, basically, is
the sf bugtracker isn't suitable because you need at least a DSDT/dmesg
with the bug report and preferably access to ask further questions, so
unless someone has that implimented in a bug-track system (with hosting
to match) it's a nightmarish task.  

> Part of this whole open source "gift" economy is that it's polite to not
> turn one's nose up a gift. Even if it wasn't all that you wanted. And
> especially if you haven't reciprocated.

Owch. Personally I've tried to submit what
patches/bugreports/information I could. Usually, I'm not sure if its
helpful, whether its important or got missed in the rush. To me
ACPI-development is a "black-box" system. You post something to the list
and either get a flaming, a pat on the head, a useful bit of help or
dead silence. Other projects have roadmaps, FAQ's, etc to at least give
people the option to inform themselves as to whats a priority, why
bugtracking is a mailling list or what's currently being neglected. A
few lines of html might save constant "are you insane, it'd be easier
if.." and "why isn't...." threads when you've thought it through and
have good reasons others might not immediately otherwise see.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: making progress with ACPI was: ACPI small patch up date

[Andrew Kohlsmith]

> patches/bugreports/information I could. Usually, I'm not sure if its
> helpful, whether its important or got missed in the rush. To me
> ACPI-development is a "black-box" system. You post something to the list
> and either get a flaming, a pat on the head, a useful bit of help or
> dead silence. Other projects have roadmaps, FAQ's, etc to at least give
> people the option to inform themselves as to whats a priority, why
> bugtracking is a mailling list or what's currently being neglected. A
> few lines of html might save constant "are you insane, it'd be easier
> if.." and "why isn't...." threads when you've thought it through and
> have good reasons others might not immediately otherwise see.

*clap*clap*clap*clap*clap*

I appreciate all the hard work that the ACPI developers are putting into the 
project, but without the damned web site even hinting that anything is going 
on / broken links / etc., it is very much a black-box operation.

I've been able to help out on the KDE project because I can hit IRC and 
chat/get flamed/etc.  I can help out with the Jabber IM I prefer (Psi) 
because when I ask a question about the internals, I get some semblance of an 
answer that doesn't raise more questions than it clears.  The ACPI project is 
*very* important to me but I can't help because there is nothing to allow me 
to take the two steps I need to get up to a level where I can ask intelligent 
questions about the workings.

I'm not trying to flame the developers here, and lord knows you're working 
your asses off, but there are people who want to help but can't get the 
initial documentation they need to make a decent effort.

Regards,
Andrew


-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en

Re: Re: making progress with ACPI was: ACPI small patch up date

[Ernst Herzberg]

On Mittwoch, 30. Oktober 2002 00:50, Grover, Andrew wrote:

>
> We can fix bugs, the problem is *diagnosing* the issue. There's only so
> much diagnosis that can be done without the hardware. If you say "line 444
> of ec.c is acquiring a semaphore at interrupt level" that's probably
> enough. If you post a patch, we'll apply it. If you just say "my system
> hangs" then it's a lot harder. Sometimes the dmesg or DSDT are enough that
> other people can suss out what might be the problem -- sometimes not.
>

Hm. Give me some debugging hints. I'm not a kernel hacker, and i see the need 
for ACPI, but this stuff is complex. I have not the time and i am not willing 
to understand every line in the code. But i'm willing to help you to help you 
to fix problems in the code. 

ACPI_FUNCTION_TRACE looks for me like a function that can help.  Should it 
work if i change acpi_set_debug(..) to ACPI_DEBUG_HIGH in acpi_init(void)?  
Last try i get a kernel that don't start or was not able to send any 
printk-message.
(clean 2.4.20-pre11, newest patched ACPI patch, compiled into, not modules, 
gcc3.2)

Problem is, that thermal and processor doesn't work anymore, no error message, 
no warning... no hint ;-)

<Earny>


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: making progress with ACPI was: ACPI small patch up date

[Randy.Dunlap]

On Wed, 30 Oct 2002, Ernst Herzberg wrote:

| On Mittwoch, 30. Oktober 2002 00:50, Grover, Andrew wrote:
|
| > We can fix bugs, the problem is *diagnosing* the issue. There's only so
| > much diagnosis that can be done without the hardware. If you say "line 444
| > of ec.c is acquiring a semaphore at interrupt level" that's probably
| > enough. If you post a patch, we'll apply it. If you just say "my system
| > hangs" then it's a lot harder. Sometimes the dmesg or DSDT are enough that
| > other people can suss out what might be the problem -- sometimes not.
| >
|
| Hm. Give me some debugging hints. I'm not a kernel hacker, and i see the need
| for ACPI, but this stuff is complex. I have not the time and i am not willing
| to understand every line in the code. But i'm willing to help you to help you
| to fix problems in the code.

That (debug hints) is one of the things that should be on an updated
ACPI web page IMO, along with DSDT issues, patches, etc.

-- 
~Randy
  "Do you need telco grade soundblaster 16 ?" -- Alan Cox



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: making progress with ACPI was: ACPI small patch up date

[Valette Eric]

Grover, Andrew wrote:

>>I also complained about acpi patches beeing done for 2.4 pre releases 
>>and not applying cleanly on 2.4.X official kernels.
> 
> 
> If we have a prayer of ever getting into official 2.4, we need to track the
> pre kernels. People in the past have done backports to the non-pre kernels,
> but that really depends on what other people are willing to do.

But, if you complicate the task of applying acpi patches, on the other 
hand you get less tester. I already expressed that I apply other patches 
to the kernel I run and I do not have the patches for pre releases.

When I'm home like now, with an old 56K modem, I do not download a pre 
version for fun especially because, I have to apply the other patches I 
need to get my computer working as I want.

> We can fix bugs, the problem is *diagnosing* the issue. There's only so much
> diagnosis that can be done without the hardware. If you say "line 444 of
> ec.c is acquiring a semaphore at interrupt level" that's probably enough. If
> you post a patch, we'll apply it. If you just say "my system hangs" then
> it's a lot harder. Sometimes the dmesg or DSDT are enough that other people
> can suss out what might be the problem -- sometimes not.

Look, I posted on the mailling list the exact line of a problem leading 
to a system freeze (by the way it was deferrencing a null pointer) long 
time agao. Proposed a trivial fix that was working but
	1) you said it was a symptom not the problem. You were probably right 
but another version of acpi code was released without having the patch. 
As a result, ACPI lead to boot hang on any recent ASUS board.
	2) in order to diagnose something, yopu need to have a kernel to test

When I was working at Canon, downloading megabytes and testing was not a 
problem. I had a fast ethernet connection and plenty of PC. Now that is 
not anymore possible. Think about the guys who need ACPI but do not have:
	1) A fast internet connection,
	2) The knowledge to look at the rejected patch and apply the missing 
lines by hand,
	3) A system that does not work from scratch

Those guy will probably never test or will test once and if it fails, as 
they do not know if the bug is known and a fix exist, they will stop 
trying ACPI. This will obviously lead to testing far less system.

If you want to have ACPI in stable kernel before 2.6 :-), you need more 
tester, and a serious development policy. To me the project is in need 
of some kind of management.

> Part of this whole open source "gift" economy is that it's polite to not
> turn one's nose up a gift. Even if it wasn't all that you wanted. And
> especially if you haven't reciprocated.

Sorry but indeed I tried and reported several bug on DELL C600 and ASUS 
board. Look at the history. Now, because the development model makes it 
hard for me to:
	1) Follow the development,
	2) Know existing problem and possible solutions,
	3) Download patches that applying cleanly to my kernel,
	4) Post bug report that are effectively handled,

I do not invest too much time helping you despite I'm quite used to work 
with OSS, and have contributed to many OSS project including rtems 
<www.oarcorp.com>, goahed web server, debian linux distrib, ...

-- eric



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf