Hi Eric, > On May 3, 2021, at 5:48 AM, Eric Auer <[email protected]> wrote: > > Good day Jerome, > >> As for RC4, it is coming very very soon. >> >> Excluding anything absolutely critical, > > Well, having four times slower install than > possible, when installing on real hardware, > does sound like something which *is* worth > fixing ASAP and in rc4, unless you plan to > release rc5 only a week later ;-)
RC4 is no slower than RC3 or RC2. > Several of my other suggestions are about > EASY to fix and old bugs in your config and > autoexec templates, which will help making > rc4 lower in bug count at low effort for you, > preventing future "I have tried the distro, > but it is full of problems" reviews. Given > that "RC" implies "better than beta" :-) Any changes at all, require additional testing. RC4 has an enormous amount of change. Both for the install media and behind the scenes. With the numerous package updates, directory restructuring, language updates, installer tweaks and much much more, RC4 is very different than RC3. In fact, probably far more changes going from RC4 to RC4 than there were going from 1.2-FINAL all the way to 1.3-RC3. In reality, it is almost as if we stopped the 1.3 line entirely and are doing 1.4-BETA. It was planned for 1.3-FINAL to follow RC4. But, depending on the amount of change we do. An RC5 is not out of the question. Possibly even only a few weeks after RC4. I’ve asked before for assistance on making the install boot config more universal. But, that was a long time ago. They sure can use improvements. But, they aren’t critical. The current ones have more or less been in place for YEARS. >> no changes will be made to RC4 at this point. > > Can you provide a sort of changelog to announce > which past changes rc4 already has compared to > rc3, as well as some prediction for rc5 timing? > > Luckily http://mercurycoding.com/downloads.html > has been as-is for three months, pre-packaged, > so UHDD, UDVD2, RDISK, XMGR etc. have been > fully available for the distro repositories, > also DEBUG, JWASM, HIMEMX and 64-bit HIMEMSX. I think all of those have been on the repo ( https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/index.html <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/index.html> ) for months as well. The RBE pulls the latest versions from the repo when creating release media. > I agree that using http://kernel.fdos.org/ to > first create a new package for a fresh kernel > would be TOO LATE now. That can wait for rc6, > while of course rc5 would be much nicer. Maybe > Jeremy can make a FreeDOS style package for you? I always appreciate being provided with ready-to-go packages for stuff. Some things are easy for me to whip up a package. Like NASM. It’s just a take the old package, update the LSM. Drop the new binaries in its “bin” dir and its sources in its “source” dir, zip it and upload it. While some others like FPC are a pain and take an hour or more. Installing them, wading through dirs and moving stuff around… Some are even worse. Stuff I don’t use with junk spread out through numerous directories. And others you can pretty much just forget about. Things only release in source with no pre-made binaries requiring specific compilers and libraries from all over the web without providing copies of them, mentioning them in the docs or even links on where to get them. So, yup ready-to-go packages are preferred. :-) On a side note… If I recall correctly, Jeremy lives in my “neck-of-the-woods.” I should meet-up with him sometime for lunch or something. > > Regards, Eric > > > > _______________________________________________ > Freedos-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
