On Tue, Nov 19, 2019, 12:20 Liam Proven <[email protected]> wrote: > > IMHO one of the problems of Étoilé was that it violated the core FOSS > principle of "release early, release often". GNUstep comes close to > the same. > > Sticking some source code on a version control system somewhere is not > releasing something. > > Offering a set of binaries users can install is releasing.
I disagree. In FOSS, releasing source tarball is releasing, not offering a set of binaries. Offering binaries for a FOSS platform is a bonus; only on Windows and Mac would I expect to get a binary. Not to mention, we don’t stick it on a version control system (tagging is there just to help a bit); it goes to FTP, which is how FOSS and especially GNU software is properly released. GPG signed and all. Binaries are a bonus. I want to > see _at a minimum_ a Zip file or tarball I can grab, open and just run > on my distro, whatever that distro is so long as it is mainstream. > Tarball with binaries? Not going to happen with libraries, which is what GNUstep is. On FOSS *nix platforms, installing with a "wizard" is also not the expected way to go. .debs can be reasonably doubleclicked on, but again, GNUstep is a bunch of libraries; do you want to manually install "redistributables" like Windows games often do / require you to do? Oh, and running a library (which is what GNUstep’s components are) is... unlikely. Remember, GNUstep is not and does not have a proper DE. We discussed having a reference one, but there isn’t one at this time. You can get an approximation with WindowMaker+GWorkspace+SystemPreferences+more, but this is not actually The GNUstep Environment (because there isn’t one). Nextspace and Etoile and such are not part of GNUstep, but their releases would be their releases. (Examples: Rocket.chat, Waterfox, Franz.) > These sound like end user applications? > Neither Étoilé nor GNUstep does this minimal effort. > > Ideally, I want to see a repo I can add to my distro with a single > command, then I can install $product _and get updates from then on_. What is the $product? Which updates? :) > Ubuntu PPA and Fedora COPR repos make this easy; openSUSE hosts the > OBS and software.opensuse.org to offer equivalent functionality. > Ubuntu PPAs don't make it easy for developers, because I tried it. You provide it with a Debian-formatted source package, not a binary package or a raw tarball. It's great for the users, but you really have to be subservient to Ubuntu's build infrastructure to upload to PPA. Oh, and while you're working on the packaging, you have to upload the package to their systems waiting in a build queue only to see everything fail and try again. When I worked on it, it was nontrivial to reproduce their build environment locally. I can’t remember, but think I even got it to build with clang (can't recall), and I thought I'd manage to automate it enough to make regular updates or even nightly uploads. But no, it was enough effort that I dropped it. The build rules are still in gnustep-make; you can choose to create a source tarball, create a Debian source package (extra tarball plus metadata, iirc), GPG sign it and upload it to your PPA. Prepare for pain, though. > GNUstep doesn't do this, but it is at least well-enough known that > most major distros include dated versions and I can just cobble > together something that kinda-sorta works, a bit, from my distro's > repos. It is only when I joined this list that I discovered that the > Debian and Ubuntu bundles of GNUstep were very dated and that I needed > to add third-party repos to get something vaguely current. > Debian and Ubuntu usually update rather quickly once a release is made. I know because I drove the last few releases, and I got feedback from Yavor rather quickly. If maintainers of individual packages ask me, I can help with cutting a release again. It's just a few hours of work, nothing to fret about: analyze changelogs (compare VCS history with actual ChangeLog files), update news files, check everything in, find the GPG key which I last used months/years ago, wrestle with the rather long passphrase, cut a release, upload the tarball and .sig to GitHub and FTP, and repeat that for all packages. This is even without cutting the Windows release, which I never did and have no idea how to do, especially without a running Windows environment. I had a dream of building the NSIS installer on Linux (mingw32 to build, NSIS to package), but I never got around to it. I also wanted to switch to MSI, but msi-tools on Linux don't know how to generate the UI tables in .msi databases, so I dropped that. Oh, right, and bumping the version or not depends on whether binary compatibility broke, which is what I don't have the tooling to check so I depend on Yavor's kind feedback when I prep a prerelease. As I said, I can cut a release, but let's not say this is easy. It would be easier if news files were correctly kept up to date, but it would become harder if I also had to cut .debs. Yavor does a stellar job ensuring Debian quality control automation doesn't throw a fit, he reports bugs, files patches. I'm not quite willing to do that for a custom PPA. Imagine if the release person (e.g. me) would have to also do this not just for Ubuntu (preparing source PKG + .deb), but also for Fedora/RedHat/CentOS, then for Arch, Suse, then for various remixes of those? Sure, we should automate some of this. But then we should maintain the automation too which not may, but WILL break. I’m enthusiastic, but not that much... > Periodically there have been all-in-one demo disks of GNUstep (GNUstep > Live, Simply GNUstep, etc.) to show off what it can do. AFAIK Étoilé > never even got this. > > If the only way to try something out is to compile it yourself, then I > am probably never going to bother. That's too much work for me, and I > suspect this is true for 90% or more of Linux users. > Users can use "outdated" releases. No harm there. GNUstep is just libraries. If they work for newer apps, they don’t need an update. Now... developers may need updated versions when developing their apps. I remember Debian not shipping with NSViewController or NSWindowController when I first came around -- but on the other hand, when I would cut a release, an updated .deb would follow. (Not to mention our source code became much more discoverable, so seeing if a class is missing is much easier too.) So when a developer needs a newer version so they can prepare a source tarball for Debian to integrate... they can talk to us. We cut our release, a Debian maintainer (e.g. Yavor) picks it up, the app gets picked up too, everyone happy. Yes, I would say developers are very welcome to advocate with maintainers for a release if not cutting one blocks their app's release. :-) And at this time, I am still here to help component maintainers with a release. I may not do it on a tight schedule, but eventually I’ll find an evening or two to tackle this kind of request. Do you have a specific anecdote about something you wanted up to date, as a binary, which wasn’t in your favorite distro? > -- Sent from Gmail Mobile
