Re: [sword-devel] CrossWire and git

[Tobias Klein]

Hi Troy, Greg!

Any progress on this initiative? :)

Best regards,
Tobias

On 3/17/23 8:09 PM, Troy A. Griffitts 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  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  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
 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
 wrote:

Any update on this (after 3.5 months)?

Zdenko

On Sat, 26 Nov 2022 at 21:53, Greg Hellings
 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
 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* 
   

Re: [sword-devel] CrossWire and git

[Peter Von Kaehne]

There was a period shortly after GiHub became MS that private repos were abolished - that in turn made us among other things as a module team move to GitLab. I am glad to hear they got reintroduced. 

 

Peter

 
 

Gesendet: Samstag, 18. März 2023 um 21:31 Uhr
Von: "Timmy" 
An: "SWORD Developers' Collaboration Forum" 
Betreff: Re: [sword-devel] CrossWire and git


Private repos on GitHub free have very limited access controls (I don't know about Gitlab).
 

I have no objection to using GitHub. 

 


On Sat, Mar 18, 2023, 15:25 Karl Kleinpaste <k...@kleinpaste.org> wrote:



On 3/18/23 07:40, Peter von Kaehne wrote:

GitLab allows private repos

I don't know where the idea comes from, that GitHub doesn't have private repos. It certainly does, as I use one, for a network project/toy most of you have never heard of (and probably never will).
___
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

Re: [sword-devel] CrossWire and git

[Timmy]

Private repos on GitHub free have very limited access controls (I don't
know about Gitlab).

I have no objection to using GitHub.

On Sat, Mar 18, 2023, 15:25 Karl Kleinpaste  wrote:

> On 3/18/23 07:40, Peter von Kaehne wrote:
>
> GitLab allows private repos
>
>
> I don't know where the idea comes from, that GitHub doesn't have private
> repos. It certainly does, as I use one, for a network project/toy most of
> you have never heard of (and probably never will).
> ___
> 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

Re: [sword-devel] CrossWire and git

[Karl Kleinpaste]

On 3/18/23 07:40, Peter von Kaehne wrote:

GitLab allows private repos


I don't know where the idea comes from, that GitHub doesn't have private 
repos. It certainly does, as I use one, for a network project/toy most 
of you have never heard of (and probably never will).___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Matěj Cepl]

On 2023-03-18, 14:57 GMT, Troy A. Griffitts wrote:
> Guys who prefer GitLab, I am sorry. No university research
> project, no commercial job has ever asked me to use GitLab. They
> have all asked me use GitHub. From a purely popular choice and
> to prevent all of us from having to create yet another account
> (I am sure most everyone already has a GitHub account) and learn
> yet another tool, can't we just settle on GitHub. Would it make
> anyone extremely unhappy? GitLab is not my preferred choice.

I really don't care that much, git is a DISTRIBUTED versioning
control system, so we shouldn't be bound to one server anyway,
it is not healthy (especially when that one server is owned by
Microsoft). It will be a bit strange that the Crosswire
repositories will be spread over at least three servers (GitHub,
GitLab, git.crosswire.org, and if GitLab is not the official
Crosswire place, I may move Czech Bibles to sr.ht), but it is
possible.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
“Push to test.” (click) “Release to detonate…”
 -- from a bugzilla quip list


___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Tobias Klein]

I'm familiar with both. GitLab at work (privately hosted) and GitHub for my 
open source work.


I like GitLab. However, I think the GitHub CI infrastructure is more powerful.

Furthermore, pretty much all SWORD frontends are already on GitHub (except 
Bishop).


Best regards,
Tobias

Am 18. März 2023 18:00:06 schrieb Greg Hellings :
From an administration and uptime point of view, I'm in support of GitHub. 
The only place I've used Gitlab is at Red Hat and only for internal 
projects there. From a pragmatic standing I'm in full support of GitHub, 
and with an existing Gitlab instance, we're already set if something comes 
up in the future that forces us to reconsider.


--Greg

