Hi Mercury and Jim, > On Jul 17, 2022, at 7:32 PM, Mercury Thirteen via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > In addition to "unstable", another practice commonly used by other software > projects for interim builds like those you're discussing here is to title > them based on their frequency, e.g. "nightly" or "weekly", etc. Perhaps this > would be the way to go?
That they do. Not a bad idea. However, we are looking at once a month. To me, FreeDOS Monthly sounds like a magazine. LOL. :-) >>> 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. :-) Yeah, i don’t think we want to wait that long. :-) > 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.” I think to normal users those terms would leave the following impressions… TEST - Hey, this is not a release. It is something we are trying out. If it works out and we like it, we will probably continue doing something like it for future releases. DEVEL - This is mostly for developers, But, you can check out what we are working on. But, It’s not quite finished. So, expect it to get better. UNSTABLE - This is what we are working on. It’s not ready for general use and expect to have some issues. But if you like the cutting edge and don’t mind having some hiccups, give it a whirl. Although each implies something a little different, they each leave a fairly similar impression to me. I don’t think using TEST will cause any user confusion. So lets go with that. :-) > >>> 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.”) During a release build by the RBE, all media gets a unique disk label. Mostly, this is to allow manually verification that the correct image is being used for different things. For example, although the installer is the same across all standard media (excluding the Floppy Edition), the media may boot with different configurations or settings in FDCONFIG and FDAUTO. A great example is the FreeDOS 1.3 LiveCD. If you boot the Live Environment, the CD boots one Floppy Image (FD13-HYDRA). However, booting that CD to Install to Hard Disk uses a different floppy image (FD13-CDBI). As for the meaning behind all the labels… FD13-BOOT - Boot diskette (Separate boot floppy image for running installer, included in ZIP archives for LiveCD and LegacyCD) FD13-LBFI - LegacyCD Boot Floppy Image, (Boot directly to install from LegacyCD. Nearly identical to FD13-BOOT and although it is interchangeable with that image contains some optimizations for booting directly from the CD) FD13-LEGACY- LegacyCD’s own disc Label. FD13-CDBI - Standard CD Boot Floppy image, (Boot directly to install from LiveCD. Like LBFI, is nearly identical and interchangeable with BOOT. But, tase some optimizations as well.) FD13-HYDRA - A multi headed monster, (Boot LiveCD to Live Environment, it refers to the multiple stages in bringing up the Live Env) FD13-HDX86 - Hard disk image version of Floppy Edition. (Boot LiveCD to install using Floppy Edition, aka FDI-x86) FD-CREDITS - Floppy image to show thank you credits on LiveCD. FD13-LiveCD - LiveCD’s own disc label FD13-BONUS0 - Non-Bootable Bonus CD #0 (Just incase we add more, maybe someday #0 games, #1 GUIs, #2 Dev Tools, etc.) FD13-LITE - Small USB stick disk label. FD13-FULL - Big USB stick disk label. Then there is the Floppy Edition Diskettes… Regardless of which set, the boot diskette is labeled FD13-BOOT. The archive diskettes are labeled FD13DSK01, FD13DSK02, etc. It is easy to forget how many images are required for all the different media and different ways of booting. > >>> 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. Ok. > >>> 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/ > ? I think “test” will be less confusing when browsing the filesystem. > > 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/ > > <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test.old/> If we used the test/2208/ method, we can store as many as needed. Another alternative is use test/, then retire previous ones to test/old/. Then if need-be, we could always keep more around in that subdirectory. I guess same goes for using a test.old/ scheme. But, just using test/ and test/old/ makes the most sense to me. One less entry in the distributions directory. We will have a month to decide. :-) > 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). Me too. :-) > Jim > > > _______________________________________________ > 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
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
