[sword-devel] CrossWire and git

Timmy tim.bze at gmail.com
Fri Mar 17 17:58:54 EDT 2023 

I apologize, I notice some of the file was cut. What I sent gives the idea.
If it's helpful for me to send everything then I will do that.



*--Timmy BraunCell: +501-615-4531*


On Fri, Mar 17, 2023 at 3:44 PM Timmy <tim.bze at gmail.com> wrote:

> Also, if there's code that should not be available to the public it would
> have to be put in a separate private repository with access granted just to
> the person(s) or team(s) that should have access.
>
>
>
> *--Timmy BraunCell: +501-615-4531*
>
>
> On Fri, Mar 17, 2023 at 3:42 PM Timmy <tim.bze at gmail.com> wrote:
>
>> From my research and some help from ChatGPT, I think the below text would
>> be the replacement for the access file (for GitHub CODEOWNERS).
>>
>> Note that I've simplified the Makefile.am, configure.ac, CMakeLists.txt
>> files to one line. This means all files with that name would be included
>> (saying in case that's not the intention).
>>
>> The "Teams" sword-prelim, sword-cmake, sword-release, sword-make would
>> have to be created in the GitHub organization.
>>
>> A branch protection rule would have to be setup in GitHub for the master
>> branch which would require at least "Require a pull request before merging"
>> and "Require review from Code Owners". Admins would always have access to
>> merge PRs unless also checking "Do not allow bypassing the above settings".
>> In such a case no one would be able to merge to master without PR.
>>
>> I don't claim to be "the expert" but take the info for what it's worth.
>>
>> # Specific access rules for refdoc
>> /trunk/man/ @refdoc
>> /trunk/src/modules/filters/ @refdoc
>> /trunk/include/teilatex.h @refdoc
>> /trunk/include/osislatex.h @refdoc
>> /trunk/include/gbflatex.h @refdoc
>> /trunk/include/thmllatex.h @refdoc
>> /trunk/src/mgr/markupfiltmgr.cpp @refdoc
>>
>> # Access rules for sword-prelim group
>> /trunk/locales.d/ @sword-prelim
>> /trunk/bindings/ @sword-prelim
>> /trunk/examples/ @sword-prelim
>> /trunk/utilities/ @sword-prelim
>> /trunk/tests/ @sword-prelim
>> /trunk/scripts/ @sword-prelim
>> /trunk/ChangeLog @sword-prelim
>> /trunk/lib/vcppmake/ @sword-prelim
>>
>> # Access rules for sword-cmake group
>> /trunk/cmake/ @sword-cmake
>>
>> # Access rules for sword-release group
>> /branches/ @sword-release
>> /tags/ @sword-release
>>
>> # Access rules for all files with the name Makefile.am
>> **/Makefile.am @sword-make
>>
>> # Access rules for all files with the name configure.ac
>> **/configure.ac @sword-make
>>
>> # Access rules for all files with the name CMakeLists.txt
>> **/CMakeLists.txt @sword-cmake
>>
>>
>>
>> *--Timmy BraunCell: +501-615-4531*
>>
>>
>> On Fri, Mar 17, 2023 at 2:40 PM Peter von Kaehne <refdoc at gmx.net> wrote:
>>
>>> Just one suggestion - a huge amount of our module work happens already
>>> on GitLab rather than GitHub. I think the reasons were to do with
>>> unfriendly policy changes of GitHub - but I am not entirely sure anymore.
>>>
>>> Cyrille, Dominique or David might know.
>>>
>>> We already run a GitLab instance on our CrossWire server, so we do know
>>> it in terms of admin etc.  I do not think GitHub is per se the more
>>> relevant place over GitLab in terms of exposure or ease of use.
>>>
>>> Might GitLab be the better choice to open up shop in?
>>>
>>> Peter
>>>
>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>
>>> On 17 Mar 2023, at 20:11, Greg Hellings <greg.hellings at gmail.com> wrote:
>>>
>>> 
>>> Current owners are myself, DM, Karl, and Doug Campos. I sent Troy an
>>> invite to it.
>>>
>>> --Greg
>>>
>>> On Fri, Mar 17, 2023 at 3:09 PM Peter von Kaehne <refdoc at gmx.net> wrote:
>>>
>>>> I think I own the CrossWire organization though not sure anymore. I
>>>> will look into it this weekend and approve you to the highest level if I
>>>> can do so
>>>>
>>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>>
>>>> On 17 Mar 2023, at 19:28, Greg Hellings <greg.hellings at gmail.com>
>>>> wrote:
>>>>
>>>> 
>>>> Troy,
>>>>
>>>> I know we've discussed the merge issue in the past. In order to help
>>>> point in the right direction, a couple of questions:
>>>>
>>>> Do you still envision self hosting the repository as you have SVN and
>>>> using GitHub to mirror, or do you anticipate self hosting a repository that
>>>> is just an insurance policy against GitHub becoming unfriendly in the
>>>> future? Most popular self hosting Git supports both push and pull to GitHub
>>>> repositories, but the one you anticipate being the source will determine
>>>> the recommendations and conversion path.
>>>>
>>>> In the Git world, the feature you're looking at seems to be known as
>>>> Code Owners. It's a relatively newer feature. Here is GitHub documentation
>>>> about their implementation.
>>>> Https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
>>>>
>>>> If you anticipate doing most of the work on a self hosted solution and
>>>> pushing GitHub as the mirror, I can look for their technique.
>>>>
>>>> I'll look into the Crosswire organization on GitHub to see if I have
>>>> admin rights there to address #1.
>>>>
>>>> --Greg
>>>>
>>>> On Fri, Mar 17, 2023, 14:09 Troy A. Griffitts <scribe at crosswire.org>
>>>> wrote:
>>>>
>>>>> I don't want this to turn into a debate.
>>>>>
>>>>> I agree, we need to move source control to git.
>>>>>
>>>>> I even mostly agree we should do most of our dev work on github for
>>>>> the visibility to draw other developers.
>>>>>
>>>>> To move forward with this:
>>>>>
>>>>> 1) I would actually need access to the github 'crosswire'
>>>>> organization, which I currently don't have.
>>>>>
>>>>> 2) I am happy to migrate our 27 repos there (yes, I was also surprised
>>>>> we have 27, but even these old ones would be nice to have on github for
>>>>> posterity).
>>>>> 3) After #2, I would love for Github experts to help me find a
>>>>> solution that effectively grant elevated access to individuals for merging
>>>>> PRs into our master repository without my approval FOR CERTAIN PARTS OF THE
>>>>> REPO they own or are trusted to approve.
>>>>>
>>>>> This #3 item had been the primary element holding us back from moving
>>>>> from SVN to git.  If you are unaware, SVN has a very easy way to elevate
>>>>> permissions for accounts for parts of the repository.  I don't want to have
>>>>> to approve all changes!  I trust our pumpkin holders to care for their
>>>>> parts of the repository.
>>>>>
>>>>> We've discussed, in the past, submodules for handle this, but they do
>>>>> not handle this well.  e.g., I want to grant Greg Hellings full write
>>>>> access to merge any PR which updates any of our cmake scripts in all
>>>>> folders everywhere.  I don't know anything about cmake and Greg is an
>>>>> expert.  I want him to be able to manage that build system without my
>>>>> oversight.  I trust him.  I do not want to grant Greg merge access for code
>>>>> that has anything to do with our C++ engine.  He might be a great C++
>>>>> programmer, but he hasn't expressed he wants that access or ever submitted
>>>>> C++ code for me to review and merge myself, so I want to protect Greg from
>>>>> accidentally merging in someone's PR which includes C++ engine code.
>>>>>
>>>>> In SVN this is easy.  Attached is our SVN access file.  Help me
>>>>> translate this workflow to Github.  There must be some way to restrict
>>>>> merges based on the merging user and files modified in the PR.  Or at least
>>>>> require a review by certain users bases on the files modified in the PR.
>>>>>
>>>>> Help me :)
>>>>>
>>>>> Troy
>>>>>
>>>>>
>>>>> On 3/17/23 11:24, Greg Hellings wrote:
>>>>>
>>>>> Indeed. It's not a principled stand that I'm refusing to get
>>>>> Subversion going. It's simply that it's too much work that I haven't
>>>>> bothered and don't foresee doing so anytime soon.
>>>>>
>>>>> And, with no setup to automatically test the scripts in all the
>>>>> environments they must support, it's not likely others are willing to
>>>>> commit this on my behalf.
>>>>>
>>>>> --Greg
>>>>>
>>>>> On Sun, Mar 12, 2023, 09:42 Peter von Kaehne <refdoc at gmx.net> wrote:
>>>>>
>>>>>> I think you misunderstood Greg.
>>>>>>
>>>>>> There is a long campaign and strong feeling to have the project on
>>>>>> Git but there is no agreement or movement to that. And it seems Greg is
>>>>>> pausing his contributions until that matter is resolved.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> Sent from my phone. Please forgive misspellings and weird
>>>>>> “corrections”
>>>>>>
>>>>>> On 12 Mar 2023, at 15:51, ZdPo Ster <zdposter at gmail.com> wrote:
>>>>>>
>>>>>> 
>>>>>> I am sorry, but I did not get the point of your reply.
>>>>>> I do not use subversion - I use git-svn as proposed several months
>>>>>> ago on this forum. But current cmake configuration expects everybody to use
>>>>>> subversion, which is wrong.
>>>>>> These patches improve cmake build:
>>>>>>
>>>>>>    -  that will work also with git-svn
>>>>>>    - MSVC build
>>>>>>    - fix depreciated
>>>>>>
>>>>>> AFAIK it should cause no harm for other combinations, just improve
>>>>>> current state.
>>>>>>
>>>>>> Zdenko
>>>>>>
>>>>>> On Thu, 9 Mar 2023 at 23:18, Greg Hellings <greg.hellings at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I've never bothered to get Subversion setup on my local machine.
>>>>>>> Remembering the setup, plus my credentials, and how to use it is more labor
>>>>>>> than I've been willing to spend on this effort. If, in the future, I
>>>>>>> overcome that inertia then I'll happily test and apply this patch.
>>>>>>>
>>>>>>> --Greg
>>>>>>>
>>>>>>> On Sat, Feb 25, 2023 at 5:34 AM ZdPo Ster <zdposter at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Any update on this (after 3.5 months)?
>>>>>>>>
>>>>>>>> Zdenko
>>>>>>>>
>>>>>>>> On Sat, 26 Nov 2022 at 21:53, Greg Hellings <
>>>>>>>> greg.hellings at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks. I am not privy to the patches email inbox, so this mailing
>>>>>>>>> list is the way to reach me for CMake things. I'll review these when I have
>>>>>>>>> the opportunity.
>>>>>>>>>
>>>>>>>>> --Greg
>>>>>>>>>
>>>>>>>>> On Sat, Nov 26, 2022, 13:46 Peter von Kaehne <refdoc at gmx.net>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> How to suggest improvements to the sword project?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> You did it the right way. It just is a bit on/off as a project.
>>>>>>>>>> GHellings is the cmake pumpkin holder as far as I know. I bcc him on a
>>>>>>>>>> different email address.
>>>>>>>>>>
>>>>>>>>>> Peter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> BR,
>>>>>>>>>>
>>>>>>>>>> Zdenko
>>>>>>>>>>
>>>>>>>>>> ---------- Forwarded message ---------
>>>>>>>>>> From: ZdPo Ster <zdposter at gmail.com>
>>>>>>>>>> Date: Sun, 6 Nov 2022 at 22:22
>>>>>>>>>> Subject: cmake patches
>>>>>>>>>> To: <patches at crosswire.org>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> please find 3 few patches related to cmake build (tested
>>>>>>>>>> on windows with MSVC 2019):
>>>>>>>>>>
>>>>>>>>>>    1. cmake_fix_deprecation.patch - cmake version 3.23.2 produce
>>>>>>>>>>    depreciation warning for old minimum version, co IMO it is time to increase
>>>>>>>>>>    expected cmake version
>>>>>>>>>>    2. cmake_fix_msvc.patch - there is no "/O3" options in
>>>>>>>>>>    current MSVC[1]
>>>>>>>>>>    3. cmake_git_svn.patch - I use git svn for accessing code,
>>>>>>>>>>    but cmake produce error because of missing svn executable. He is patch that
>>>>>>>>>>    fixed it + code for detecting svn revision (MYSVN_WC_REVISION) from git
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> https://learn.microsoft.com/en-us/cpp/build/reference/o-options-optimize-code?view=msvc-160
>>>>>>>>>>
>>>>>>>>>> Zdenko
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>>>
>>>>>> _______________________________________________
>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>>
>>>>>> _______________________________________________
>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel at crosswire.orghttp://crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
>>>>>
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://crosswire.org/pipermail/sword-devel/attachments/20230317/e99aab77/attachment-0001.htm>

More information about the sword-devel mailing list