On Sat, Mar 18, 2023, 09:57 Troy A. Griffitts  wrote:
Guys who prefer GitLab, I am sorry. No university research project, no 
commercial job has ever asked me to use GitLab. They have all asked me use 
GitHub. From a purely popular choice and to prevent all of us from having 
to create yet another account (I am sure most everyone already has a GitHub 
account) and learn yet another tool, can't we just settle on GitHub. Would 
it make anyone extremely unhappy? GitLab is not my preferred choice.



On March 18, 2023 6:40:57 AM MST, Greg Hellings  
wrote:



On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:
GitLab vs GitLab


GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
intellipaat.com






There is plenty more but this gives a decent summary. GitLab allows private 
repos which I think are a really useful thing. I think it should also be 
easier to integrate our own GitLab stuff or move it if we want to
This comparison is quite dated (for instance, GitHub definitely has CI/CD 
integrated nowadays, and GitLab is by no means buggy and slow), but I also 
would support GitLab over GitHub as our definitive location simply on the 
principle of it being FOSS instead of closed source hosting.


It does have an identical Code owners feature to GitHub with the same 
syntax and location. I'm not sure if it's available in the self hosted/free 
versions or if it is one of their premium features. I'm getting conflicting 
information on that.


It does support automatic mirroring, so it would be easy for us to self 
host the official repository but still allow automated mirrors on GitHub 
and the public GitLab for ease of contribution by others.


--Greg


We aren’t a democracy but as far as it goes - I welcome the move to Git so, 
so gladly and I vote for moving towards GitLab as there is more active 
development of us already


Peter

Sent from my phone. Please forgive misspellings and weird “corrections”


On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:

I am very happy with this progress in your thinking about git. I just
reiterate my preference for gitlab, where as Peter has already pointed
out we now have all our modules. It would be consistent to add the sword
sources there as well.
@David I don't particularly use github for my personal projects which
are all under gitlab.


+1

Matěj
--
https://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
   -- Tim Hansel


___
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
--
Sent from my Android device with K-9 Mail. Please excuse my 
brevity.___

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

Re: [sword-devel] CrossWire and git

[Greg Hellings]

On Sat, Mar 18, 2023, 13:30 Fr Cyrille  wrote:

>
>
> Le 18/03/2023 à 15:57, Troy A. Griffitts a écrit :
>
> Guys who prefer GitLab, I am sorry. No university research project, no
> commercial job has ever asked me to use GitLab.
>
> The french wikipedia says about : The software is used by several large IT
> companies, including IBM, Sony, the Jülich Research Centre, NASA, Alibaba,
> Oracle, Invincea, O'Reilly Media, Leibniz Rechenzentrum, CERN4,5,6,
> European XFEL, the GNOME Foundation, Boeing, Autodata, SpaceX7 , Symbio and
> Altares...
>
> They have all asked me use GitHub. From a purely popular choice and to
> prevent all of us from having to create yet another account (I am sure most
> everyone already has a GitHub account) and learn yet another tool, can't we
> just settle on GitHub. Would it make anyone extremely unhappy? GitLab is
> not my preferred choice.
>
>
> I wouldn't be unhappy, but when I have a choice between open or
> proprietary software I always ask myself if the small inconvenience I would
> have to use open is worth it or not, if I have a surmountable inconvenience
> I favour the inconvenience. I don't know in our case, because I don't have
> the skills, and I trust you. However I wonder if for what we write as
> source code gitlab is not just enough?
> For the creation of an account, I think most of us already have an
> account, no?
>

Unfortunately, for Gitlab, the code owners feature is behind a paid
subscription. In that very important way it does not (freely) provide what
Troy needs to administrate the engine development. It works great for
modules because they are owned by a person and each in separate
repositories. This, Gitlab does not provide the features needed unless Troy
is willing to pay.

Another feature that Gitlab hides behind payment is multiple reviewers per
PR. I don't know if that's a hard requirement at this time, but it could be
if a proposed change touched multiple areas of the engine code.

