Re: [Freedos-devel] Thinking about FreeDOS test releases

[Wilhelm Spiegl]

Hi, I just wanted "to add my mustard" (=denglish, =german english) to make this FD update discussion a little
useful for end users (for improved files) by adding the "to-do-list" and "plans for the future" that I found at the
FD base section while working on help 1.1.0 (will surely not be published before update/upgrade/whatever 2023-12 version)
and some bug report links for checking.

I know that some of these commands are outdated, but my idea was to remember you what still

could / has to be done. You can find the whole text / documentation files at:

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/base/

at the related files. Please do not oversee position 18).

 

 

0001) fdisk: (actual: 1.3.4)

 

Future changes planned for Version 2.0.0:
-
TO-DO:  Complete addition of international language support.

Future changes planned for Version 1.8.0:
-
TO-DO:

Future changes planned for Version 1.6.0:
-
TO-DO:  Increased the extended partition buffer size by 1 to support
    24 extended partitions.

Future changes planned for Version 1.4.0:
-
TO-DO:  Investigate the possibility of resetting the boot sector
    bytes 510 and 511 to 0x00 instead of filling the boot
    boot sector(s) with 0xf6 when creating a partition.  This
    would make a file system easier to repair if a drive was
    accidentally fdisked.

TO-DO:  Fixed a bug that prevented option 5 from being displayed,
?   on the main menu, when more than one physical drive exists.

TO-DO:  Continued adding support for international languages.

TO-DO:  Check for fdisk functionality if the only hard disk is on
    the second IDE controller.

TO-DO   Fixed the ported BootEasy code.  

TO-DO:  Regression Testing
    1.  Maxtor 245MB hard disk (7245AT)
    2.  Fujitsu 20GB hard disk (MPF3204AT)
    3.  Western Digital 180GB hard disk (WD1800JB)

TO-DO:  Fix drive label modification issues.

TO-DO   Fix partition start and end corruption problems with
    some non-dos partition types.

 

 

0002) format (0.91w) - todo.txt:

 

TO-DO Add international language support (e.g. with KITTEN library).

TO-DO Debug FAT32 support. Debug all mirror / unformat data writes.
  FAT32 mirror data partially done in 0.91k - depends on your
  UNFORMAT whether more mirroring is required. To make things
  easier, 0.91l now contains a builtin UNFORMAT. Improved FAT32
  MIRROR and Win9x compatibility in 0.91p and 0.91q (again).

TO-DO Fix any other bugs (see bugs.txt).

TO-DO Clean up the source code, for example: Remove duplicate
  duplicate sanity checks. Maybe add checks for division by 0:
  0 sec/fat, 0 sec/clust, 0 sec/disk, too few sec/disk...


TO-DO (half)  Release filesystem locks (Win9x) when FORMAT has to give up
  before completing the format process. Otherwise, the system
  could be left in a "dangling" state, esp. for 0.91q / newer.
  (half-done: ctrl-c handler missing, otherwise done, 0.91r)

TO-DO (half)  Modify safe formatting such that it avoids overwriting data.
  (e.g. create a mirror.fil before deleting the file system...)
  (for now, 0.91r+: mirroring just fails if it would o/w data.)

TO-DO (maybe) Support sector sizes other than 512 bytes (64, 128, 256...).

TO-DO (maybe) SET 40:[9x] values to use all drives on all (even XT) BIOSes?
  Optimize non-standard floppy format settings? (...)

TO-DO (maybe) Use bigger and aligned buffers for harddisk surface scan.
  Is a WRITE ONLY scan enough (HARDDISK has to detect errors)?

TO-DO (maybe) When system files are written, the summary must subtract the
  amount of space they take up from the total disk space.
  (We just call the SYS tool to write the system files...)

format - bugs.txt:

Known bugs and problems (in 0.91k / known by Brian or Eric):
*** = bug which is definitely still an issue in 0.91t...
Please test and tell if the non-*** problems are REALLY fixed now!

 

