Hi Christian,

>> 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 fork already exists so you do not add badness... Things for
stable should indeed be compatible, but if you need a playground
for incompatible FAT-more-than-32-plus, unstable is the place ;-)

> The problem here isn't just that you don't want to release new feature
> in official builds, it's that you support forking another single build

The aim is compatibility... Of course you are free to write a
network redirector which lets DOS access any modern filesystem
of your choice, but even then, please make it an existing one
and not an exotic invention of EDR DOS that does not even help
any existing app to do anything useful that FAT32 did not do.

> Of course that's just my opinion and I'm not even a FreeDOS
> developer, so feel free to ignore it.

Of course opinions of Tom and me about FAT32+ are also opinions.

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

Good point. Why indeed. But if the code is small and beautiful,
even useless features can make it ;-).

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

If you do not like kernels with odd features, do not suggest ;-)

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

Changes in stable are small and well-documented, so anybody with
interest in updating unstable could port them TO unstable much
quicker than the time it would take to port any feature back
FROM unstable...

>> The stable / unstable diff is maybe 1000s of lines.

> Could it be smaller if the changes in "stable" were added
> to "unstable"?

Only marginally. Do have a look at the diff between r1261
and r981 in the unstable branch (2035 versus now, as the
2035 kernel is the common ancestor) to check...

Changes from 2035 to 2036 typically are also in 2037, but
changes from 2036 to 2038 typically are not. However, the
latter (2036 to 2038) difference is relatively small anyway.

svn diff -r981:1261 \
https://freedos.svn.sourceforge.net/svnroot/freedos/kernel/branches/UNSTABLE

...at least 3800 old lines replaced by at least 8700 new lines.

Eric



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

Reply via email to