Although I prefer to leverage the FOSS option where available, in this case
it comes down to Troy deciding whether it's worth the financial cost for
those features on Gitlab or working in GitHub where those are gratis. That
cost would come to $29 per user, per month. And then we lose the network
effect of allowing people to easily fork the repository and send a PR
unless he's paying for the SaaS version. There is a model for FOSS projects
to gain access to the premium features we need, if you apply and are
accepted. https://about.gitlab.com/solutions/open-source/projects/

--Greg

>
>
>
> On March 18, 2023 6:40:57 AM MST, Greg Hellings 
>  wrote:
>>
>>
>>
>> On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:
>>
>>> GitLab vs GitLab
>>>
>>> [image: image3-1.png]
>>>
>>> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
>>> 
>>> intellipaat.com
>>> 
>>> 
>>>
>>> There is plenty more but this gives a decent summary. GitLab allows
>>> private repos which I think are a really useful thing. I think it should
>>> also be easier to integrate our own GitLab stuff or move it if we want to
>>>
>>
>> This comparison is quite dated (for instance, GitHub definitely has CI/CD
>> integrated nowadays, and GitLab is by no means buggy and slow), but I also
>> would support GitLab over GitHub as our definitive location simply on the
>> principle of it being FOSS instead of closed source hosting.
>>
>> It does have an identical Code owners feature to GitHub with the same
>> syntax and location. I'm not sure if it's available in the self hosted/free
>> versions or if it is one of their premium features. I'm getting conflicting
>> information on that.
>>
>> It does support automatic mirroring, so it would be easy for us to self
>> host the official repository but still allow automated mirrors on GitHub
>> and the public GitLab for ease of contribution by others.
>>
>> --Greg
>>
>>
>>> We aren’t a democracy but as far as it goes - I welcome the move to Git
>>> so, so gladly and I vote for moving towards GitLab as there is more active
>>> development of us already
>>>
>>> Peter
>>>
>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>
>>> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>>>
>>> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>>>
>>> I am very happy with this progress in your thinking about git. I just
>>>
>>> reiterate my preference for gitlab, where as Peter has already pointed
>>>
>>> out we now have all our modules. It would be consistent to add the sword
>>>
>>> sources there as well.
>>>
>>> @David I don't particularly use github for my personal projects which
>>>
>>> are all under gitlab.
>>>
>>>
>>> +1
>>>
>>> Matěj
>>> --
>>> https://matej.ceplovi.cz/blog/, @mcepl@floss.social
>>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>>
>>> Pain is 

Re: [sword-devel] CrossWire and git

[Fr Cyrille]

Le 18/03/2023 à 15:57, Troy A. Griffitts a écrit :
Guys who prefer GitLab, I am sorry. No university research project, no 
commercial job has ever asked me to use GitLab. 
The french wikipedia says about : The software is used by several large 
IT companies, including IBM, Sony, the Jülich Research Centre, NASA, 
Alibaba, Oracle, Invincea, O'Reilly Media, Leibniz Rechenzentrum, 
CERN4,5,6, European XFEL, the GNOME Foundation, Boeing, Autodata, 
SpaceX7 , Symbio and Altares...


They have all asked me use GitHub. From a purely popular choice and to 
prevent all of us from having to create yet another account (I am sure 
most everyone already has a GitHub account) and learn yet another 
tool, can't we just settle on GitHub. Would it make anyone extremely 
unhappy? GitLab is not my preferred choice.


I wouldn't be unhappy, but when I have a choice between open or 
proprietary software I always ask myself if the small inconvenience I 
would have to use open is worth it or not, if I have a surmountable 
inconvenience I favour the inconvenience. I don't know in our case, 
because I don't have the skills, and I trust you. However I wonder if 
for what we write as source code gitlab is not just enough?
For the creation of an account, I think most of us already have an 
account, no?





On March 18, 2023 6:40:57 AM MST, Greg Hellings 
 wrote:




On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:

GitLab vs GitLab

image3-1.png
GitLab vs GitHub: Top 10 Differences between GitHub and GitLab

intellipaat.com




