Well, the role has changed people over time. But no, the scripts are not in git. -d
On Mon, November 14, 2022 1:30 pm, john wrote: > Wow, I'm elevated to a whole department! ;-) I wish I had the clones to > make it true! > > If the scripts are in git on code then Geert or I can update them as > needed when we shift branches. > > Regards, > John Ralls > >> On Nov 14, 2022, at 8:26 AM, Derek Atkins <de...@ihtfp.com> wrote: >> >> I have no objection to changing branch names. >> >> Just keep in mind that several build scripts depend on the branch names, >> so if they change once, that's fine, but if they are constantly changing >> (e.g. 4.x, 5.x, 4.99, 6.x, etc) then we may need to rework the scripts >> so >> I don't have to coordinate with release-engineering when a new branch >> gets >> created. (This dev-docs, etc). >> >> -derek >> >> On Mon, November 14, 2022 11:17 am, Geert Janssens wrote: >>> This had been brewing in my mind as well, so thanks for bringing this >>> up. >>> >>> When I considered alternative branch names I initially thought of >>> "stable" >>> vs "development" >>> or "devel" with an optional "unstable" at times of pre-releases. >>> >>> However when thinking this through some more I started wondering >>> whether >>> we really >>> should limit ourselves to just two (or three) branch names. >>> >>> We could also name our branches "4.x", "5.x" and so on to indicate the >>> release series this >>> branch is for. At some point we just stop using the older branches. We >>> can >>> choose to drop >>> them or just leave them in the git history as it suits is best. >>> >>> Both naming schemes have advantages and drawbacks. I like the direct >>> relationship >>> between branch name and releases that will be on it for the latter >>> scheme. >>> Although I admit >>> this relationship doesn't hold for the pre-releases, unless we make >>> that a >>> separate branch for >>> those like eg "4.9xx". >>> >>> Regards, >>> >>> Geert >>> >>> Op zondag 13 november 2022 21:40:14 CET schreef 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 >>>> <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 >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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