*** There should be error handling that allows you to retry when format or
    disk read / write errors happen (beyond the default "try N times").
    Partially fixed in 0.91n by allowing noncritical disk I/O to fail.

*** Could use separate error messages for CD-ROM, remote, SUBST...

    Will, under some circumstances, fail to format due to dma overruns.
    Fixed in 0.91?

   

Re: [Freedos-devel] Thinking about FreeDOS test releases

[Jerome Shidel]

Hi, 

> On May 16, 2022, at 7:24 PM, Louis Santillan  wrote:
> 
> Any thoughts about the ability to build (more than kernel, FreeCOM, ISO) from 
> source?
> 

The release build process does not compile individual programs. It pulls 
pre-compiled versions staged in package format from the Official FreeDOS 
Archive on GitLab ( https://gitlab.com/FreeDOS  ). 
When the RBE (Release Build Environment) creates the release media, it checks 
each project for a branch specific to the OS build skew it is creating. If it 
exists, it will use that branch for the release. Otherwise, it will just use 
the default (usually “master") branch. 

Doing a full OS release using the pre-compiled packages is still a long process 
taking nearly an hour. When the RBE is set to Verbose, it displays only the 
main actions performed to generate the release. Even so, many megabytes of text 
is displayed. And that is only an overview of what is being done. There is a 
good deal of processing performed on packages and their metadata during a 
release build. Compiling those packages during a release build, would add many 
hours to the OS release build process.

But, it has long been problematic building many packages from source. So, it 
isn’t actually possible at present.

However, I’ve often thought it would be nice to sort-of standardize building 
packages from source. Possibly by including a “BUILD.BAT” or “BUILD.SH” for 
each project. Such a script could then verify that all tools and versions are 
present to build the package. Then, it could perform all the actions needed to 
compile and put it in package format. For some, that would be easy. For others, 
not so much. Many things rely on difficult to find libraries or specific 
versions. While others may need commercial compilers. 

For example, there have been numerous times I have spent hours working on 
getting an “updated” program that is available in source only to compile. And 
then, not always successfully because some critical piece of information on 
compiling it is missing. Nowadays, for the most part, if the developer cannot 
be bothered to provide a compiled version (at least for comparison), I won’t 
bother with trying to compile and update that program. 

:-)

Jerome




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Thinking about FreeDOS test releases

[Louis Santillan]

Any thoughts about the ability to build (more than kernel, FreeCOM, ISO)
from source?

On Mon, May 16, 2022 at 3:11 AM Jerome Shidel  wrote:

> Hi,
>
> Based on the discussion during the online get-together and the tool-chain
> and release processes used to maintain packages and deploy release media,
> this is what I’m thinking…
>
> The pipeline used to assemble all the different aspects into a release is
> very capable. It can handle multiple OS versions without issue. Including
> things like different names, package sets, specific skews of individual
> packages and much much more.
>
> So...
>
> An automated "Testing build" of the OS release media (possibly all
> versions or just maybe the LiveCD) on a regular schedule. Possible the 1st
> of every month. This version would be called something like “FreeDOS
> 2022-06.” It would contain new features and packages, updates and any other
> changes. This version could easily boot with a message indicating it is a
> Test Build.
>
> At some point, we could decide that there has been enough improvement to
> warrant a new OS release. When that occurs, we could branch the "Testing
> Build” into an “RC build”.  We would decide at that time if it would be a
> simple update (like FreeDOS 1.3U1-RC1) or major release (like FreeDOS 1.4,
> 2.0, etc.). Regardless of which type, the “RC build” would only get bug
> fixes from that point.
>
> During that time, the "Testing Build” could continue to receive general
> changes. However (excluding bug fixes), the Testing Build would most like
> sit idle during the testing of the RC Build.
>
> When we are satisfied that the RC Build is ready, we just push out the new
> OS version.
>
>  :-)
>
> Jerome
>
>
>
> ___
> Freedos-devel mailing list
> Freedos-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Thinking about FreeDOS test releases

