Hi Jim, > I disagree with your "No, but you could say it is stable enough" > statement. The kernel needs to work reliably. Today, we have two > branches of the FreeDOS kernel: 2036 stable, and 2037 devel > (unstable). That shouldn’t be ok, yet somehow we’ve convinced > ourselves this is acceptable. Having two versions of the kernel, > where the most recent branch is effectively “broken”, is what’s > keeping us from moving forward.
> Is there a developer on the lists here who has an interest in kernel > programming? We need someone who is willing to dig into the code and > fix the kernel so we finally have a latest version that's more > "stable". Is it easier to start with 2036 and re-add the features from > 2037? Or is it better to fix the broken parts from 2037, to release a > (working) 2038 version? I lack the skill to do any kernel development, > so I never tried. I’m hoping someone with the necessary energy and > enthusiasm can work it out. The current numbering is that "stable plus patches" will be 2038 while unstable is 2037 (next unstable will be 2039)... Both branches are based on kernel 2035 and for a while they even both used 2035 as version number(s), unfortunately. While it does not have a SF file release yet, 2038 combines stable 2036 kernel with patches that fix bugs, increase the stability or add small, non-experimental features. It could be released at any time if necessary, but there are some doc updates and small patches what would suit it well :-). The 2037 unstable branch, on the other hand, contains a big number of sometimes complex or unstable patches... A partial list aimed at giving programmers an overview is in the wiki: http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch Any help with making this list more complete is welcome and would be useful both as starting point for people who want to make unstable more stable or add new experimental features in unstable as well as for people who want to backport some of the things from unstable into stable. I think that unstable is too different and too unstable to get a merge soon, but we can work on BOTH branches. For example we can port COUNTRY SYS support from unstable to stable, and the various bugfixes in stable since Jeremy vanished can be ported into the unstable branch while others can start reviewing and cleaning up code in unstable to get it back in view... On the other hand, it might also be an option to keep unstable only for reference and use it as a pool of potential patches which can be put into stable after careful review. As soon as that pool "got fished empty", unstable could be abandoned if there are no developers who can give unstable a real future by then. Eric ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign 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-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