There is plenty more but this gives a decent summary. GitLab
allows private repos which I think are a really useful thing.
I think it should also be easier to integrate our own GitLab
stuff or move it if we want to


This comparison is quite dated (for instance, GitHub definitely
has CI/CD integrated nowadays, and GitLab is by no means buggy and
slow), but I also would support GitLab over GitHub as our
definitive location simply on the principle of it being FOSS
instead of closed source hosting.

It does have an identical Code owners feature to GitHub with the
same syntax and location. I'm not sure if it's available in the
self hosted/free versions or if it is one of their premium
features. I'm getting conflicting information on that.

It does support automatic mirroring, so it would be easy for us to
self host the official repository but still allow automated
mirrors on GitHub and the public GitLab for ease of contribution
by others.

--Greg


We aren’t a democracy but as far as it goes - I welcome the
move to Git so, so gladly and I vote for moving towards GitLab
as there is more active development of us already

Peter

Sent from my phone. Please forgive misspellings and weird
“corrections”


On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:

On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:

I am very happy with this progress in your thinking about
git. I just
reiterate my preference for gitlab, where as Peter has
already pointed
out we now have all our modules. It would be consistent to
add the sword
sources there as well.
@David I don't particularly use github for my personal
projects which
are all under gitlab.


+1

Matěj
-- 
https://matej.ceplovi.cz/blog/, @mcepl@floss.social

GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
   -- Tim Hansel


___
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

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

___
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

Re: [sword-devel] CrossWire and git

[Greg Hellings]

>From an administration and uptime point of view, I'm in support of GitHub.
The only place I've used Gitlab is at Red Hat and only for internal
projects there. From a pragmatic standing I'm in full support of GitHub,
and with an existing Gitlab instance, we're already set if something comes
up in the future that forces us to reconsider.

--Greg

On Sat, Mar 18, 2023, 09:57 Troy A. Griffitts  wrote:

> Guys who prefer GitLab, I am sorry. No university research project, no
> commercial job has ever asked me to use GitLab. They have all asked me use
> GitHub. From a purely popular choice and to prevent all of us from having
> to create yet another account (I am sure most everyone already has a GitHub
> account) and learn yet another tool, can't we just settle on GitHub. Would
> it make anyone extremely unhappy? GitLab is not my preferred choice.
>
> On March 18, 2023 6:40:57 AM MST, Greg Hellings 
> wrote:
>>
>>
>>
>> On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:
>>
>>> GitLab vs GitLab
>>>
>>> [image: image3-1.png]
>>>
>>> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
>>> 
>>> intellipaat.com
>>> 
>>> 
>>>
>>> There is plenty more but this gives a decent summary. GitLab allows
>>> private repos which I think are a really useful thing. I think it should
>>> also be easier to integrate our own GitLab stuff or move it if we want to
>>>
>>
>> This comparison is quite dated (for instance, GitHub definitely has CI/CD
>> integrated nowadays, and GitLab is by no means buggy and slow), but I also
>> would support GitLab over GitHub as our definitive location simply on the
>> principle of it being FOSS instead of closed source hosting.
>>
>> It does have an identical Code owners feature to GitHub with the same
>> syntax and location. I'm not sure if it's available in the self hosted/free
>> versions or if it is one of their premium features. I'm getting conflicting
>> information on that.
>>
>> It does support automatic mirroring, so it would be easy for us to self
>> host the official repository but still allow automated mirrors on GitHub
>> and the public GitLab for ease of contribution by others.
>>
>> --Greg
>>
>>
>>> We aren’t a democracy but as far as it goes - I welcome the move to Git
>>> so, so gladly and I vote for moving towards GitLab as there is more active
>>> development of us already
>>>
>>> Peter
>>>
>>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>>
>>> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>>>
>>> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>>>
>>> I am very happy with this progress in your thinking about git. I just
>>>
>>> reiterate my preference for gitlab, where as Peter has already pointed
>>>
>>> out we now have all our modules. It would be consistent to add the sword
>>>
>>> sources there as well.
>>>
>>> @David I don't particularly use github for my personal projects which
>>>
>>> are all under gitlab.
>>>
>>>
>>> +1
>>>
>>> Matěj
>>> --
>>> https://matej.ceplovi.cz/blog/, @mcepl@floss.social
>>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>>
>>> Pain is inevitable, but misery is optional. We cannot avoid pain,
>>> but we can avoid joy.
>>>-- Tim Hansel
>>>
>>>
>>> ___
>>> 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
>>>
>> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Peter Von Kaehne]

