I have thoughts on this. I hate the idea of this project being in the business of providing binaries for distros.
The reason for this is precisely the one in your last sentence before the word "Thoughts?" I personally have a full-time job that already involves doing software testing, packaging, and distribution using Jenkins, a large build farm, and CPack's package generators (even though my job is *supposed* to be doing R&D), and I don't need a second one that doesn't pay. I am unwilling to chase down all the possible distros to set up virtual machines so that I can build (or automate the building of) packages for operating systems I don't use and do the work required to get every single package maintainer to place the new package into a package repository. Travis is great for picking up build errors, but the limited set of systems it supports means it's basically useless for overcoming the real issues we have of distro support. That *has* to be left to people who actually work in the package system of each distro. Even if you create packages, they won't be part of any distro's package management system unless the package maintainer for the distro chooses (or is allowed) to push it to the package repo. If you feel like setting up a jenkins instance and running a suite of docker or virtual machines, learning every distro's packaging system, and doing all that work, then I have no problem with you doing it. And when you inevitably get exhausted by the process (and the likely endless requests to add one more system to the mix) I'll be very happy to say "I told you so." On Mon, Apr 22, 2019 at 12:28:24PM -0700, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > It's been suggested that our current method of having non-project people do > packaging on an ad-hoc basis isn't working. Often the packages available in > various Linux distributions are years old. > > I was thinking about how to make Travis-CI do auto-packaging of releases. > It's possible, but the OS'es available on Travis-CI aren't the newest so > there wouldn't be a big impetus to do so. The current list on Travis-CI is: > > Ubuntu-14.04 (2014) > Ubuntu-16.04 (2016) > OSX-10.13.3 > > So... While Travis-CI is excellent to let us know when we break something > or new warnings show up, it's untenable for packaging targeted towards many > or newer OS'es. > > I have Jenkins (another CI engine) running at home. At the time I set it up > the Xastir project was still on Sourceforge. My Xastir Jenkins builds > haven't been re-targeted to Github yet, but using Jenkins I could set up > auto-packaging for the OS it's running: OpenSuSE-42.3. Even that isn't the > latest-latest OS version. > > Not sure what to do about other OS'es. Setting up VM's / Docker instances > for several different current OS'es to do packaging might be a full-time > job. Even after the initial bunch of work, adding newer OS'es and keeping > things running might also be a full-time job. > > Thoughts? -- Tom Russo KM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
