Hi,
This mail explains my position on the recent 1.0 list issue. If the FreeDOS version 1.0 concerns you, please read this.
When I declared my intention to create the TODO list, I explained my two major concerns about it. First of all is that I wanted it as a checklist, and second, that I just wanted consensus or at least majority in order to perform changes on it.
The rules for applying the changes have always been, and are,
(1) Majority wins against minority
(2) If tie, then things remain as they are, and the reason to do so is that when I announced my intention to create the list and its features, few people replied. It's far easier to wait till the work is done and then complain when you don't like such or such thing.
In particular, there several things that Eric likes (one vote for), and that I don't (one vote against), so applying rule (2), this means they remain as they are, unless majority speaks in favour of them, of course (they are roughly speaking verbosity, that is, I want "A, B, C,..." and not "A, this uses interrupt XXX, please see here, and comment there; B: ...", including the POST items mentioned in the todo items, IMHO they are just noise, that don't let you see clearly what is to be done yet).
Now if you dislike something on the list, there are two ways:
- Comment in the mailing list, and see what majority thinks. Everytime majority has decided to change something, even if I voted against (e.g. the parameters of EMM386/HIMEM, although I must admit that Michael Devore convinced me in his latest messages, please read them), I have committed the changes
- Fork the list, make the changes you like (regardless if you weren't in majority) and post it somewhere (that is, Eric's way)
Needless to say, I don't think this helps the FreeDOS project. Branching is ok whenever a person wants to take sources for a particular purpose. Generally speaking, I don't think that branching between two freeDOS developers is good, and I say this knowing that
- you are FREE to do it
- there are dramatically opposite positions against this or that everytime a branch happened (e.g. MEM, Kernel)
So I just have to live with that, and thank Bernd and Jeremy, that have been acting as mediators many times very well. But I think it can be specially harmful that, being a single project, there is something like two sets of goals for FreeDOS 1.0, almost as critical as if there was a branch on the spec or manifesto.
Eric, you say your list is not to replace the official, then why you do it? why, being over 70 bugs, do you waste your time (and mine) in creating such a list?
Respect to the list consulting and posting: the list is updated weekly (what a remedy! read below) in my hard drive, and latest edit is always available via mail.
Modifications, typos, etc (some come from Eric) are always welcome, but specially welcome when ALL of them (say 20) are listed AFTER one official release, and not when they come by twos every week: this forces me to be updating the files and going over them once and once again. The normal behaviour has been: I upgrade the files, send them to Eric and Bernd, Eric reports 2 typos and 1 feature (for which there's no majority, so I explain for the n-th time and ignore), I change the list, I send it again to Eric and Bernd, etc etc).
In a past time, Jim was with myself concerned with the TODO list, and he understandably gave up. Now it is Bernd who very kindly uploads the list to a web server from where it can be checked online. But I ensured that the list will NO LONGER be sent to be uploaded every time Eric has a change, that is, every... four days?, and I claimed that updates would come at a reasonable rate, say once each two month (or at most month), or every time big changes occur, in order not to be bugging Bernd everytime.
<rantmode>
Thus, in the message from Eric (that I haven't read yet) he seems to mention other reasons why changes are not reflected in the webserver. Eric there are no conspiracies or similar. You know very well that I have been very clear with you in what concerns the todo list. It's simply that, despite I, stupid of me, allow you to be bugging me every week with a slight change (and not, say, every two weeks with SEVERAL changes, and with changes that have been discussed and agreed in the mailing lists), and do the appropriate modifications to the files in my hard drive, I don't bug Bernd in turn to upload the file till he things it's ok to do it.
So I hope it is now clear forever why changes are not reflected in the list fast. Bernd, you do NEVER have to justify yourself why you couldn't have uploaded the files (you didn't have to) because you had other personal non-FreeDOS stuff in your real life to do it.
Likewise, I don't have to justify that I was on a trip, thus I couldn't just reply to Eric's messages in the space of four hours.
So Eric, if you get bored, I think you help much more the FreeDOS project if you just pick the bugs at bugzilla and start patching, or if you take the TODO list, but not to directly modify it, but to convert the missing features into "ready". I don't know if it's just me, but it seems to me that there has been much chatting and less coding in the list lately (?), or am I getting old?.
If noone complained when I announced my intention to simply put in a webpage the items that seemed to be missing for a hypotheticall FreeDOS 1.0 version, then I also hoped that I would be given the necessary trust. If someone else disagrees with the policy followed for the list (explained above), then it is the moment to complain. Otherwise please acept what has been done, and be constructive for the FreeDOS project.
So Jim, I share your irritation about this issue, and hope to be able to read the messages you mention (that I couldn't read) and give appropriate response.
</rantmode>
So that was it. Now let's see if I can finish touching the list once again, and if I can go back and resume the coding for DISPLAY.SYS that I was doing, and that I had to stop to write this long letter.
But first let's read private mail for the space of two days. Oh! four mails from Eric Auer.
Cheers. Aitor
Jim Hall escribió:
<rant>
Okay, I'm starting to get fed up with this kind of behavior. Eric sent an email to me & Aitor 07/19/2004 04:21 PM asking where he can upload some changes for the To-Do list, and asking about the changes he already submitted to the To-Do list, saying "... Or are there other reasons apart from "no time" why you avoid uploading the updates and send only ZIPs of the new versions?"
And 07/19/2004 04:21 PM Eric posts his new To-Do list.
So now we have two To-Do lists. Which should be linked from the FreeDOS.org site?
We've seen this kind of behavior before where a developer is not willing to wait for a patch to be incorporated by the maintainer of the package, and so decides to release a second version of that program. In essence, a fork. What we have here is a fork of the To-Do list.
Yes, that's perfectly allowable ... but very irritating. That we've seen this so many times before, and looks like it will continue far into the future, starts to suck the joy out of working on FreeDOS.
</rant>
-jh
Eric Auer wrote:
Hi, I am proud to have finished the first version of my inofficial FreeDOS 1.0 TODO list on:
http://www.coli.uni-sb.de/~eric/stuff/soft/specials/freedos-inofficial-1.0-todo-list.html
Features:
- post 1.0 items are included and marked in a separate color
(all link to http://www.freedos.org/news/version1/post/ where you
can usually find more information about that item)
- EXIT CODE LIST translated to English language as suggested on
http://www.freedos.org/news/version1/ (have done that a while ago
but nobody linked it from the FreeDOS site yet...)
- this list asks YOU, the READER, for feedback. Please send that feedback
directly to me, unless it is also relevant for the offical list (which is
maintained by Aitor as you know...)
- "list of hard to test bugs" (for which you need particular hardware
or software to test), "stolen" from Aitor's unpublished TODO list updates,
with an extra quick-jump form where you can enter a bug number to jump
directly into FreeDOS Bugzilla
- comments to explain things which are missing are updated
- comments for missing or postponed features now suggest alternative
solutions (using other open source or freeware tools) where possible:
Please let me know if you have extra suggestions.
Sometimes I have links to "post/" but no color coding for "postponed".
This is for cases where I think that the current solution will be good
enough even for post-1.0, although there do exist extra suggestions in
the post-1.0 list. You will notice that FASTOPEN is not even mentioned:
It might be that we eventually add speed optimizations (by remembering
recently used slots / doing look-ahead for following slots!) to the
kernel for FAT32 FAT chain surfing and anyFAT DIRECTORY surfing. For now,
you have to rely on using a disk cache only.
My list tries to mention all "base" packages from the LSM database on FreeDOS.org, let me know if I have forgotten some (language packs for KEYB and MODE/DISPLAY are intentionally left out, and VERIFY is actually a FreeCOM-internal command now. MKEYB is the unlucky (not mentioned) alternative to KEYB, although I actually like MKEYB better (smaller, only 1 file, supports the top 10 keyboard layouts).
Enjoy!
Eric.
PS: Comparing to MS/PC-DOS -> http://www-306.ibm.com/software/os/dos/psm952a.html
EDIT - use SETEDIT REXX - use BASH DYNALOAD - use DEVLOAD
but also:
CALCULATOR - please suggest one SCHEDULER - please suggest one PCMCIA - create something based on the code released by DeskWork
(with translations and comments by me, with help of DeskWork)
Memory usage is quite good already, only SHARE and DISPLAY are clearly
worse than their MS/IBM counterparts. And our Win3.x compatibility is limited.
(other deficiencies of FreeDOS vs. MS/PC-DOS are listed on my online list,
except for the missing QBASIC - BWBasic is no real replacement, but you can
download QBASIC from MS and use it on FreeDOS systems, and Basic is Basic ;-))
PPS: Our STACKS are not MS-DOS 3.x+ style, does that matter? The idea is to
have N chunks of M bytes each, and every IRQ can get one or more of them,
which seems to be elegant in some way!? And the DOS IRQ wrappers support chaining
and sharing of IRQs, because they have standardized patchable structure.
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Freedos-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-user
