Hi Aitor, > On Jun 25, 2022, at 3:22 PM, Aitor Santamaría <aitor...@gmail.com> wrote: > [...] > How do these logs build up? (I am assuming logs in an user-readable format). > Every time someone updates a tool, do we need to fill in somewhere? > Ideally, the implemented bugs and enhancements from GitLab would go to the > list, but I guess the ticketing system is not being widely used. ANother > option would be that every time a new version comes, instead of logging > somewhere else, someone simply logs a new enhancement ticket in GitLab with > the changelog.
The packages are all sourced from the GitLab Archive. A couple other key components to the release (like FDI, FD-NLS, RBE, etc) are pulled from their own GitHub/GitLab projects. The CHANGES.LOG is created using the commit comment messages for each project. For example, if KEYB on the GitLab archive has a commit pushed with the comment “Fixed double keypress bug”. That comment would appear in the CHANGES.LOG as something like “2022-06-29 04:52:11 keyb (Aitor Santamaría): Fixed double keypress bug” Also if for example that same commit was made to a branch (other than master/main) as a "test fix”, it would be identified as such in the LOG. By default, the interim builds check for an “unstable” branch and will use that instead of the master/main branch when creating a build. That would look like “2022-06-29 04:52:11 keyb [unstable] (Aitor Santamaría): Fixed double keypress bug” For projects that are maintained elsewhere and just get copied and adjusted into the GitLab Archive, they usually just get a version number. However, we can include more information in the commit message. For example, I updated DOSLFN to v0.41f yesterday. It’s logged as "2022-06-24 08:54:13 doslfn (shidel): v0.41f - More extending directory fixes and basic version check” It’s possible that we may include a compatible CHANGE.LOG for the maintained elsewhere projects in their GitLab Archive’s version. But, I’m not sure that is necessary or desirable. They get the version number comment and if someone is interested they could check that projects change.log. After all, it’s not actually changes that we would have made. IDK. > > Finally, what path on ibiblio do you want to use to provide package updates? > This has nothing to do with creating the interim build. As you recall, the > current RBE uses the GitLab FreeDOS Archive (https://gitlab.com/FreeDOS > <https://gitlab.com/FreeDOS>) to create the packages on the release. It can > also automatically pull specific branches of those packages based on the > release, interim, development or other type of build it is creating. The > package update url only applies to where the release / interim build will > check for package updates. > > I think it makes sense to keep it along side the other OS update > repositories. There are already repositories for each Release > > 1.1 - > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.1/ > <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.1/> > 1.2 - > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/ > <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.2/> > 1.3 - > https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/ > <https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/> > I don't know if I am getting this well: this means that in the 1.2 folder you > find the packages updated over 1.2? > This means that if at this moment there appears a new updated package that > hasn't been updated earlier, it should go into ALL of the 1.1, 1.2 and 1.3 > folders? Basically, yes. There is a separate software update repository for maintained for each of OS release. This supports the ability for packages under different OS versions to use different paths, settings, options, versions or other differences. However, generally there is no difference in the actual update packages for each release. The repository management utility has no problem maintaining a bunch of separate repos. When an update is made to a package, we can just drop a zip in one of a couple directories on the server. The repo management stuff will grab it, stick it into the proper repository, generate file-system links, versioned webpages, etc. However, it will have at 1 copy of the update zip in each of the update repositories. When I eventually get around to making the next version of the repo management utilities, it will be able eliminate multiple cross-repo duplicates and conserve wasted disk space. That along with desktop clients to more easily manage them, multi-repo comparison, syncing and numerous other improvements. But, I’m just one person and it keeps getting put off in favor of other more immediate needs. Someday hopefully, I will get to it. > > AItor :-) Jerome
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