[Jerome Shidel]

Hi,

Based on the discussion during the online get-together and the tool-chain and 
release processes used to maintain packages and deploy release media, this is 
what I’m thinking…

The pipeline used to assemble all the different aspects into a release is very 
capable. It can handle multiple OS versions without issue. Including things 
like different names, package sets, specific skews of individual packages and 
much much more. 

So...

An automated "Testing build" of the OS release media (possibly all versions or 
just maybe the LiveCD) on a regular schedule. Possible the 1st of every month. 
This version would be called something like “FreeDOS 2022-06.” It would contain 
new features and packages, updates and any other changes. This version could 
easily boot with a message indicating it is a Test Build.

At some point, we could decide that there has been enough improvement to 
warrant a new OS release. When that occurs, we could branch the "Testing Build” 
into an “RC build”.  We would decide at that time if it would be a simple 
update (like FreeDOS 1.3U1-RC1) or major release (like FreeDOS 1.4, 2.0, etc.). 
Regardless of which type, the “RC build” would only get bug fixes from that 
point. 

During that time, the "Testing Build” could continue to receive general 
changes. However (excluding bug fixes), the Testing Build would most like sit 
idle during the testing of the RC Build.

When we are satisfied that the RC Build is ready, we just push out the new OS 
version.

 :-)

Jerome



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Thinking about FreeDOS test releases

[Aitor Santamaría]

Hello Jim,

My own thoughts:

On Sun, 15 May 2022 at 21:56, Jim Hall  wrote:

> I'm interested in a parallel test distribution that gets updated on a
> regular schedule, by an automated (or mostly-automated) process. Let's
> say there's a new test distribution once a month. Each test
> distribution contains everything in the distribution that's current
> when it was built: packages, installer, translations, documentation,
> etc.
>
> For example, imagine monthly test distributions called "FreeDOS Test
> Build 2022-07," "FreeDOS Test Build 2022-08," FreeDOS Test Build
> 2022-09," ... you get the idea. These don't have a "1.3" or other
> version number on them, only a test build label.
>


> *How we would use this:
>
> We can leave FreeDOS 1.3 distribution as the *stable* release, and
> continue to make changes in the test distribution.
>
> Developers use the monthly test distribution if they want to test
> interoperability with other recent packages. Folks who want to test
> can always find the latest version to experiment with. Translators
> have the latest version. Documenters have the latest version. And so
> on.
>
> The test release label will make it easier to track bugs. "This bug in
> (program) was reported in FreeDOS 1.3, but that problem in (program)
> was fixed since then. Download the latest FreeDOS Test Build and see
> if that fixes it."
>
> At some point in the future (let's use July 2023 as an example) we
> might decide "there haven't been significant changes in the FreeDOS
> test releases in the last year .. we've only seen package updates, no
> big distribution changes .. let's make a 'FreeDOS 1.3 Update1' release
> with the new changes." And then we can promote "FreeDOS Test Build
> 2023-07" as "FreeDOS 1.3U1 RC1" and go through the testing. Bug fixes
> go back into the monthly test release, so "FreeDOS Test Build 2023-08"
> becomes "FreeDOS 1.3U1 RC2," and so on. When testing looks okay, we
> can release "FreeDOS 1.3U1" with very little effort.
>
Well, for this to work, all the updates on the test releases should be
corrective (patches). No new features should be added for this to happen,
otherwise, the test releases will fix some bugs and introduce new ones. For
this reason, it would be useful that the name contains the point version it
is based upon: "FreeDOS Test Build 2023-07 over 1.3" or whatever.

However, it is hard that not all tools would have both fix releases and new
feature releases.
If it were really easy an automated to create new distribution, ideally
there could be two lines: one that patches 1.3 and a second one that goes
toward 1.4.

Aitor
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Thinking about FreeDOS test releases

[Jim Hall]

Looking ahead to "FreeDOS Next," I wanted to continue the conversation
again about test releases for FreeDOS. Before, I called this idea a
"rolling release" - but that's not the right term. So that might be
why the last conversation on this topic didn't go anywhere.

*Where we are now:

We use a point release model for the FreeDOS distribution, where we
specifically label each distribution. Skipping the "alpha" and "beta"
releases, we've had FreeDOS 1.0, 1.1, 1.2, and 1.3 (and several
"Release Candidate" versions in between, such as FreeDOS 1.3 RC1, 1.3
RC2, 1.3 RC3, 1.3 RC4, and 1.3 RC5).

