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

[Jo Even Skarstein <joska@online.no>]

On 07/18/2010 08:47 AM, Paul Wratt wrote:

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

But a discussion is just that - a discussion. A wiki is not a forum.
There are no threads, no (practical) way of keeping track of who said
what. This is exactly what a mailing list does well. If you're having
problems following threads or finding old stuff you need a better MUA.

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

But who sets the "interim state"? The author of the latest posting? The
problem is not the tool, but that things are discussed without no-one
taking charge and finalize things. Like now ;-)

> 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

That's a drawback. Anyone can mangle the wiki article. Any discussions
will end in a edit war.

> 2) editing and clarification can be done even if one is not a list
> correspondent (most get the list, but only some post)

Where's the advantage of that? If you subscribe to the list, you can
post too.

> 3) wiki does allow for document composition, which is particulary
> useful in API extension development

This only makes sense when setting up the final proposal. But it's much
better to do it in the sources itself, where it's available for the
developer(s). It also makes the developer responsible for keeping the
api and it's doc in sync.

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

The bugtracker the right place for a wishlist.

> A specific example in relation to this list:
> who remembers the fVDI discussion from December 2009

My MUA does ;-)

> where is an outline of things agreed on at the time
> where does one start if implementations are to be added to sources

Add a feature request to the bugtracker with a link to the relevant
thread in the mailing list.

> 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

Doesn't your MUA have a search function?

Jo Even