> On Sep 27, 2024, at 4:51 PM, Michael Brutman via Freedos-devel > <freedos-devel@lists.sourceforge.net> wrote: > > > I read that there were some previous bad experiences with shipping source > code separately, but I think it should be looked at again with a fresh set of > eyes. > > Some reasons to ship source code separately: > Few people are actually using it. Most people are never going to look at the > source code - it is just wasted download bandwidth and space. > Other open source projects ship source code separately. This is a solved > problem. > Using the source code generally requires other downloads too. Source code by > itself is bad entertainment - people need compilers and toolchains. So we > are not really reducing the friction to use the source code when we ship it; > the greater friction is in setting up a development environment. > For current projects we are shipping stale source code. mTCP is a good > example of this ... I really hate seeing people pick up old binaries and > source code from FreeDOS. I'd rather point them to the canonical source for > downloads and source code and mirror those as a secondary option in case the > primary source goes dormant. > > -Mike >
I wouldn’t call the source code stale. It is the source for the version provided. But, there are newer versions for some packages. Some require building from source. Some are tricky to update. Some are updates that have not been noticed. Some are ones I just haven’t got around to doing. Only so many hours in the day. :-) If you or anybody else in the devel mailing list would like to help keep any of actively maintained projects more up to date in the GitLab archive (used to stage packages for the OS release), let me know. As for the binary + sources… I agree that most end users will never use the sources, don’t care if they have them and would prefer smaller downloads. Honestly, it does not matter much to me personally if each package contains its sources on the release. Or, if there is a separate SourceCD. But, I do want to point out a couple things. Packages are staged on GitLab with sources. The RBE (Release Build Environment) is fully automated. It looks at what packages are to be included on the release. Then , it checks those projects out of GitLab. It does some processing and verification on the cloned project and generates the packages for the release. With a little adjustments to the RBE it can easily split those into two packages a source and a binary. This would be consistent and reliable. There is no way that the package sources could be out-of-date for the binaries simply from splitting them up. Nor, would sources get accidentally excluded by the RBE. If the package on GitLab has the proper sources, they will end up on a SouceCD when the get included in the release. Other than updating the RBE to perform this duty, it is a non-issue. However, if we include all that stuff on one Binary CD, we really should not install everything with FULL. That would mean that there are more packages on the disc after install. A simple solution to prevent any confusion is to have the installer inform the User during installation that even more stuff is available after install. Maybe have a message on the BASE/FULL selection screen that says something like “there are additional bonus packages on the install media that can be installed using FDIMPLES after the OS install has completed” or something similar. :-) 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
