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....@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....@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 <ref...@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.helli...@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 <ref...@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.helli...@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 <scr...@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 <ref...@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 <zdpos...@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.helli...@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 <zdpos...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Any update on this (after 3.5 months)? >>>>>>>> >>>>>>>> Zdenko >>>>>>>> >>>>>>>> On Sat, 26 Nov 2022 at 21:53, Greg Hellings < >>>>>>>> greg.helli...@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 <ref...@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 <zdpos...@gmail.com> >>>>>>>>>> Date: Sun, 6 Nov 2022 at 22:22 >>>>>>>>>> Subject: cmake patches >>>>>>>>>> To: <patc...@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@crosswire.org >>>>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>>>>>>> Instructions to unsubscribe/change your settings at above page >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>>>>>> Instructions to unsubscribe/change your settings at above page >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>>>>> Instructions to unsubscribe/change your settings at above page >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>>>> Instructions to unsubscribe/change your settings at above page >>>>>>> >>>>>> _______________________________________________ >>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>>> Instructions to unsubscribe/change your settings at above page >>>>>> >>>>>> _______________________________________________ >>>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>>> Instructions to unsubscribe/change your settings at above page >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sword-devel mailing list: >>>>> sword-devel@crosswire.orghttp://crosswire.org/mailman/listinfo/sword-devel >>>>> Instructions to unsubscribe/change your settings at above page >>>>> >>>>> _______________________________________________ >>>>> sword-devel mailing list: sword-devel@crosswire.org >>>>> http://crosswire.org/mailman/listinfo/sword-devel >>>>> Instructions to unsubscribe/change your settings at above page >>>>> >>>> _______________________________________________ >>>> sword-devel mailing list: sword-devel@crosswire.org >>>> http://crosswire.org/mailman/listinfo/sword-devel >>>> Instructions to unsubscribe/change your settings at above page >>>> >>>> _______________________________________________ >>>> sword-devel mailing list: sword-devel@crosswire.org >>>> http://crosswire.org/mailman/listinfo/sword-devel >>>> Instructions to unsubscribe/change your settings at above page >>>> >>> _______________________________________________ >>> sword-devel mailing list: sword-devel@crosswire.org >>> http://crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >>> >>> _______________________________________________ >>> sword-devel mailing list: sword-devel@crosswire.org >>> http://crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >>> >>
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
