From mint-bounce@lists.fishpool.fi Tue Jul 20 02:41:26 2010 Message-ID: From: "Jo Even Skarstein" To: "mint" References: In-Reply-To: Subject: Re: [MiNT] Bit-Depth and Graphics stuff.... Date: Tue, 20 Jul 2010 08:39:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: joska@online.no Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: -------------------------------------------------- From: "Paul Wratt" Sent: Tuesday, July 20, 2010 3:07 AM To: "mint" Subject: Re: [MiNT] Bit-Depth and Graphics stuff.... >> 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. >> > why isnt this working? > http://wiki.sparemint.org/index.php/Special:RecentChanges It works perfectly fine. >> 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 ;-) >> > thast the problem, it is left to one person to provide finalized > documentation. No, it isn't. The finalized documentation is in the CVS. > Which is not an issue if people have enough time to document things, This is not a problem if the API docs is in the code itself. No self-respecting coder will leave incorrect docs/comments inline. > Its not about NOT using the list for discussion, its about > facilitating/fast-tracking the process at which discissions are made, A wiki just doesn't work. Believe me. This is *not* what a wiki is intended for. > in such a way as to alleviate the problem with time related issues, > which in part is related to "history of the current position", which > "could" (not will) be solved (in part?) by easily referencing "the > current outline" online I'm afraid I don't understand what you're saying here. > Bugtraker is fine, but fVDI is a good example of that not being > possible, because its not related to code or projects held on this > system (AtariForge/SpareMiNT) and yet it is essential to the core of > TOS/GEM development Why do you want to document wishes/changes/ideas for fVDI on the FreeMiNT/SpareMiNT wiki if fVDI doesn't belong here? > Essentially I am saying, one should be able to code modern projects > and contribute, without having to spend hours wasted where a suitable > solution would speed up the process of finding the starting point, > weather that is finalized, or still in discussion, it would be > documented in one place, along with other things that are > inter-related. Bugtracker!! Using a bugtracker to manage bugs and features is a pretty well accepted way of working ;-) We just need to start using it. > That would cover most people (differing) ways of using, contributing, > use off the shelf apps, or a custom app (I have the time & skill for > this). Something that could import user/pass from current lists (HW, Rather than spending time on this, why not spend time on MiNT/XaAES itself? Or a GEM application? > OK, whatever the solution, one point is obvious, this list gets used > for discussions for which the project/code are not soley maintained by > its associated servers, and that needs to be taken into account I'm pretty sure that these projects have their own mailing lists and/or ways of working, which should be respected. Jo Even