DOS doesn't change much, so our releases have been spread out over
time. But in that time, developers release new versions of their
programs. So between each distribution release, a bunch of individual
packages will get updated. But in the current model, most folks have
to wait until the next full distribution to see those changes.

I'd like to make it easier for everyone to test the latest version of
everything.

*Short version:
We keep the "point release" model, but add a parallel "test"
distribution that gets updated once a month. (Could be some other
cadence, I'm suggesting monthly because that seems like a good balance
to me.)

*My thoughts:

I'm interested in a parallel test distribution that gets updated on a
regular schedule, by an automated (or mostly-automated) process. Let's
say there's a new test distribution once a month. Each test
distribution contains everything in the distribution that's current
when it was built: packages, installer, translations, documentation,
etc.

For example, imagine monthly test distributions called "FreeDOS Test
Build 2022-07," "FreeDOS Test Build 2022-08," FreeDOS Test Build
2022-09," ... you get the idea. These don't have a "1.3" or other
version number on them, only a test build label.

*How we would use this:

We can leave FreeDOS 1.3 distribution as the *stable* release, and
continue to make changes in the test distribution.

Developers use the monthly test distribution if they want to test
interoperability with other recent packages. Folks who want to test
can always find the latest version to experiment with. Translators
have the latest version. Documenters have the latest version. And so
on.

The test release label will make it easier to track bugs. "This bug in
(program) was reported in FreeDOS 1.3, but that problem in (program)
was fixed since then. Download the latest FreeDOS Test Build and see
if that fixes it."

At some point in the future (let's use July 2023 as an example) we
might decide "there haven't been significant changes in the FreeDOS
test releases in the last year .. we've only seen package updates, no
big distribution changes .. let's make a 'FreeDOS 1.3 Update1' release
with the new changes." And then we can promote "FreeDOS Test Build
2023-07" as "FreeDOS 1.3U1 RC1" and go through the testing. Bug fixes
go back into the monthly test release, so "FreeDOS Test Build 2023-08"
becomes "FreeDOS 1.3U1 RC2," and so on. When testing looks okay, we
can release "FreeDOS 1.3U1" with very little effort.

Or, maybe we instead decide (let's stick with February 2023 as an
example) "there *have* been a bunch of structural changes, but it's
looking good." Maybe we've trimmed down the packages, maybe we've
changed the installer, or whatever other changes happen in the FreeDOS
test distributions. And we get to a point where we decide "this is
looking good, I think we can release this as '1.4' or '2.0'." And then
we can promote "FreeDOS Test Build 2023-07" as "FreeDOS 1.4 RC1" and
start testing. Changes go back into the monthly test release, so
"FreeDOS Test Build 2023-08" becomes "FreeDOS 1.4 RC2," and so on
until we finally release "FreeDOS 1.4."



I think the monthly test release would need to display a big red
dialog box when you boot it, saying something like:

: This is a test distribution release intended only for testing the
: latest changes in FreeDOS, and could be unstable. This is not an
: official FreeDOS distribution. If you want the official distribution,
: please download FreeDOS 1.3 from www.freedos.org

The idea is that anyone who downloads the monthly test release should
immediately recognize that this is not the stable distribution.



Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel