[asus-port] [RFC] Standard port status wiki page

[This message is cross-posted to number of lists, as it supposedly
relates to almost every kernel developer and user. I'm sorry for any
inconvenience this may cause. Please cc: only to kernel-discuss
mailing list when replying. Thanks.]

Greetings,

  By the end of the year, looking back, it's fair to say that kernel
porting efforts to different devices achieved good progress in this
year - well, just as in previous years too ;-).

  What becomes more and more evident however is that we don't have
good means to express and track status of individual ports. Even
kernel developers oftentimes cannot tell does some or another feature
work in another port, and what is its general state.

  This is major drawback in our process, as it makes active kernel
developers duplicate effort, doesn't foster inflow of new developers
and contributors, and makes developers and users two separate camps,
having low insight in each other's needs and work.

  Of course, we have wiki pages and they are updated with ports's
statuses, especially for ports in active development. What we lack is
consistent wiki pages conventions to represent such status, and
estimation procedure. Well, actually we have, and for more than year
now. http://handhelds.org/moin/moin.cgi/PortingProjectFrontpageTemplate
page have detailed RFC, authored by Andrew Vovk, available for more
than year now. And some ports, mostly newer, - Eten G500/M500/M600,
HTC Wizard, Siemens SX1 - already use it. Once I learned about that
template, I also gradually converted h4000 and h3900 (2.6) pages to
it.

  The PortingProjectFrontpageTemplate seems to very well thought out
proposal, will takes into account needs of different target audiences,
with emphasis on ease of access for users. Let me outline its crucial
points:

1. Port's main page starts with status table, which clearly and
unambiguously (works/doesn't work) outlines state of each of
handheld's feature. This main pages should contain only basic info in
addition to it, like credits, means to get further information.

2. All features are broken down in groups, with familiar status letter
assigned to each, from D (most basic support) to A (complete support),
with usual + and - modifiers. Once handheld has all feature working in a
group, it is considered to achieve corresponding status, assuming that
all previous groups are complete. Each status roughly corresponds to
usability level, like "just boots kernel", "well suitable for
development", "suitable for daily use with basic PDA functionality",
"supports more advanced usage (still as basic PDA)", "full support
for device-specific features".

3. There's consistent and not overloaded menubar structure.

  So, given that PortingProjectFrontpageTemplate exists for extended
time, I would like to propose all port maintainers to review it,
provide feedback for and suggestions for what features it may lack and
how to handle them, and strongly consider supporting and migrate port
wiki pages to the proposed structure. As Andrew currently works on
other projects, I would volunteer to process this feedback and work
towards elaborating the template, while ensuring consistency and
support for needs of different devices. I myself would like to update
hx4700 and h2200 ports, as most advanced ("complete") ports to the new
design, as with them being pronounced complete, their wikis suffer
from undermaintenance and in great need for an update to capture tehir
current state.

  Together with introduction of port status codes, I would like to
update http://handhelds.org/moin/moin.cgi/SupportedHandheldSummary to
record it instead of less-insightful "Linux boots column". (Actually,
I already started that for h3900 & h4000). At the same time, I would
like to remove "Boots with X bootloader" footnotes from it - this is
exactly the kind of information which is better be written on
individual ports pages, and only disperses attention on a general
status page.

  So, please share your feedback/concerns/ideas regarding this
proposal, and I hope it will get attention of both developers and
users.

Thanks (and Merry Christmas)!

-- 
 Paul                          mailto:pmiscml_at_gmail.com