No objection - as long as it is accepted that the modules stay in GitLab. 

 
 

Gesendet: Samstag, 18. März 2023 um 14:57 Uhr
Von: "Troy A. Griffitts" 
An: "SWORD Developers' Collaboration Forum" , "Greg Hellings" 
Betreff: Re: [sword-devel] CrossWire and git

Guys who prefer GitLab, I am sorry. No university research project, no commercial job has ever asked me to use GitLab. They have all asked me use GitHub. From a purely popular choice and to prevent all of us from having to create yet another account (I am sure most everyone already has a GitHub account) and learn yet another tool, can't we just settle on GitHub. Would it make anyone extremely unhappy? GitLab is not my preferred choice.
 
On March 18, 2023 6:40:57 AM MST, Greg Hellings  wrote:


 

On Sat, Mar 18, 2023, 06:41 Peter von Kaehne <ref...@gmx.net> wrote:


GitLab vs GitLab
 





	
		
			
		
		
			
			

	
		
		
		GitLab vs GitHub: Top 10 Differences between GitHub and GitLab

		intellipaat.com
		
		
	

			
			
		
	




There is plenty more but this gives a decent summary. GitLab allows private repos which I think are a really useful thing. I think it should also be easier to integrate our own GitLab stuff or move it if we want to 





 

This comparison is quite dated (for instance, GitHub definitely has CI/CD integrated nowadays, and GitLab is by no means buggy and slow), but I also would support GitLab over GitHub as our definitive location simply on the principle of it being FOSS instead of closed source hosting.

 

It does have an identical Code owners feature to GitHub with the same syntax and location. I'm not sure if it's available in the self hosted/free versions or if it is one of their premium features. I'm getting conflicting information on that.

 

It does support automatic mirroring, so it would be easy for us to self host the official repository but still allow automated mirrors on GitHub and the public GitLab for ease of contribution by others.

 

--Greg

 





 

We aren’t a democracy but as far as it goes - I welcome the move to Git so, so gladly and I vote for moving towards GitLab as there is more active development of us already

 

Peter

 


Sent from my phone. Please forgive misspellings and weird “corrections”

 
On 18 Mar 2023, at 11:20, Matěj Cepl <mc...@cepl.eu> wrote:
 



On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:

I am very happy with this progress in your thinking about git. I just 

reiterate my preference for gitlab, where as Peter has already pointed 

out we now have all our modules. It would be consistent to add the sword 

sources there as well.

@David I don't particularly use github for my personal projects which 

are all under gitlab.

+1

Matěj
-- 
https://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
   -- Tim Hansel


___
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






--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___ 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

Re: [sword-devel] CrossWire and git

[Troy A. Griffitts]

Guys who prefer GitLab, I am sorry. No university research project, no 
commercial job has ever asked me to use GitLab. They have all asked me use 
GitHub. From a purely popular choice and to prevent all of us from having to 
create yet another account (I am sure most everyone already has a GitHub 
account) and learn yet another tool, can't we just settle on GitHub. Would it 
make anyone extremely unhappy? GitLab is not my preferred choice.

