>>On Jun 22, 2022, at 1:05 PM, Jim Hall <jh...@freedos.org> wrote: >> >>I like the idea of the interim development builds. This should be a >>great way to test new changes that everyone can experiment with! >>Thanks for doing this. >> >>I'm thinking about how people will (mis)interpret the "FreeDOS >>Unstable" name. I wonder if "FreeDOS Test" might be a better name for >>this. > On Wed, Jun 22, 2022 at 1:22 PM Jerome Shidel <jer...@shidel.net> wrote: > > I don’t think “Unstable" would cause much confusion. I think it > is a well understood and established term for such releases. Many > users are familiar with it from the Linux world. However, it is not > a big deal to switch it from using the “Unstable” to “Test” > or “Devel”. Maybe it’s a good question to put to your usability > class.
The usability course is in the Spring semester, so that's a long time. :-) But in my experience, I think "test" or "devel" is a better label than "unstable." While "unstable" may be a term well known by other developers, remember that ordinary users will find it, and will get confused by "unstable." >>The benefit of "Test" is that it is short enough to combine with >>the "year+month" label and stay conveniently within an "8.3" filename, >>so you have "TEST2207" and "TEST2208" and so on. (I know "8.3" names >>aren't necessary for the web server, but it's a nice symmetry for >>FreeDOS.) > > Actually, not quite… For example, each of the media get’s it’s > own volume label to help differentiate them. For example, with 1.3 the > CD boot floppy was “FD13-BOOT” but the image to boot directly from > the LegacyCD is “FD13-LBFI”. So for all of those, they get labeled > things like U2206-BOOT and U2206-LBFI. I guess the 8.3 filename doesn't matter as much to me, that was just a suggestion because "test" was conveniently short. But I'll add that we probably don't need to worry about 8.3 filenames for the download zip file. "FD13-LiveCD.zip" and "FD13-BonusCD.zip" from FreeDOS 1.3 didn't use 8.3 filenames for the download. So the interim build download files could have longer names that are more descriptive. I'm not sure what "LBFI" stands for, though. I'm bad at remembering acronyms. (I live by the old 1990s joke, "PCMCIA stands for People Can't Memorize Computer Industry Acronyms.") >>Also: I'd prefer to keep the repository for this separate from the >>FreeDOS official 1.3, 1.2, and and 1.1 distributions. If we put the >>interim development builds in the same "repositories" path as the >>official distributions, I think people could easily be confused about >>the status of the interim development builds. I think a better >>location is under the ".../distributions/unofficial" parent location: >>https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/ > > I’m not sure about the “unofficial” label. It suggests it is > not an official version of FreeDOS and is akin to a 3rd party fork of > the OS. Good point on "unofficial." And that would allow me to delete the "unofficial" directory tree (which is empty anyway). I'm okay keeping it in the https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ directory on Ibiblio, if the name is clear. Something like https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/devel/ or https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ would be okay, for example. >>The path for the "FreeDOS Test" interim development builds would be: >>https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/ > > I was thinking go just > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable > and only keeping the latest one around. How about "latest plus 1 previous" instead? I take your other point (below) that the builds could be quite large, so it's probably not a good idea to keep every single build. But I'm thinking about the use case where someone reports a bug on the interim test build, and a day later we put out a new interim test build (which may or may not have fixed the bug on its own .. or maybe the "bug" wasn't really a bug, but something else) and now we can't go back to compare what happened in the version that the bug was reported against, to make sure the bug is really fixed in the current version. Keeping "latest plus 1 previous" seems like a good solution without taking too much space. >>And the path to the interim development builds package repo (index >>page) would be: >>https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/pkg-html/index.html > > Not a problem to move it. > > But when a user is not testing the interim build, it may make it more > difficult for them to find and try the latest versions of packages. > >>If we want to create an ISO "snapshot" of a specific test build, we >>can use the "year+month" path to create a clearly labeled directory: >>https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unofficial/test/test2207/ > > We could. But at roughly 2gb per build, they use a lot of disk > space. That will add up quickly doing monthly builds. > > I’ve uploaded the current interim test build version (U2206) to > my server in a sub-directory of https://fd.lod.bz/releases/ I have > not added a boot warning yet or implemented the black background > in the installer. There are several aspects to look at and discuss > before doing the official interim development releases. For example, > the report includes in document links to change summaries. > > Just let me know what we need to change. > Summary: 1. Can we use https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/devel/ or https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/ ? 2. Can we keep "current plus 1 previous"? For example, https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/devel.old/ or https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test.old/ And not to lose the original point: I love that this becomes a way to test current changes. And I love that this could help accelerate new releases; we might say "this release is pretty solid, if no issues found in [n] weeks, we'll make this the 'FreeDOS 1.4 RC1' distro." And so on until FreeDOS 1.4 (or 2.0, whatever we call it). Jim _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
