Re: [GNC-dev] Git branches

[list+gnucash]

On 2022-11-13 12:40, john wrote:


...I thought it timely to start a discussion about a related trend: The name of 
the git repository's primary branches

I don't think 'main' is the right name for gnucash or gnucash-docs because it 
does nothing about the confusion factor. Note that the default branch on those 
two is maint but we still use master for the next major release's branch. The 
most expressive titles would be current-major-release and next-major-release 
but they're a bit wordy; OTOH just current (or curr) and next leave a new 
contributor to ask current and next what? maint is concise and not terrible for 
a branch that gets only bug fixes and small features. Lots of generic names for 
the next-major-release branch (future, devel or development, major-change) come 
to mind but I'm not sure that any of them clearly express the intent of the 
branch.

Comments?


How about "next" and "maint", for "next-major-release" and 
"current-major-release"?


Or maybe "current-maint" instead of "maint".

And by the way, I love how you worded this bit:


...the cultural sensitivity issues (primarily in the United States because of 
our unfortunate history with forced importation and enslavement of Africans)...
I think the forthright words "forced importation and enslavement" are a 
good preemptive rebuttal to the objection that branch naming is just a 
matter of posturing and virtue signalling. There is a real horror that 
it is good to take seriously. Thank you.


Best regards,
 —Jim DeLaHunt

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Git branches

[john]

Since Geert brought up our relationship with Github I thought it timely to 
start a discussion about a related trend: The name of the git repository's 
primary branches. There's an ongoing effort in the software development 
community for the last 25-30 years or so to remove the terms master and slave; 
originally when used together (as in processes) but more recently when used 
alone. This recently includes the name of the primary branch in a git 
repository. The Gitlab folks have a nice summary at 
https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/.

'Master' was the standard when we started using git 10 years ago and so we 
adopted it and still use it. Aside from the cultural sensitivity issues 
(primarily in the United States because of our unfortunate history with forced 
importation and enslavement of Africans) it has proved to be a bit confusing to 
new contributors.

The new standard default is 'main'. I think that would be fine for htdocs where 
we have master and beta: Main would better express that that's the branch that 
you see when you visit https://www.gnucash.org . The 
gnucash-on-foo repositories for the build processes have only master branches 
so it doesn't really matter what the branch is called.

I don't think 'main' is the right name for gnucash or gnucash-docs because it 
does nothing about the confusion factor. Note that the default branch on those 
two is maint but we still use master for the next major release's branch. The 
most expressive titles would be current-major-release and next-major-release 
but they're a bit wordy; OTOH just current (or curr) and next leave a new 
contributor to ask current and next what? maint is concise and not terrible for 
a branch that gets only bug fixes and small features. Lots of generic names for 
the next-major-release branch (future, devel or development, major-change) come 
to mind but I'm not sure that any of them clearly express the intent of the 
branch.

Comments?

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash and Github

