Re: [Freedos-devel] FreeDOS interim development build

[Aitor Santamaría]

Hello,

Thanks for the answers!


On Sat, 25 Jun 2022 at 22:32, Jerome Shidel  wrote:

> 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”
>

Ok, commit logs are a good source too, but this advices to write good
(user-readable) commit logs.


> 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) 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/
>> 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/
>>
> 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.
>

It would be for each major, or for every unstable too? (in the latter, it'd
require a lot of space, right?)

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

Re: [Freedos-devel] FreeDOS interim development build

[Jerome Shidel]

Hi Aitor,

> On Jun 25, 2022, at 3:22 PM, Aitor Santamaría  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 
> ) 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/ 
> 
>   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/ 
> 
> 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 

Re: [Freedos-devel] FreeDOS interim development build

[Aitor Santamaría]

Hello Jerome,

I'll give you my opinion on some of these.

On Sat, 25 Jun 2022 at 15:02, Jerome Shidel  wrote:

> First, how will we Label and refer to these builds? I went with “Unstable”
> with the short name would be “FreeDOS U2207” and long name as “FreeDOS
> 2206-Unstable”. To me, it is a well established nomenclature. However to
> the general user base, that may not be the case. We could use “Unstable”
> for now and possible change it later. But, I think we should commit to a
> scheme and stick with it for the foreseeable future.
>
> Should we stick with “Unstable” or use…
>
> Test build; FreeDOS 2207; FreeDOS 2207-TEST
> Development build; FreeDOS DEV2207; FreeDOS 2207-DEVEL
>
Personally, I don't see "DEVEL" as option, as it may give the impression to
be "for developers".
As for the other two, be it TEST or UNSTABLE, I like the idea of YYMM, so
that we get a monthly unstable version that can be downloaded.


> Second, do we want the changes log to go back as far as the previous
> interim build or back to the previous OS release? At present, it limits
> itself to the previous build. But since users / testers will probably not
> test every iteration, I think it may be best to always include everything
> back to the previous official release. At present that would be FreeDOS
> 1.3-Final.
>
I am of the same opinion, go back to the last official.
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.

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) 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/
> 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/
>
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?

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

[Freedos-devel] FreeDOS interim development build

[Jerome Shidel]

Hi Jim and all,

Well, the work I wanted to do to the RBE and release media is finished. I’ve 
replaced the downloads on my server with the new versions. You can fetch them, 
or view the report information at https://fd.lod.bz/releases/unstable/ 
 

Mostly, the additional stuff I wanted to get in there came down to two more 
things mentioned earlier. The interim builds include a warning message 
displayed at boot (from install media and one the installed system). Also, the 
interim build uses a different theme for the installer. Basically the theme is 
the same as the normal mode except instead of a blue background, it is black.

In order for us to have the first interim build officially available on 7/1, 
there are a couple minor items that need a final decision…

First, how will we Label and refer to these builds? I went with “Unstable” with 
the short name would be “FreeDOS U2207” and long name as “FreeDOS 
2206-Unstable”. To me, it is a well established nomenclature. However to the 
general user base, that may not be the case. We could use “Unstable” for now 
and possible change it later. But, I think we should commit to a scheme and 
stick with it for the foreseeable future.

Should we stick with “Unstable” or use…

Test build; FreeDOS 2207; FreeDOS 2207-TEST
Development build; FreeDOS DEV2207; FreeDOS 2207-DEVEL

Or, some other specific terms or variation?

Second, do we want the changes log to go back as far as the previous interim 
build or back to the previous OS release? At present, it limits itself to the 
previous build. But since users / testers will probably not test every 
iteration, I think it may be best to always include everything back to the 
previous official release. At present that would be FreeDOS 1.3-Final. 

Third, what path do we wish to provide them on ibiblio under 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/ 
 ?

I prefer 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable 

 or 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/unstable/2207
 

 

But, we could use dev, devel, or test. I don’t think unofficial/dev is 
the best choice and suggests it is not an official test version. But, that 
could just be me. As always, whichever you decide is best. 

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 
) 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/ 

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/ 


I think using 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/ 

 makes sense. It also makes it easy for users running one of the Official 
Release versions (1.1, .1.2, 1.3) to find and try the latest versions of 
package updates. However if you think renaming it to something like “TEST” or 
“DEV” is a better choice, it is easy to adjust. The repository management 
utility is flexible with such things and at is also not a problem to put it in 
an entirely different directory not under “repositories”. 

Let me know what changes you want. None of theses changes are that difficult or 
time consuming. Hopefully, we will can make the first interim build available 
on  7/1. 

:-)

Jerome


 


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