Re: [MiNT] Bit-Depth and Graphics stuff....

[Paul Wratt <paul.wratt@gmail.com>]

On Sat, Jul 17, 2010 at 6:45 PM, Jo Even Skarstein <joska@online.no> wrote:
> On 07/17/2010 04:47 AM, Paul Wratt wrote:
>
>> On API proposals, I hark back to the use of wiki in making them
>> available in a permanent form (as opposed to the list or a text file),
>
> A wiki is a poor tool for this. API docs (even for unimplemented stuff)
> belongs in the source of the AES itself (or perhaps in the bindings, but
> ideally the bindings should be automatically created from the source
> too), so it can easily be extracted during the build process. It's the
> only way to make sure that the docs are up to date. Keeping docs and
> sources separate means that the docs simply won't be updated - this is
> how programmers work ;-)
>
> Jo Even
>
OK, if you remember back to the original discussion in which wiki was
decided the best use for the "new sparemint/freemint" web site, it
came down to the ability for the site to be maintained

Dont get me wrong about the docs mentioned here, yes they should be in
the sources. But what I am saying is that any additions or changes
which are outlined or discussed here on the list can only be updated
in the docs when that discussion is finallized. This is the way things
are done here..

What I am saying is "give us a place we can view the API in its
interim state" while that discusson is going on.

There are at least 2 benifits from this (using a wiki)
1) anything need (which will be outlined in a post) can be added (by
the person posting) to a central point, one that may finalized &
unfinalized information
2) editing and clarification can be done even if one is not a list
correspondent (most get the list, but only some post)
3) wiki does allow for document composition, which is particulary
useful in API extension development

at the end of the day I am basically talking about the inability of
the list to be used as a documentation tool, and "where is this
documentation" while it has not been finalized

another way to look at it is like this:
I have a list of things I want or need
I understand is that some of those features may not even be finalized
for 2 or more years, let alone implimented.
without a place to see these additions in relation to what else is on
the cards, I will have to "reinvent my own wheel".

A specific example in relation to this list:
who remembers the fVDI discussion from December 2009
where is an outline of things agreed on at the time
where does one start if implementations are to be added to sources

Some of what has been discussed here in this thread was in that
December 2009 thread on fVDI.

I am constantly unable to find things that were posted just last week,
let alone 6 months ago, and I do have the tools that should give me an
instant result. But I do not have the time (or the patience) to
manually go through hundreds (or thousands) of posts in order to find
what I am looking for (note that some others so get results this way),
which at the end of the day is still not consolidated

At the end of the day I maintain my own example of what is being
discussed here. But it is mine, not ours, nobody knows where it is,
and (atm) it is not editable by others. And that is what needs to be
addressed.

The list will always be primary communication channel, but is there
any reason why it cant be supplimented with a system (in this example)
that maintains unfinalized documentation outlines/proposals, often
time are inter-related to other parts of (non-kernel & kernel) OS
development

Paul
PS I believe in an Open Source respect, this is what a body/group
secretary does or maintains <-- mint/freemint/sparemint does not have
this person