Re: Administration Wishlist

Re: Administration Wishlist

[Huw Hawkins]

For what its worth I _AM_ opinionated, I am certainly not suggesting
overthrowing Andrew, just suggesting he might like to decree
documentation and bugtracking a priority sometime soon. With the 2.4.19
backport now done and talk of merging to the 2.4.20-pre3 tree, the time
may well be near....

I once offered to try to document some of the code, but since I like to
believe somebody has a grand plan for what should go where (that they
just haven't got around to writing down for the rest of us yet) and
since I'm not really as familiar with the code as I would need to be,
I'll leave that to the experts. (step up all ye experts!)

I'll try my hand at suggesting some updates to get the webpages a little
less "under development", as I recall there is already an attempt
underway to gather information on the /proc/acpi filesystem which I
might be able to contribute something to (if someone would be good
enough to remind me where it was).

Huw



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Administration Wishlist

[Dominik Brodowski]

On Thu, Aug 22, 2002 at 01:59:53PM +0200, Huw Hawkins wrote:
> I'll try my hand at suggesting some updates to get the webpages a little
> less "under development", as I recall there is already an attempt
> underway to gather information on the /proc/acpi filesystem which I
> might be able to contribute something to (if someone would be good
> enough to remind me where it was).
Information on the /proc/acpi/processor part can be found at
http://www.brodo.de/english/pub/acpi/proc/processor.html

Please note that I do not intend to add documentation for other parts of
/proc/acpi/.

Dominik


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

RE: Administration Wishlist

[Grover, Andrew]

> From: Huw Hawkins [mailto:hrhawk-JGs/UdohzUI@public.gmane.org] 

> For what its worth I _AM_ opinionated, I am certainly not suggesting
> overthrowing Andrew, just suggesting he might like to decree
> documentation and bugtracking a priority sometime soon. With 
> the 2.4.19
> backport now done and talk of merging to the 2.4.20-pre3 
> tree, the time
> may well be near....

It's not talk, I already submitted the patches to Marcelo and Alan. It's
just a matter of getting accepted now. :)

> I once offered to try to document some of the code, but since 
> I like to
> believe somebody has a grand plan for what should go where (that they
> just haven't got around to writing down for the rest of us yet) and
> since I'm not really as familiar with the code as I would need to be,
> I'll leave that to the experts. (step up all ye experts!)

I am willing to give almost anyone who is willing to improve things access
to update acpi.sourceforge.net. Send me your sf.net username and I will fix
the permissions and let you do your thing.

I am all for delegating almost all of the admin work to other people. I
think I would have written a lot more code if I hadn't been maintainer, but
someone's gotta do it. If someone else is interested, *start grabbing
responsibility*, and if you do a good job, I can give you more. :)

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Administration Wishlist

[Huw Hawkins]

Hi guys,
    watching the nice little flamewar progressing over who, when and
whynot the latest acpi patches aren't backported for the latest stable
kernel release I thought it might be a good time to post my thoughts on
what is going right and wrong for ACPI development in my own personal
wishlist.


Problem: The current 2.4.19 backport issue

  This is what Linus was warning against a month or so back when he had
