Re: making progress with ACPI was: ACPI small patch update

Re: making progress with ACPI was: ACPI small patch update

[Huw Hawkins]

Behold, Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> hath decreed:

> i find it fascinating that there are so many people on this list who
> want to see a bug tracking system, but don't feel able to keep a list
> of bugs themselves.  why is that?  expecting andy to set it up seems
> unreasonable.

I think the answer to this question is obvious. People who want a bug
tracking system are people who'd like to get involved with the project
either as a tester or more actively. They would assume there's no point
collecting bug reports the main developers never look at, probably don't
have the familiarity with the project to feel able to categorise bug
reports sanely and quite possibly have never set up or maintained a bug
tracking system. 

As far as I can see, there is already a perfectly functional bug
tracking system on sourceforge, which at worst and unmaintained will
keep a list of bugs in much the same way as this mailing list does. At
the moment there is a rather discrete note "Use the mailling list
instead" and its obviously not maintained in any shape or form. I'd
suggest changing that little label to "Make sure you include the kernel
version, acpi-patch version and hardware description in any bug reports"
and then at least the option is there for someone to step up to the task
of organising bug reports (which would be a lot more appealing than the
current "set up a bug-tracking system better than the sourceforge's and
maintain it").

This whole thread seems familiar... as I recall, the last time I brought
it up and the issue of some documentation I went away to try to write
some documentation for the /proc/acpi interface. As it turned out, I can
read what shows up in mine, I know what people on the mailling list have
said can be echoed to files to get things to happen, but since I have no
idea whether these are subject to change, which may change between
computers (eg. show whatever the manufacturer called something) it
seemed rather silly to contine, since such reverse engineering of the
interface could be done by anyone with equally qualitative results. I'd
hate to think everyone started submitting bug reports because Andrew's
latest code didn't behave like I said it would in my description of the
interface!

In my opinion, without up-to-date documentation (probably a spec as to
what happens in /proc/acpi) and a bug-tracking system, the acpi-project
demographic is going to stay pretty as "Andrew or one of the other 2-3
developers who contribute sizable slabs of code at a time", "niche
patches" (eg. what Ducrot Bruno has done with toshiba DSDTs),
"occasionally submits a patch which implimented something for them, but
couldn't be reused" or  "reads the list, occasionaly reports a problem".
What I think is needed, is for one of the "Andrew or one of the other
2-3 developers" to take a break for a day or two from coding to set
things up so the hurdle for getting involved isn't (or doesn't seem)
quite so high (hell, post a HOWTO-contribute-to-the-ACPI-project on the
project page listing what isn't being maintained would be a start).

Just my 2c, I'll go back to converting my friends over to GNU/linux 
again so no need to flame..

Huw



-------------------------------------------------------
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 update

[Valette Eric]

Jan Rychter wrote:

>  Huw> I think the answer to this question is obvious. People who want a
>  Huw> bug tracking system are people who'd like to get involved with the
>  Huw> project either as a tester or more actively. 

I disagree : I mostly use a bug tracking system when I encounter a bug 
to see if someone else got the same problem and if the fix is already 
availiable. Only there I start to try to debug something. I have run 
debian for than 5 years now, and their bug tracking system saved my ass 
several time... I just spend a few days really debugging things. I 
probably have spend already more time testing/debugging acpi and 
readding this mailling list...

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.


> 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.


> If Andy and Bob don't want to use a bug-tracking system, there is no 
> way to force it.

Just keep telling them to they should. That there is time for adding 
feature and time for fixing bugs and making software work. Now ACPI is 
one of the few area where windows XP performs far better than linux and 
it has not been yet accepted into 2.4.x due to lack of stability...




-- 
    __
   /  `                   	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