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

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

[Jens Haug]

> I have been working for famous companies and yes having a bug tracking 
> system was required and compled with the source management system. 

But this wasn't public, was it?

> If 
> your company is responsible, they want to have no bug in the system they 
> distribute.

No company distributes ACPI for linux.

> At a macroeconomic level, I bet if Intel sell more P4 for mobile devices 
> because linux runs on them, yes they want to have a good ACPI system and 
> a bug tracking system will help achieving this goal.

Or maybe people will read about all these bugs and think ACPI on
Intel was a mess - although these bugs are perfectly normal in this
stage of development.
I dunno.
Maybe I'm all wrong here. I hope I am.


Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@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 update

[Valette Eric]

Jens Haug wrote:
>>I have been working for famous companies and yes having a bug tracking 
>>system was required and compled with the source management system. 
> 
> 
> But this wasn't public, was it?

Yes it was unless submitter requested explicitely the contrary.

> No company distributes ACPI for linux.

No but companies are seeling ACPI compatible processors...


-- eric



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

[Markus Gaugusch]

On Oct 30, Jens Haug <haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org> wrote:
> Or maybe people will read about all these bugs and think ACPI on
> Intel was a mess - although these bugs are perfectly normal in this
> stage of development.
How much do you give on meanings that are obviously wrong?

I think a bugtracking system would be a good help.

Talking about bug reporting: Sometimes it's not easy to track a bug down,
because you don't know how to turn debugging on, etc. Some docs would be
great here (probably they even exist, but nobody can find them).

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \



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

[John Summerfield]

Rats. Did it again.

On Wed, 30 Oct 2002 17:25, Jens Haug wrote:
> Or maybe people will read about all these bugs and think ACPI on
> Intel was a mess - although these bugs are perfectly normal in this
> stage of development.
> I dunno.
> Maybe I'm all wrong here. I hope I am.

Does the lk team hide its bugs?

To my mind the best-supported software I use is fetchmail, and the standard 
way there of reporting bugs is to the list. It's very public.

Red Hat's buglist is open to all, for all the software it packages. I expect 
ACPI falls between the two in the number of bugs it has.


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

[Jens Haug]

> > I don't think this is about fun. There are people getting paid by
> > Intel for this, aren't they? Would you like it if your boss could
> > have a look at a list of mistakes you made in your job? Man, I sure
> > am glad there's no list with *my* mistakes! Yes, I know that bugs
> > are perfectly normal in such projects, no need to be ashamed. But
> > maybe their boss doesn't know that?
> > Just speculating here...
> 
> Unless my memory fails me, the name Andy Grover's been associated with Intel 
> for quite a while.
> 
> Frankly, I reckon any boss fit to manage an IT project has BTDT and will 
> understand that bugs arise.

Maybe I just read too many Dilbert comic strips.


Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org



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

[Jens Haug]

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

I don't think this is about fun. There are people getting paid by
Intel for this, aren't they? Would you like it if your boss could 
have a look at a list of mistakes you made in your job? Man, I sure 
am glad there's no list with *my* mistakes! Yes, I know that bugs 
are perfectly normal in such projects, no need to be ashamed. But 
maybe their boss doesn't know that?
Just speculating here...


Jens

-- 
Jens Haug
IKFF Universität Stuttgart              Tel. 0711/685-6422
Pfaffenwaldring 9                       Fax  0711/685-6356
70550 Stuttgart	                haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@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 update

[Valette Eric]

Jens Haug wrote:
>>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.
> 
> 
> I don't think this is about fun. There are people getting paid by
> Intel for this, aren't they? Would you like it if your boss could 
> have a look at a list of mistakes you made in your job? Man, I sure 
> am glad there's no list with *my* mistakes! Yes, I know that bugs 
> are perfectly normal in such projects, no need to be ashamed. But 
> maybe their boss doesn't know that?
> Just speculating here...

I have been working for famous companies and yes having a bug tracking 
system was required and compled with the source management system. If 
your company is responsible, they want to have no bug in the system they 
distribute.

At a macroeconomic level, I bet if Intel sell more P4 for mobile devices 
because linux runs on them, yes they want to have a good ACPI system and 
a bug tracking system will help achieving this goal.


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

[Derek Broughton]

From: "Jens Haug" <haug-X6ztD3ggwzuBAmxm6OvjtTjhTm2NLCe8@public.gmane.org>

> > 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.
>
> I don't think this is about fun. There are people getting paid by
> Intel for this, aren't they? Would you like it if your boss could
> have a look at a list of mistakes you made in your job? Man, I sure

Actually yes.  When there's an official bug list, there's also an official list
of stomped bugs.  My current project has a list of 154 bugs, of which I've fixed
all but three and those are dependent on someone else.  Makes me look pretty
good :-)



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

[Randy.Dunlap]

On Wed, 30 Oct 2002, Jens Haug wrote:

| > 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.
|
| I don't think this is about fun. There are people getting paid by
| Intel for this, aren't they? Would you like it if your boss could
| have a look at a list of mistakes you made in your job? Man, I sure
| am glad there's no list with *my* mistakes! Yes, I know that bugs
| are perfectly normal in such projects, no need to be ashamed. But
| maybe their boss doesn't know that?
| Just speculating here...

Sure, they get paid for it.  And it's fun.  It's a great work
combination if you can get it.
And I don't expect the boss question to be an issue either.

When I was the linux-usb maintainer (and working at Intel),
my manager and I discussed Linux process issues, or I could
ask him for advice whenever I wanted to, but otherwise I had
almost complete autonomy over the Linux-USB project (unless
Linus objected :).
I don't know how Andy works, but I doubt that it's a traditional
Intel project.

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

[John Summerfield]

Sorry Jens

Will someone please fix this list?

On Wed, 30 Oct 2002 15:12, Jens Haug wrote:
> > 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.
>
> I don't think this is about fun. There are people getting paid by
> Intel for this, aren't they? Would you like it if your boss could
> have a look at a list of mistakes you made in your job? Man, I sure
> am glad there's no list with *my* mistakes! Yes, I know that bugs
> are perfectly normal in such projects, no need to be ashamed. But
> maybe their boss doesn't know that?
> Just speculating here...

Unless my memory fails me, the name Andy Grover's been associated with Intel 
for quite a while.

Frankly, I reckon any boss fit to manage an IT project has BTDT and will 
understand that bugs arise.


He would also understand that one of the best ways of locating them is peer 
code review, and a free peer code review is a gift not to be sneezed at.


Fun? I've been working with computers for over three decads because its fun.




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