his little grump about the rarity of acpi kernel merges. The fact is
ACPI in the kernel is so far behind, average users NEED to patch their
kernel to get APCI to work (especially with these newfangled "ACPI does
all" things). The thing about average users is most of them use a fairly
modern, stable, linux kernel (At the moment that is either 2.4.18 or
2.4.19) and they don't have the knowhow/patience or courage to fiddle
around if a patch doesn't work as expected. 

Solutions : 

(1) As promised, get ACPI in the kernel vaguely up to date by merging
regularly as promised.

(2) Release a 2.4.19 backport of a (or the most) recent acpi-patch. Put
it on the sourceforge page, and recrute yourself a couple of extra
testers (and get the people who just want ACPI in their stable kernel
off your back).

Problem : Documentation is very sparse in most areas.

(1) There is little or no documentation in a lot of the code (remember
me grumbling about osl.c? Hacks to replace the DSDT were in completely
the wrong place because the description of what the function in osl.c
did was hidden in a file in the tables subdirectory).

(2) There is no description of how the spec. is being implimented.
(acpi_os_table_override seems half implemented. It is hardwired to
return AE_OK, what meaningful codes could otherwise be returned is
beyond my understanding of the code, why divert the newtable pointer to
NULL if the override was rejected makes less sense, why there's no
function definition to explain these things is beyond me)
 
(3) There's no desctiption of how other programs can access the
interface. the /proc/acpi tree is somewhat of an enigma to most people.
Most code at the moment merely hardcodes whatever the contents of the
authors own /proc/acpi happenned to be (since there's no obvious
descriptions of what is/will be implimented here). The last time I
looked at acpid, I had no idea what to put in the config file, since I
couldn't find a description of what event codes to expect.

Solutions:

(1) Get documentation into the code so that there is at least the
opportunity for people to write globally useful patches, rather than
just hacks for individual platforms. If something is semi-implimented,
explain what it is intended to do and what it's currently hardwired to
do. (Take a look at the way functions in tbget.c are documented, that's
the sort of code that bugs disappear from).

(2) Cobble together a description of what will be implimented in each
module, why, and how the various functions are implemented and should be
expected to interact. This could either be in the the source code, in a
"how things should interact spec" or as part of an overall
implementation spec. included in a HOWTO for interfacing with the ACPI
subsystem.

(3) Put together a "Interfacing with the ACPI subsystem HOWTO", take it
from the ACPI spec, the code documentation and/or the description of how
functions should be implemented. 


Problem : Everyone wants to do cutting edge development.

     The current activity on the mailing list suggests there are a few
dedicated individuals hacking new code, one or two cleaning up existing
code, about a dozen building hacks to get various bits and pieces
working for their platform and lots of people trying to get their PC to
work as advertised. What is lacking is someone to orchestrate the whole
shebang. 

Solution : Someone needs to step up and volunteer to give up most of
their current hacking to instead focus on delegating tasks, releasing
patches, assigning bugs and generally keeping everything running
smoothly. 
  I've seen numerous posts from people with patches trying to get
feedback on their work, get someone to accept it and threatening to
submit it to Linus directly for acceptance into the kernel tree. Give
the almighty administrative overlord the power to accept/reject patches,
everyone will know who to send patches to, hopefully get some feedback
on what they're doing and maybe getting the code documentation up to
scratch can be pushed at the same time...
  NOTE: At the moment the de-facto person in this position seems to be
Andrew Grover, I'm not sure if he wants to take over maintaining
everything, or get back to hacking code full time. As the userbase grows
I'd suggest whoever is maintaining things will get less and less time to
hack code, or ready themselves for more and more emails flaming them for
neglecting the administrative side of things. (take a look at
http://people.debian.org/~branden/ if you dont believe me that taking
responsiblity for widely used code is going to be stressful).


Problem : There is no bugtracking system.

The ACPI-devel mailing list is an all in one, developers conference,
users help forum, bug reporting system, general chat forum and dating
service. If I have a bug, I have to read the archives for half an hour
to find out if anybody knows about it, if anyone solved it, if anyone's
working on it, who that person might be and if anybody else experienced
the same problem. 

Solution : Sourceforge has a bugtracking system, why not use it. There
are also other alternative bugtracking applications. A bugtracking
system and someone doing a little bit of occasional administration could
organise and keep track of who has bugs, who's working on them and which
bugs can be bundled together. 


Problem : The ACPI code is getting useful, useable and widely used.

If you buy a new laptop, search the internet for how to set up linux,
the odds are the page you find will say "patch the kernel with the
latest ACPI patch". A lot of people use the acpi code, a lot more want
to use the acpi code but are waiting for stable releases, a lot more
people in the future are going to want to use acpi related code. They
will find bugs, they will find features you didn't intend, they will
want to thank someone for making it finally work.

Solution : Keep working hard, get support and administration
orchestrated properly and maybe set a sticky "ACPI is fantastic"
bugthread in the bugtracking subsystem. Users find the bugs, users help
isolate the bugs, developers get to take the credit for the great code
and users have somewhere to put all their thankyou messages.




>From my point of view, the ACPI code userbase has jumped significantly
over the last few months and the current administrative system isn't
coping. The point of this wishlist is to get people thinking and
hopefully volunteering towards overcoming the shortcomings in these
areas of administration. To this end, questions, comments and feedback
would probably be a good idea. 

Huw.



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Administration Wishlist

[Matthew Wilcox]

fwiw, i think you're full of opinions.  but your opinions are worthless
unless you're volunteering to do something.  i have no problems with
how andy is choosing to run this project.  you're far too ready to jump
to grandiose conclusions based on scraps of evidence.

-- 
Revolutions do not require corporate support.


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390

Re: Administration Wishlist

[Arndt Schoenewald]

Hi everybody!

On Thu, Aug 22, 2002 at 02:01:39AM +0100, Matthew Wilcox wrote:
> 
> fwiw, i think you're full of opinions.  but your opinions are worthless
> unless you're volunteering to do something.

Please don't be so fast and negative. His opinions are not worthless
just because he is not volunteering. The volunteer could be someone
else who reads them, gets inspired, and steps in.

I don't have a reason to complain about Andy either, but Huw does
raise some relevant issues. For example, after being on this list for
five months and watching the state of affairs, I second his proposal
that we would benefit from using a bug tracking system.

Best regards,
Arndt

-- 
 /////    Quelltext AG -- Professionelle Software-Dienstleistungen
//   //   Arndt Schönewald <arndt.schoenewald-DlrTi3oYuhxFZBE5LHGN+g@public.gmane.org>, Vorstand
//   //   Ostenhellweg 31, 44135 Dortmund, Deutschland
//  \\/   Telefon (0231) 9503750, Fax (0231) 9503751
 ////\\   Web http://www.quelltext-ag.de


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390