> Still no reason to add experimental things to stable now :-)
> The solution is easy: Add it to the UNSTABLE fork
No. Because first, I don't develope DOS-C, and second, forking is bad and
makes merging changes back in harder. Since your opinion seems to be that
filesystem extensions can never be added to the "stable" or official
release, this is of course what you want to happen to them: Implement it
into "unstable" and it will never find it's way to "stable".
The problem here isn't just that you don't want to release new features in
official builds, it's that you support forking another single build
(which, by now, is already years behind in improvements of "stable" - see
below why) instead of adding the feature to (unofficial) builds directly
derived from the latest "stable".
Of course that's just my opinion and I'm not even a FreeDOS developer, so
feel free to ignore it.
>> At least I didn't yet see anything changed in
>> "stable" which was derived from "unstable"
>
> Actually not much apart from COUNTRY SYS support in unstable
> has very favorable "risk/complexity versus gain in features"
> ratio at the moment, unfortunately...
So why write a "risky" feature at first, if there's apparently no chance
it will be merged to "stable"? Additionally, this raises the problem that
people that want to write new features into "unstable" first will have to
cope with a kernel already full of other "unstable" features. So I won't
recommend re-using the outdated "unstable" anymore.
>> , and improvements of "stable" aren't added to "unstable" either.
>
> This is because more or less the only developers were Jeremy,
> Lucho and Arkady - the latter is kind of missing and Jeremy
> just returned a few weeks ago from being so busy with the real
> world real life that he simply had no time to continue working
> on the unstable branch. Lucho now has other big things as 4DOS.
I'm of course not blaming these people. However, as I mentioned
previously, if all developers of "stable" had merged their changes (as
applicable) to "unstable" as well, this would make life easier for people
that want to test new features for "stable" on "unstable". (And please
don't argue that the developers of "stable" would have to know "unstable"
then, too, because they of course should do if it's more than a fork.)
> If they were IFDEFed then you would have no chance understanding
> either ;-).
I doubt I would have a problem with it if the source was divided that way.
What do you mean by "either"?
> The stable / unstable diff is maybe 1000s of lines.
Could it be smaller if the changes in "stable" were added to "unstable"?
>> [...] because I
>> prefer to write such programs in Assembler. In a way, I want to "change
>> everything" compared to DOS-C ("The FreeDOS Kernel") which is written
>> in a
>> high-level language, and that's the reason I choose not to develop it.
>
> Tastes differ. One of the original goals with DOS-C was using more C :-)
I know. "and that's the reason I choose not to develop it." If you repeat
"answering" that DOS-C tries to use C as much as possible I can repeat to
write my answer again ;-)
> Still you are welcome to point out tech details of bugs if you find
> them, as we often have only vague "it somehow does not work" type
> bug reports and no time or hardware/software to reproduce/debug them.
Of course ;-)
Regards,
Christian
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Freedos-kernel mailing list
Freedos-kernel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
