Re: [GNC-dev] GnuCash and Github
I don't think the silo effect is a big deal. The main impact is on transferring bugs and we gave that up when Gnome shut down its Bugzilla instance. Cross-project pull/merge requests make no sense, so I guess your complaint is that you can't use your Github account to submit a PR to e.g. Gtk because while there's a Gtk mirror on Github it doesn't take PRs, you have to get a Gnome LDAP account and make your MR (merge request, gitlab's name for pull request). Based on what I see over at Gnome running a gitlab instance is a lot of work. Plus even with the Gnome Foundation's compute resources it frequently bogs down. I don't think we'd want to do that. I'd never even heard of gitea or codeberg and I've encountered only one project on sourcehut. I wasn't terribly impressed. We could switch the git mirror to Sourceforge, which would get us the code-browsing, though not as nice as GitHub's, and the merge requests. I don't know how the edit/discussion flow works there, but I bet it's not as nice as Github's either. That leaves CI. Sourceforge doesn't provide it, so we'd have to set up our own instance of something; Jenkins used to be popular but I don't know if it's still considered the best. Regardless that's more time spent setting it up, securing, and maintaining it. Regards, John Ralls > On Nov 18, 2022, at 9:15 AM, Geert Janssens > wrote: > > That's a good analysis of the situation. > > I agree this is largely a legal issue to be solved by organisations like the > SFC. > > At a deeper level though I agree this could only have happened because OSS > has allowed github to become such a golden cage for our projects in the first > place. And this seems to happen over and over again. > > It has become very hard to leave github because of the network effect. And I > agree we can't make others not have a clone of the gnucash repo on github. > That doesn't mean we can't make a statement by not hosting our own > forks/clones there ourselves if we care enough. > > I don't know if *I* care enough. I am concerned about these developments, > but at the same time I wouldn't want to add more infrastructure maintenance > to our already limited time. > > SFC suggested a few alternatives, either hosted (sourcehut, codeberg) or > self-hosted (gitea, gitlab CE, sourcehut). > > Codeberg is very similar to github, except for CI (which is currently in > closed beta). So it offers much of what our users/contributors are already > used to. > I don't know about the others. > > As a last semi-OT remark/rant, I think all the alternatives are missing a key > piece - federation. > > You either have a centrally hosted platform(codeberg.org,...), or you have > completely isolated islands that happen to use the same software (think > gitlab.gnome.org, gitlab.kitware.com,...) > > The centrally hosted platforms will invariably lead to similar silo effects > as github.com or gitlab.com if they become more successful. The islands on > the other hand currently have no means of interaction or integration (like > tracking an issue issue on another 'island's' tracker, forking to another > 'island', creating pull requests across 'islands',...). So in both cases the > very distributed nature of git is not brought up to the level of the web > interfaces. > > The social media landscape is in the same boat in fact, though federation may > very slowly be getting a foot in the door with the recent twitter debacle and > a fair number of users now start to experiment with Mastodon. > > Regards, > > Geert > > Op zondag 13 november 2022 20:50:53 CET schreef john: > > My number one use of GitHub, and IIRC the reason we mirrored it there in the > > first place, is to refer to and reference code when communicating on these > > lists, bug reports, and IRC. That's replaceable too by serving the repo > > ourselves or moving the mirror back to Sourceforge. > > > > The fear is that Github's copilot will violate our author's copyrights by > > copying sufficiently substantial sections of code into a non-GPL project, > > stripping off the copyright and license in the process. I've seen claims > > that this has already happened. > > > > In my completely non-legal opinion that makes every project that uses > > CoPilot GPL and the FSF should be suing all of them to publish their source > > code. But I think that's also true of any project whose developers read > > Stack Overflow or search on the web for solutions to their coding problems. > > The world has changed since the GPL was conceived and sharing source code > > meant sending me a blank DECTape and a paid mailer or downloading a tarball > > by anonymous FTP and code on the web--regardless of where--is findable by > > web-searching for a function name, and even if we don't provide web access > > someone else will. The GPL encourages that. > > > > Plus the bird has flown. Sure, we could take down our Github repo. That > > won't affect the 673 forks, and some of
Re: [GNC-dev] GnuCash and Github
That's a good analysis of the situation. I agree this is largely a legal issue to be solved by organisations like the SFC. At a deeper level though I agree this could only have happened because OSS has allowed github to become such a golden cage for our projects in the first place. And this seems to happen over and over again. It has become very hard to leave github because of the network effect. And I agree we can't make others not have a clone of the gnucash repo on github. That doesn't mean we can't make a statement by not hosting our own forks/clones there ourselves if we care enough. I don't know if *I* care enough. I am concerned about these developments, but at the same time I wouldn't want to add more infrastructure maintenance to our already limited time. SFC suggested a few alternatives, either hosted (sourcehut, codeberg) or self-hosted (gitea, gitlab CE, sourcehut). Codeberg is very similar to github, except for CI (which is currently in closed beta). So it offers much of what our users/contributors are already used to. I don't know about the others. As a last semi-OT remark/rant, I think all the alternatives are missing a key piece - federation. You either have a centrally hosted platform(codeberg.org,...), or you have completely isolated islands that happen to use the same software (think gitlab.gnome.org, gitlab.kitware.com,...) The centrally hosted platforms will invariably lead to similar silo effects as github.com or gitlab.com if they become more successful. The islands on the other hand currently have no means of interaction or integration (like tracking an issue issue on another 'island's' tracker, forking to another 'island', creating pull requests across 'islands',...). So in both cases the very distributed nature of git is not brought up to the level of the web interfaces. The social media landscape is in the same boat in fact, though federation may very slowly be getting a foot in the door with the recent twitter debacle and a fair number of users now start to experiment with Mastodon. Regards, Geert Op zondag 13 november 2022 20:50:53 CET schreef john: > My number one use of GitHub, and IIRC the reason we mirrored it there in the > first place, is to refer to and reference code when communicating on these > lists, bug reports, and IRC. That's replaceable too by serving the repo > ourselves or moving the mirror back to Sourceforge. > > The fear is that Github's copilot will violate our author's copyrights by > copying sufficiently substantial sections of code into a non-GPL project, > stripping off the copyright and license in the process. I've seen claims > that this has already happened. > > In my completely non-legal opinion that makes every project that uses > CoPilot GPL and the FSF should be suing all of them to publish their source > code. But I think that's also true of any project whose developers read > Stack Overflow or search on the web for solutions to their coding problems. > The world has changed since the GPL was conceived and sharing source code > meant sending me a blank DECTape and a paid mailer or downloading a tarball > by anonymous FTP and code on the web--regardless of where--is findable by > web-searching for a function name, and even if we don't provide web access > someone else will. The GPL encourages that. > > Plus the bird has flown. Sure, we could take down our Github repo. That > won't affect the 673 forks, and some of those folks will get our code from > somewhere and keep their repos up to date. > > In fact it seems to me that the Software Freedom Conservancy is missing the > point: The problem with Copilot isn't that it's encouraging > proprietary-software developers to use open-source code in their projects. > Although the GPL requires that using GPL code turns the project into a GPL > one, most other FLOSS licenses don't. They require only that copyright ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
We could pinch from Debian and use stable, testing, and unstable, where testing
is the alpha/beta pre-major-release weeklies.
Regards,
John Ralls
> On Nov 18, 2022, at 7:55 AM, Geert Janssens
> wrote:
>
> I'm fine with just doing the simple name change for our two primary branches
> as it's the option of least effort.
>
> I'd rather have a different name than "main" though. It's a bit ambiguous and
> like "master" suggesting this branch is somehow more important than the other
> long-term branch "maint". I'd rather have names that help guide contributors
> to the right branch to work from. I don't think there's a silver bullet here
> though, but some names may give more of a hint than others. Some suggestions:
>
> * "current" vs "future" as shorthands for "current-release-series" or
> "future-release-series"
> * "maintenance" ("maint") vs "development" ("devel")
> * "stable" vs "development"
>
> That said, I'm also very interested in the single branch model as
> alternative. Discussion on that is for another message.
>
> Regards,
>
> Geert
>
> Op maandag 14 november 2022 20:59:26 CET schreef john:
> > > On Nov 14, 2022, at 11:11 AM, Alex Aycinena
> > > wrote:
> > >
> > > how about a simple change, like calling it 'main' rather than
> > > 'master' and keeping the existing pattern for branches.
> >
> > That would be OK as long as long as the two names aren't similar. main and
> > stable would be OK; with main and maint one is far too likely to do
> > something to the wrong branch.
> >
> > Regards,
> > John Ralls
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Dependencies policy for major releases
Op zondag 13 november 2022 20:08:15 CET schreef john: > > On Nov 13, 2022, at 6:28 AM, Geert Janssens > > wrote: > > > > How recent then can "more recent" be ? In my mind anything that's in the > > most recent LTS, should be fine in all cases. For anything more recent > > than that, we should consider how hard it would be to self-build the > > dependency. > For clarity, I think you mean Ubuntu's latest LTS, currently 22.04. As far as I know there are only two primary LTS distros: - RHEL - Ubuntu LTS All others are derived from either of these. In the RHEL 7 series, gnucash got stuck on version 2.6.x - I think - due to dependency issues. We moved on, but started to ignore RHEL at that point. In addition it's not really RHEL that carries gnucash. It can only be installed via an add-on repository, EPEL. In Ubuntu, gnucash is in the Ubuntu proper repos. Also contrary to RHEL, Ubuntu LTS has a clear release cadence of two years. For RHEL the time between major releases has been very variable (6 years between 7 and 8, 3 years between 8 and 9, with no commitment to a certain cadence). All reasons it makes it much harder to predict when our dependencies will be updated on RHEL. On the other hand I found today that EPEL 8 ships gnucash 4.9 (https:// packages.fedoraproject.org/pkgs/gnucash/gnucash/epel-8.html[1]). Interestingly I didn't find gnucash for RHEL 9 in EPEL. I haven't followed the evolutions in that area so I don't know any details. That's a lot of ambiguity around a distro to base minimum dependency decisions on. So yes, I meant Ubuntu LTS 22.04 when I wrote that bit. > > > The other approach, where we freeze minimum dependencies on the stable > > branch, sounds like a nice compromise, but has the drawback that it makes > > the stable code more complicated in order to accommodate support for > > multiple versions of a dependency. So we trade the stability of an older > > dependency for complexity in our own code. I don't know if that's really > > a good trade-off for a small development team. > I think that means that we'd bump a dependency's minimum version only in the > case where there's an API change that would otherwise require that we have > to #ifdef on the dependency version--or rather that bumping the minimum > version lets us remove ifdefs introduced to keep building on both the > current Ubuntu LTS and bleeding-edge distros like Arch Linux and Debian > Unstable. > Just for clarity, you're still talking about our stable series as well, right? In practice this means we indeed may have to introduce #ifdefs if a bleeding edge distro makes API changes that affect our code and that we only can remove them the moment a new Ubuntu LTS release ships. I don't know the exact details of the LTS lifecycle. I know there are intermittent sub releases for the LTS as well (as opposed to the normal Ubuntu releases), but I have no idea which if any library version bumps are allowed in these sub releases. > Then there's Gnome and macOS which have very nice versioning macros and > deprecation policies that let you tune what the compiler will warn about. > See e.g. https://docs.gtk.org/glib/const.VERSION_MIN_REQUIRED.html. There's > a corresponding GLIB_VERSION_MAX_ALLOWED that somehow eluded gi-doc, see > glib/versionmacros.h.in. There are corresponding macros for Gtk and Gdk. > The idea is that MIN_REQUIRED will emit deprecation warnings for API > deprecated in that version or earlier while MAX_ALLOWED will warn if you > use API that was introduced after that version. Should we start using these > to try to keep our code more current? (I think so.) If so how should we set > them? > I'm not sure I get how these can help us. Can you give an example of when and why to set either parameter ? Regards, ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Git branches
I'm fine with just doing the simple name change for our two primary branches as
it's the
option of least effort.
I'd rather have a different name than "main" though. It's a bit ambiguous and
like "master"
suggesting this branch is somehow more important than the other long-term
branch
"maint". I'd rather have names that help guide contributors to the right branch
to work from.
I don't think there's a silver bullet here though, but some names may give more
of a hint
than others. Some suggestions:
* "current" vs "future" as shorthands for "current-release-series" or
"future-release-series"
* "maintenance" ("maint") vs "development" ("devel")
* "stable" vs "development"
That said, I'm also very interested in the single branch model as alternative.
Discussion on
that is for another message.
Regards,
Geert
Op maandag 14 november 2022 20:59:26 CET schreef john:
> > On Nov 14, 2022, at 11:11 AM, Alex Aycinena
> > wrote:
> >
> > how about a simple change, like calling it 'main' rather than
> > 'master' and keeping the existing pattern for branches.
>
> That would be OK as long as long as the two names aren't similar. main and
> stable would be OK; with main and maint one is far too likely to do
> something to the wrong branch.
>
> Regards,
> John Ralls
>
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