[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 statements 
are preserved and Copilots failure to do so is the real problem.  That's a 
matter for the courts; in order to get the matter before the courts somebody 
has to sue Github. Filing those suits on behalf of their client projects is the 
Software Freedom Conservancy's job, see 
https://sfconservancy.org/copyleft-compliance/. Since they have a history of 
suing over GPL compliance the boycott call suggests to me that they think 
they'd lose, either on merit or just because Microsoft has a bigger badder 
legal team. It's interesting that the FSF has nothing to say on their own, just 
a few links to articles: https://www.fsf.org/licensi
 ng/copilot.

Regards,
John Ralls



> On Nov 13, 2022, at 6:59 AM, Derek Atkins  wrote:
> 
> Hi,
> 
> What are the features of github that we use/depend on?
> 
> - We don't use github's git repo except as a read-only version -- we COULD
> open up code for RO access.
> 
> - We don't use github issues; we have our own bugzilla.
> 
> - We DO use github pull requests; we could theoretically migrate to gerrit
> for review/management.
> 
> - We DO use github actions; we could theoretically migrate to Jenkins
> (with gerrit) for build/test/CI work.
> 
> Am I missing anything?
> 
> Having said that, and admitting I did not follow the link and read the
> complaints, what is the fear with their "use" of GnuCash?
> 
> -derek
> 
> On Sun, November 13, 2022 9:48 am, Geert Janssens wrote:
>> Some may have heard the rumblings around github semi-recently. The
>> software
>> conservancy is calling free software projects to seek alternatives. They
>> motivate this in much
>> more detail over here:
>> https://sfconservancy.org/GiveUpGitHub/[1]
>> 
>> In short, they claim github is a proprietary tool that's leveraging the
>> hosted free software for
>> their commercial purposes. In itself that would be acceptable as long as
>> it's done according
>> to the licenses of these free software projects. There have been several
>> situations where
>> that's not the case, "copilot" being the latest and most worry-some.
>> 
>> Is this something we as a free software project should think about and
>> possibly act on ?
>> 
>> Personally I don't like it at all that I chose to write code under a free
>> software license to
>> ensure my effort helps and benefits the free software ecosystem. Yet that
>> a commercial
>> company then decides to use my code to train an AI that's meant to help
>> build proprietary
>> software. The legal status of that is still very unclear and certainly not
>> what I intended my
>> code to be used for.
>> 
>> That is obviously only my personal opinion, but I wanted to express it as
>> starting point for a
>> wider discussion on this topic.
>> 
>> Is the golden cage that is github to developers really becoming
>> detrimental to real free
>> software principles ?
>> 
>> Should we do something about this ? Once hooked into the github ecosystem
>> it's pretty hard
>> to leave, as the sfc also acknowledges. They do offer initial suggestions
>> for alternatives, but
>> they are not at the same level as github currently.
>> 
>> Please share your views on this topic as well.
>> 
>> Regards,
>> 
>> Geert
>> 
>> 
>> [1] https://sfconservancy.org/GiveUpGitHub/
>> 

Re: [GNC-dev] Dependencies policy for major releases

[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.

> 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. 

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?

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] GnuCash and Github

[Derek Atkins]

Hi,

What are the features of github that we use/depend on?

- We don't use github's git repo except as a read-only version -- we COULD
open up code for RO access.

- We don't use github issues; we have our own bugzilla.

- We DO use github pull requests; we could theoretically migrate to gerrit
for review/management.

- We DO use github actions; we could theoretically migrate to Jenkins
(with gerrit) for build/test/CI work.

Am I missing anything?

Having said that, and admitting I did not follow the link and read the
complaints, what is the fear with their "use" of GnuCash?

-derek

On Sun, November 13, 2022 9:48 am, Geert Janssens wrote:
> Some may have heard the rumblings around github semi-recently. The
> software
> conservancy is calling free software projects to seek alternatives. They
> motivate this in much
> more detail over here:
> https://sfconservancy.org/GiveUpGitHub/[1]
>
> In short, they claim github is a proprietary tool that's leveraging the
> hosted free software for
> their commercial purposes. In itself that would be acceptable as long as
> it's done according
> to the licenses of these free software projects. There have been several
> situations where
> that's not the case, "copilot" being the latest and most worry-some.
>
> Is this something we as a free software project should think about and
> possibly act on ?
>
> Personally I don't like it at all that I chose to write code under a free
> software license to
> ensure my effort helps and benefits the free software ecosystem. Yet that
> a commercial
> company then decides to use my code to train an AI that's meant to help
> build proprietary
> software. The legal status of that is still very unclear and certainly not
> what I intended my
> code to be used for.
>
> That is obviously only my personal opinion, but I wanted to express it as
> starting point for a
> wider discussion on this topic.
>
> Is the golden cage that is github to developers really becoming
> detrimental to real free
> software principles ?
>
> Should we do something about this ? Once hooked into the github ecosystem
> it's pretty hard
> to leave, as the sfc also acknowledges. They do offer initial suggestions
> for alternatives, but
> they are not at the same level as github currently.
>
> Please share your views on this topic as well.
>
> Regards,
>
> Geert
>
> 
> [1] https://sfconservancy.org/GiveUpGitHub/
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] GnuCash and Github

[Geert Janssens]

Some may have heard the rumblings around github semi-recently. The software 
conservancy is calling free software projects to seek alternatives. They 
motivate this in much 
more detail over here:
https://sfconservancy.org/GiveUpGitHub/[1]

In short, they claim github is a proprietary tool that's leveraging the hosted 
free software for 
their commercial purposes. In itself that would be acceptable as long as it's 
done according 
to the licenses of these free software projects. There have been several 
situations where 
that's not the case, "copilot" being the latest and most worry-some.

Is this something we as a free software project should think about and possibly 
act on ?

Personally I don't like it at all that I chose to write code under a free 
software license to 
ensure my effort helps and benefits the free software ecosystem. Yet that a 
commercial 
company then decides to use my code to train an AI that's meant to help build 
proprietary 
software. The legal status of that is still very unclear and certainly not what 
I intended my 
code to be used for.

That is obviously only my personal opinion, but I wanted to express it as 
starting point for a 
wider discussion on this topic.

Is the golden cage that is github to developers really becoming detrimental to 
real free 
software principles ?

Should we do something about this ? Once hooked into the github ecosystem it's 
pretty hard 
to leave, as the sfc also acknowledges. They do offer initial suggestions for 
alternatives, but 
they are not at the same level as github currently.

Please share your views on this topic as well.

Regards,

Geert


[1] https://sfconservancy.org/GiveUpGitHub/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Dependencies policy for major releases

[Geert Janssens]

Op zaterdag 29 oktober 2022 18:53:57 CET schreef john:
> What really makes sense? How many users are building for themselves and on
> what?

Here are a few of my thoughts on this topic (I threw away several earlier 
attempts because 
they became way too long...)

With my developer hat on I prefer to have as little conditional code as 
possible in the sources 
as this complicates reasoning about the code and makes it harder to test. So 
ideally no parts 
of the code that require certain versions of a dependency and other parts of 
the code for 
other versions of that same dependency. So that's the "most extreme" policy in 
John's 
writing. I am aware this is not always possible, especially as we offer gnucash 
on multiple 
platforms.

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.

>From the perspective of an end user (on linux), the group affected the most 
>are self-builders. 
A few have spoken up, but I have no idea of the size of this group in the wider 
community 
and whether or not they tend to run up-to-date distros.

The feedback we have received so far expresses a prudent willingness to 
self-build 
dependencies if needed.

On the whole my opinion is we can aim for more recent dependencies when it's 
useful, 
needed or desired.

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.

Regards,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel