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 list > cdesktopenv-devel@lists.sourceforge.net > https://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