On March 18, 2023 6:40:57 AM MST, Greg Hellings  wrote:
>On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:
>
>> GitLab vs GitLab
>>
>> [image: image3-1.png]
>>
>> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
>> 
>> intellipaat.com
>> 
>> 
>>
>> There is plenty more but this gives a decent summary. GitLab allows
>> private repos which I think are a really useful thing. I think it should
>> also be easier to integrate our own GitLab stuff or move it if we want to
>>
>
>This comparison is quite dated (for instance, GitHub definitely has CI/CD
>integrated nowadays, and GitLab is by no means buggy and slow), but I also
>would support GitLab over GitHub as our definitive location simply on the
>principle of it being FOSS instead of closed source hosting.
>
>It does have an identical Code owners feature to GitHub with the same
>syntax and location. I'm not sure if it's available in the self hosted/free
>versions or if it is one of their premium features. I'm getting conflicting
>information on that.
>
>It does support automatic mirroring, so it would be easy for us to self
>host the official repository but still allow automated mirrors on GitHub
>and the public GitLab for ease of contribution by others.
>
>--Greg
>
>
>> We aren’t a democracy but as far as it goes - I welcome the move to Git
>> so, so gladly and I vote for moving towards GitLab as there is more active
>> development of us already
>>
>> Peter
>>
>> Sent from my phone. Please forgive misspellings and weird “corrections”
>>
>> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>>
>> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>>
>> I am very happy with this progress in your thinking about git. I just
>>
>> reiterate my preference for gitlab, where as Peter has already pointed
>>
>> out we now have all our modules. It would be consistent to add the sword
>>
>> sources there as well.
>>
>> @David I don't particularly use github for my personal projects which
>>
>> are all under gitlab.
>>
>>
>> +1
>>
>> Matěj
>> --
>> https://matej.ceplovi.cz/blog/, @mcepl@floss.social
>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>
>> Pain is inevitable, but misery is optional. We cannot avoid pain,
>> but we can avoid joy.
>>-- Tim Hansel
>>
>>
>> ___
>> 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
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Greg Hellings]

On Sat, Mar 18, 2023, 06:41 Peter von Kaehne  wrote:

> GitLab vs GitLab
>
> [image: image3-1.png]
>
> GitLab vs GitHub: Top 10 Differences between GitHub and GitLab
> 
> intellipaat.com
> 
> 
>
> There is plenty more but this gives a decent summary. GitLab allows
> private repos which I think are a really useful thing. I think it should
> also be easier to integrate our own GitLab stuff or move it if we want to
>

This comparison is quite dated (for instance, GitHub definitely has CI/CD
integrated nowadays, and GitLab is by no means buggy and slow), but I also
would support GitLab over GitHub as our definitive location simply on the
principle of it being FOSS instead of closed source hosting.

It does have an identical Code owners feature to GitHub with the same
syntax and location. I'm not sure if it's available in the self hosted/free
versions or if it is one of their premium features. I'm getting conflicting
information on that.

It does support automatic mirroring, so it would be easy for us to self
host the official repository but still allow automated mirrors on GitHub
and the public GitLab for ease of contribution by others.

--Greg


> We aren’t a democracy but as far as it goes - I welcome the move to Git
> so, so gladly and I vote for moving towards GitLab as there is more active
> development of us already
>
> Peter
>
> Sent from my phone. Please forgive misspellings and weird “corrections”
>
> On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:
>
> On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
>
> I am very happy with this progress in your thinking about git. I just
>
> reiterate my preference for gitlab, where as Peter has already pointed
>
> out we now have all our modules. It would be consistent to add the sword
>
> sources there as well.
>
> @David I don't particularly use github for my personal projects which
>
> are all under gitlab.
>
>
> +1
>
> Matěj
> --
> https://matej.ceplovi.cz/blog/, @mcepl@floss.social
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> Pain is inevitable, but misery is optional. We cannot avoid pain,
> but we can avoid joy.
>-- Tim Hansel
>
>
> ___
> 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

Re: [sword-devel] CrossWire and git

[Peter von Kaehne]

