I'll change the wiki pages accordingly when I have the time (probs tomorrow). I would suggest that once a major change has been done (like recently solving the gcc 10 breakage) we test on all platforms and push out a new source package. That way we've always got a safe release for new users or people like me who actually use CDE in everyday work.
Btw, Jon, you probably installed the binary packages, but that can leave you with fairly outdated packages in the older FSBDs that are still in support (9x, 10x). I was talking about building from source. If you use precompiled packages, you can actually use the binary CDE package just as well. FreeBSD is the only distro that comes with a precompiled CDE. They're currently providing 2.3.1. Cheers, Danilo On Sun, 29 Nov 2020 at 01:21, Jon Trulson <j...@radscan.com> wrote: > On 11/28/20 3:54 PM, Danilo Pecher wrote: > > Hi folks, > > May I offer a suggestion? We need something of a release strategy. We > should depart from the "pull stuff from the git repo" strategy in the > Wikis, because we keep breaking our build by pushing untested stuff. > > As I build CDE daily on several platforms to test the builds, I can pretty > much pinpoint the latest breakage to Thursday. On Wednesday it built on > FreeBSD, NetBSD, Raspbian, Ubuntu, Fedora and CentOS - on Friday it was > broken on all of them because of the breakage I reported earlier today. > > > This is going to happen... The issue is not a release strategy problem, > it's a lack of CI problem. Of course the mistake in the above issue was > committing a change that had not been tested in a full CDE build. That is > something we try very hard to avoid, but apparently that did not happen > with the libcsa changes. > > But a problem is that that even if it had, and lets say it worked on the > linuxen - there is no guarantee it would not break on the BSD's or Solaris > for example since people will (hopefully) test on the OS/hardware they > have, and that will be good enough for them. > > Ideally, when someone comes across a problem on a platform, they should > send a patch along that fixes it. But not too many people do that. As a > matter of fact, it's pretty rare these days. > > And I can only speak for myself, but I have a day job - so I don't get a > lot of time anymore to 'play' with CDE, and write patches for people who > can't be bothered to write and submit them themselves. > > Having some sort of CI would be a good interim solution for that, but > alas, there is no such animal with SF. It would be up to people (like you) > who can/do run multiple OS's and can identify problems. But then depending > on that has it's own issues as people enter and leave the project. > > I'm not really sure how to resolve that problem, other than setting up > some sort of setup like you have and using jenkins or some such to test all > builds (based on a commit) and send a status somewhere indicating failure. > But that will take more time than I currently have, and money too. > > Master should generally always be considered 'unstable' - though it should > ALWAYS be build-able on linux (ubuntu LTS). Though I will admit - if you > send a patch or commit one, you should certainly make sure it doesn't break > things. But as I mentioned above, without some kind of formal CI > infrastructure we can't really 'enforce' that. > > For me personally that isn't much of a big deal, but I'm out there banging > the drum for the project and I look a bit of a berk if people then run into > a broken build by following our Wiki instructions. Wouldn't it be better if > we regularly released tested tar.gz releases and left the bleeding edge git > stuff to internal testing? It would also greatly reduce the > pre-requirements, especially on FreeBSD where, due to the rampant > dependency bloat in the ports collection, just compiling git can easily > hand you a 3-hour time penalty. > > > Odd... I was test building on FBSD some months ago for the autotools > branch, and I just installed the relevant packages. IIRC, there was very > little I had to actually build via the ports collection, and when I did, I > only needed to do it once. Don't recall off-hand what I built vs. what I > installed via the package manager. I believe I just followed the wiki :) > And building git cannot be more expensive than building CDE... > > Also, 2020 has been somewhat of a challenging year :) > > -jon > > > > > Cheers, > Danilo > > > _______________________________________________ > cdesktopenv-devel mailing > listcdesktopenv-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > > -- > Jon Trulson > > "Entropy. It isn't what it used to be." > -- Sheldon > > _______________________________________________ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
