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