GitLab vs GitLabGitLab vs GitHub: Top 10 Differences between GitHub and GitLabintellipaat.comThere is plenty more but this gives a decent summary. GitLab allows private repos which I think are a really useful thing. I think it should also be easier to integrate our own GitLab stuff or move it if we want to We aren’t a democracy but as far as it goes - I welcome the move to Git so, so gladly and I vote for moving towards GitLab as there is more active development of us alreadyPeterSent from my phone. Please forgive misspellings and weird “corrections”On 18 Mar 2023, at 11:20, Matěj Cepl  wrote:On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:I am very happy with this progress in your thinking about git. I just reiterate my preference for gitlab, where as Peter has already pointed out we now have all our modules. It would be consistent to add the sword sources there as well.@David I don't particularly use github for my personal projects which are all under gitlab.+1Matěj-- https://matej.ceplovi.cz/blog/, @mcepl@floss.socialGPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8Pain is inevitable, but misery is optional. We cannot avoid pain,but we can avoid joy.    -- Tim Hansel___sword-devel mailing list: sword-devel@crosswire.orghttp://crosswire.org/mailman/listinfo/sword-develInstructions 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

Re: [sword-devel] CrossWire and git

[Matěj Cepl]

On 2023-03-18, 09:55 GMT, Fr Cyrille wrote:
> I am very happy with this progress in your thinking about git. I just 
> reiterate my preference for gitlab, where as Peter has already pointed 
> out we now have all our modules. It would be consistent to add the sword 
> sources there as well.
> @David I don't particularly use github for my personal projects which 
> are all under gitlab.

+1

Matěj
-- 
https://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Pain is inevitable, but misery is optional. We cannot avoid pain,
but we can avoid joy.
-- Tim Hansel


___
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page

Re: [sword-devel] CrossWire and git

[Fr Cyrille]

I am very happy with this progress in your thinking about git. I just 
reiterate my preference for gitlab, where as Peter has already pointed 
out we now have all our modules. It would be consistent to add the sword 
sources there as well.
@David I don't particularly use github for my personal projects which 
are all under gitlab.


Le 18/03/2023 à 08:41, Tobias Klein a écrit :


Yay! Thanks for your efforts to move into this direction! :) Exciting 
news!


Best regards,
Tobias

On 3/17/23 8:27 PM, Greg Hellings 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  
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  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  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 

Re: [sword-devel] CrossWire and git

[Tobias Klein]

Yay! Thanks for your efforts to move into this direction! :) Exciting news!

Best regards,
Tobias

On 3/17/23 8:27 PM, Greg Hellings 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 > 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 mailto: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 mailto: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

Re: [sword-devel] CrossWire and git

[Greg Hellings]

Now I'm attaching a simplified version of the CODEOWNERS for just the sword
repository. I've combined the configure.ac, Makefile.am, and CMakeLists.txt
entries to single entries and I've sorted the entries alphabetically (I
think...) ignoring any leading "/" characters. I've also substituted
usernames for where I know them:

scribe -> scribe777
refdoc == refdoc
tbiggs -> Tee2
charcoal -> karlkleinpaste

The others mentioned I don't know an equivalent GitHub username for:
willthimbleby, mgruner, dglassey, jansorg, chrislit

I've also gone ahead and created the 3 teams that are mentioned in the
file, so users can be added to them as appropriate.

--Greg

On Fri, Mar 17, 2023 at 5:21 PM Greg Hellings 
wrote:

> I'm attaching a Python file that gives a basic go at parsing the access
> file into a GitHub CODEOWNERS file, along with the output I get from it.
> It's not flawless, but it does properly transform group names to
> "@crosswire/group-name". It also assumes users have the same username
> between Crosswire and GitHub. Obviously a search/replace can account for
> that where it proves false.
>
> There is obviously plenty of room to simplify this, as it assumes all
> files are anchored to the root of the repository, and that does not have to
> be the case for CODEOWNERS. (e.g. /CMakeLists.txt will only apply to the
> file in the root of the repository whereas CMakeLists.txt would apply to a
> file with that name anywhere in the repo) However, it _should_ get us 99%
> of the way there.
>
> Note that the CODEOWNERS_files.txt includes an output for every one of the
> repos mentioned in your access file that you'd need to copy and paste out.
> Feel free to modify the script I've attached and run it with
> `access-to-codeowners.py access` as the argument. It can take arbitrarily
> many inputs or can have the access file piped to it if you want to
> pre-process in some way (e.g. by something like `sed -e
> s/scribe/scribe777/g`).
>
> --Greg
>
> On Fri, Mar 17, 2023 at 4:59 PM Timmy  wrote:
>
>> 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  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  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 
 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
> 

Re: [sword-devel] CrossWire and git

[Greg Hellings]

I'm attaching a Python file that gives a basic go at parsing the access
file into a GitHub CODEOWNERS file, along with the output I get from it.
It's not flawless, but it does properly transform group names to
"@crosswire/group-name". It also assumes users have the same username
between Crosswire and GitHub. Obviously a search/replace can account for
that where it proves false.

There is obviously plenty of room to simplify this, as it assumes all files
are anchored to the root of the repository, and that does not have to be
the case for CODEOWNERS. (e.g. /CMakeLists.txt will only apply to the file
in the root of the repository whereas CMakeLists.txt would apply to a file
with that name anywhere in the repo) However, it _should_ get us 99% of the
way there.

Note that the CODEOWNERS_files.txt includes an output for every one of the
repos mentioned in your access file that you'd need to copy and paste out.
Feel free to modify the script I've attached and run it with
`access-to-codeowners.py access` as the argument. It can take arbitrarily
many inputs or can have the access file piped to it if you want to
pre-process in some way (e.g. by something like `sed -e
s/scribe/scribe777/g`).

--Greg

On Fri, Mar 17, 2023 at 4:59 PM Timmy  wrote:

> 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  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  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  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 
 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 
 wrote:

> I think I own the CrossWire organization though not sure anymore. I
> will 

Re: [sword-devel] CrossWire and git

[Timmy]

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

Re: [sword-devel] CrossWire and git

[Timmy]

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

Re: [sword-devel] CrossWire and git

[Timmy]

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

Re: [sword-devel] CrossWire and git

[David Haslam]

This thread so far mentions GitHub but some of our projects for module content 
development have been hosted on GitLab and some on the GitLab instance 
installed on the CrossWire server.

IIRC, Peter owns and manages users on the latter (git.crosswire.org), and 
possibly also the CrossWire organisation on gitlab.com. Correct me if I’m 
mistaken.

btw. Fr Cyrille also uses GitHub for some module development.

NB. Which project resides where largely depends on the copyright status of the 
content.

Source code development for the SWORD API is a separate activity. Are we 
envisaging using GitHub for this purpose?

David

Sent from Proton Mail for iOS

On Fri, Mar 17, 2023 at 20:08, Peter von Kaehne  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  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  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  

Re: [sword-devel] CrossWire and git

[Peter von Kaehne]

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? PeterSent from my phone. Please forgive misspellings and weird “corrections”On 17 Mar 2023, at 20:11, Greg Hellings  wrote:Current owners are myself, DM, Karl, and Doug Campos. I sent Troy an invite to it.--GregOn Fri, Mar 17, 2023 at 3:09 PM Peter von Kaehne  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 soSent from my phone. Please forgive misspellings and weird “corrections”On 17 Mar 2023, at 19:28, Greg Hellings  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-ownersIf 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.--GregOn Fri, Mar 17, 2023, 14:09 Troy A. Griffitts  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 

Re: [sword-devel] CrossWire and git

[Greg Hellings]

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

Re: [sword-devel] CrossWire and git

[Peter von Kaehne]

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 soSent from my phone. Please forgive misspellings and weird “corrections”On 17 Mar 2023, at 19:28, Greg Hellings  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-ownersIf 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.--GregOn Fri, Mar 17, 2023, 14:09 Troy A. Griffitts  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 
  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 
  

Re: [sword-devel] CrossWire and git

[Greg Hellings]

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

[sword-devel] CrossWire and git

[Troy A. Griffitts]

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  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  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
 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
 wrote:

Any update on this (after 3.5 months)?

Zdenko

On Sat, 26 Nov 2022 at 21:53, Greg Hellings
 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
 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* 
Date: Sun, 6 Nov 2022 at 22:22
Subject: cmake patches
To: 


Hello,