Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

I will not respond further on this in this thread.

On Thursday, April 11, 2024 at 1:15:52 PM UTC-7 Dima Pasechnik wrote:

>
>
> On 11 April 2024 21:47:57 CEST, Matthias Koeppe  
> wrote:
> >Once again, the workflow files in .github/workflows have to be statically 
> >present in a repository so that Actions work.
> >And the .devcontainers files have to be statically present in a 
> repository 
> >so that Codespaces work. 
>
> Yes, sure, as I said, you can have it statically present, and test a 
> submodule containing sagelib from there.
>
> There is nothing hard to design here, once you split the repo this way.
>
>
> >
> >If you want to propose a design for breaking our repository into multiple 
> >repositories, work it out first. Learn about the relevant technological 
> >restrictions. 
> >It does not make sense to develop it here in a question-and-answer game. 
> >In particular, this cannot be done here in this thread about governance; 
> >it's only a distraction.
> >
> >Matthias
> >
> >
> >On Thursday, April 11, 2024 at 12:36:20 PM UTC-7 Dima Pasechnik wrote:
> >
> >On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
> >wrote: 
> >>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote: 
> >> 
> >>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
> >>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
> >>> Necessary reminder that we're discussing, as the subject says, the 
> files 
> >>> that control the GitHub workflows and the Codespaces. 
> >>> What a developer may do on their local machine does not matter. 
> >> 
> >>But there is no difference here between a CI and a local machine here. 
> >>A CI is perfectly capable of doing 
> >>"git submodule update --remote" 
> >>and proceed. 
> >> 
> >> 
> >>No. These files are processed by GitHub before any custom code can be 
> run. 
> >
> >Are you saying that "git submodule..." cannot be triggered by 
> >repository_dispatch hook? 
> >So GH Actions cannot be triggered by a submodule update? 
> >
> >
> >
> >> 
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/e49e8408-c44b-4179-8867-3c13e7a79e82n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 11 April 2024 21:47:57 CEST, Matthias Koeppe  
wrote:
>Once again, the workflow files in .github/workflows have to be statically 
>present in a repository so that Actions work.
>And the .devcontainers files have to be statically present in a repository 
>so that Codespaces work. 

Yes, sure, as I said, you can have it statically present, and test a submodule 
containing sagelib from there.

There is nothing hard to design here, once you split the repo this way.


>
>If you want to propose a design for breaking our repository into multiple 
>repositories, work it out first. Learn about the relevant technological 
>restrictions. 
>It does not make sense to develop it here in a question-and-answer game. 
>In particular, this cannot be done here in this thread about governance; 
>it's only a distraction.
>
>Matthias
>
>
>On Thursday, April 11, 2024 at 12:36:20 PM UTC-7 Dima Pasechnik wrote:
>
>On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
>wrote: 
>>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote: 
>> 
>>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>>> Necessary reminder that we're discussing, as the subject says, the files 
>>> that control the GitHub workflows and the Codespaces. 
>>> What a developer may do on their local machine does not matter. 
>> 
>>But there is no difference here between a CI and a local machine here. 
>>A CI is perfectly capable of doing 
>>"git submodule update --remote" 
>>and proceed. 
>> 
>> 
>>No. These files are processed by GitHub before any custom code can be run. 
>
>Are you saying that "git submodule..." cannot be triggered by 
>repository_dispatch hook? 
>So GH Actions cannot be triggered by a submodule update? 
>
>
>
>> 
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/A3395AC1-7AE8-436A-B1AE-B864F5E79BA8%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

Once again, the workflow files in .github/workflows have to be statically 
present in a repository so that Actions work.
And the .devcontainers files have to be statically present in a repository 
so that Codespaces work. 

If you want to propose a design for breaking our repository into multiple 
repositories, work it out first. Learn about the relevant technological 
restrictions. 
It does not make sense to develop it here in a question-and-answer game. 
In particular, this cannot be done here in this thread about governance; 
it's only a distraction.

Matthias


On Thursday, April 11, 2024 at 12:36:20 PM UTC-7 Dima Pasechnik wrote:

On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
wrote: 
>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote: 
> 
>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>> Necessary reminder that we're discussing, as the subject says, the files 
>> that control the GitHub workflows and the Codespaces. 
>> What a developer may do on their local machine does not matter. 
> 
>But there is no difference here between a CI and a local machine here. 
>A CI is perfectly capable of doing 
>"git submodule update --remote" 
>and proceed. 
> 
> 
>No. These files are processed by GitHub before any custom code can be run. 

Are you saying that "git submodule..." cannot be triggered by 
repository_dispatch hook? 
So GH Actions cannot be triggered by a submodule update? 



> 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ccfbffb1-4989-4be4-bcbb-b2680f7394ean%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 11 April 2024 18:06:42 CEST, Matthias Koeppe  
wrote:
>On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote:
>
>On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
>> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
>> Necessary reminder that we're discussing, as the subject says, the files 
>> that control the GitHub workflows and the Codespaces. 
>> What a developer may do on their local machine does not matter. 
>
>But there is no difference here between a CI and a local machine here. 
>A CI is perfectly capable of doing 
>"git submodule update --remote" 
>and proceed.
>
>
>No. These files are processed by GitHub before any custom code can be run.

Are you saying that "git submodule..." cannot be triggered by 
repository_dispatch hook?
So GH Actions cannot be triggered by a submodule update?



>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/D6F9CBA3-4EF6-430C-A534-46B7514CD975%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Thursday, April 11, 2024 at 4:28:12 AM UTC-7 dim...@gmail.com wrote:

On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote: 
> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote: 
> Necessary reminder that we're discussing, as the subject says, the files 
> that control the GitHub workflows and the Codespaces. 
> What a developer may do on their local machine does not matter. 

But there is no difference here between a CI and a local machine here. 
A CI is perfectly capable of doing 
"git submodule update --remote" 
and proceed.


No. These files are processed by GitHub before any custom code can be run.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7c04399f-9b63-4bb1-a7ca-4ac0687dc776n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[dimpase]

On Wed, Apr 10, 2024 at 04:23:13PM -0700, Matthias Koeppe wrote:
> On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote:
> 
> On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe  
> wrote:
> 
> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
> 
> There is simply no need to keep the .gitsubmodules -
> 
> the only file in the main repo affected by "git submodule update --remote" 
> - 
> always synchronized, commit-wise, for everyone.
> 
> 
> There is. Without doing that, the changes made in the submodule won't take 
> effect. 
> 
> This is not true.
> 
>   git submodule update --remote
> 
> will pick up submodules changes just fine.
> 
> 
> Necessary reminder that we're discussing, as the subject says, the files 
> that control the GitHub workflows and the Codespaces.
> What a developer may do on their local machine does not matter.

But there is no difference here between a CI and a local machine here.
A CI is perfectly capable of doing 
"git submodule update --remote" 
and proceed.


> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/b178151b-6c80-4a8c-a93d-04fc824f969dn%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/Zhe2Ke9VxXXQFFco%40hilbert.homenet.telecomitalia.it.


signature.asc
Description: PGP signature

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 3:25:16 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe  
wrote:

On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:

There is simply no need to keep the .gitsubmodules -

the only file in the main repo affected by "git submodule update --remote" 
- 
always synchronized, commit-wise, for everyone.


There is. Without doing that, the changes made in the submodule won't take 
effect. 

This is not true.

  git submodule update --remote

will pick up submodules changes just fine.


Necessary reminder that we're discussing, as the subject says, the files 
that control the GitHub workflows and the Codespaces.
What a developer may do on their local machine does not matter.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b178151b-6c80-4a8c-a93d-04fc824f969dn%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 11:10 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:
>
> On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
> wrote:
>
> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>
>
> Have you ever worked with submodules?
>
>
> Yes, Dima, I have.
>
>
> There is simply no need to keep the .gitsubmodules -
> the only file in the main repo affected by "git submodule update --remote"
> -
> always synchronized, commit-wise, for everyone.
>
>
> There is. Without doing that, the changes made in the submodule won't take
> effect.
>
This is not true.

  git submodule update --remote

will pick up submodules changes just fine.
Read the docs?

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq1niXYTBjvEgncLBxq9KyZEWdVBmSXRn6ab56OiX8s2AA%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 2:40:18 PM UTC-7 Dima Pasechnik wrote:

On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe  
wrote:

On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote: 
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote: 
>[...] git submodules [...] 
> 
>git submodules are included in a repository by specific commit sha of the 
>submodule repo. 
>So whenever one has to make a change in the submodule repo, one also has 
to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR?


I just explained it. To update the version (commit sha) of the submodule.


Have you ever worked with submodules?


Yes, Dima, I have.
 

There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by "git submodule update --remote" 
- 
always synchronized, commit-wise, for everyone.


There is. Without doing that, the changes made in the submodule won't take 
effect. 
That's the whole point.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/56e7ccaa-11de-4013-8a0f-b7cd8965a66an%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On Wed, Apr 10, 2024 at 9:02 PM Matthias Koeppe 
wrote:

> On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:
>
> On 10 April 2024 19:24:12 CEST, Matthias Koeppe 
> wrote:
> >On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
> >
> >[...] git submodules [...]
> >
> >git submodules are included in a repository by specific commit sha of the
> >submodule repo.
> >So whenever one has to make a change in the submodule repo, one also has
> to
> >commit a change (by a second PR) in the main repo.
> Why a 2nd PR?
>
>
> I just explained it. To update the version (commit sha) of the submodule.
>

Have you ever worked with submodules?

There is simply no need to keep the .gitsubmodules -
the only file in the main repo affected by "git submodule update --remote"
-
always synchronized, commit-wise, for everyone.
Yes, it's a bit annoying to have that pesky .gitsubmodules around, and I
can imagine that
git-subtree etc I mentioned are a better alternative.

Dima

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq0JXHPBpq4oFOjsBiaPoDGfqFWZpjT5H0xKGZ7cjXbMxQ%40mail.gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Wednesday, April 10, 2024 at 1:00:06 PM UTC-7 Dima Pasechnik wrote:

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote: 
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote: 
> 
>[...] git submodules [...] 
> 
>git submodules are included in a repository by specific commit sha of the 
>submodule repo. 
>So whenever one has to make a change in the submodule repo, one also has 
to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR?


I just explained it. To update the version (commit sha) of the submodule.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/7e976287-8f5e-4248-b5e9-1601bed1fa6dn%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 19:24:12 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>[...] git submodules [...]
>
>
>git submodules are included in a repository by specific commit sha of the 
>submodule repo.
>So whenever one has to make a change in the submodule repo, one also has to 
>commit a change (by a second PR) in the main repo. 
Why a 2nd PR? 

>Hence this does not solve anything; it only adds more friction.

Anyway, there are alternatives like git-subrepo 
https://github.com/ingydotnet/git-subrepo
and git-subtree, which are said to be 
much more convenient (myself I only used git-submodule, so this is only what 
others say)
and don't suffer from these real or imaginary problems with git-submodule.

Dima


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/C9A68AC0-5474-4A85-9E5C-771CDF803176%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Tuesday, April 9, 2024 at 6:39:00 PM UTC-7 Kwankyu Lee wrote:

How about redefining the meaning of "CI Fix" label:

1. We designate a person to be the CI manager. 
2. For PRs pertaining to the designated directories and files, we add "CI 
Fix" label
3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
5. Hot fix PRs for breakage of CI also gets "CI Fix" label.


Note that "CI Fix" is intended in particular for fixes to the Sage library 
that make the Lint workflow pass.
Such fixes are still needed and should go through normal review.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8537452a-1c7a-499f-8107-169855d026e7n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:

[...] git submodules [...]


git submodules are included in a repository by specific commit sha of the 
submodule repo.
So whenever one has to make a change in the submodule repo, one also has to 
commit a change (by a second PR) in the main repo. 
Hence this does not solve anything; it only adds more friction.

git submodules are also well-known to be a developer education nightmare.
I'm pretty sure we don't want to go there as a solution for anything in the 
Sage project.


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/fa82905b-731c-47c3-ad60-09525a0a4af3n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 03:39:00 CEST, Kwankyu Lee  wrote:
>How about redefining the meaning of "CI Fix" label:
>
>1. We designate a person to be the CI manager. 
>2. For PRs pertaining to the designated directories and files, we add "CI 
>Fix" label
>3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
>4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
>5. Hot fix PRs for breakage of CI also gets "CI Fix" label.

No, this has a big risk that such a manager will accidentally push non-CI bits, 
and obviously the discipline for not mixing CI and non-CI bits in one commit/PR 
will need to be manually managed.

This is why my proposal to split the repo is much better in this way. 

(One of the mottos of the political party I am forced to set up is "monorepos 
considered harmful", along with "batteries excluded" :-))




>
>?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/2F5FD23C-680E-4FC5-8ECE-69BE08A3F3B0%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 02:04:48 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 4:20:56 PM UTC-7 Dima Pasechnik wrote:
>
>have a CI/sage-distro repo [...] with all that .github/ etc stuff needed 
>for CI, including a part of build/ - and checkout sagelib as a submodule.
>
>
>Also that does not work. Part of the .github/workflows is to run the CI on 
>the pull requests for the Sage library, and the .devcontainer is for making 
>GitHub Codespaces available on the pull requests for the Sage library.

Regarding CI, triggering a git update+CI run on an event in  another repo is 
done via a repository_dispatch hook. 


Indeed, it would be silly if one needed to pollute another repo with your CI 
workflow files.

Dima
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/B44D0BAB-7B85-4121-B34E-5851FE72880E%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Kwankyu Lee]

How about redefining the meaning of "CI Fix" label:

1. We designate a person to be the CI manager. 
2. For PRs pertaining to the designated directories and files, we add "CI 
Fix" label
3. The CI manager has the right to merge PRs with "CI Fix" label to develop.
4. The old meaning of "CI Fix" label as "immediate fixes" is dropped.
5. Hot fix PRs for breakage of CI also gets "CI Fix" label.

?


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/a6786dd0-1d85-4b06-99ca-75697172d71en%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Tuesday, April 9, 2024 at 4:20:56 PM UTC-7 Dima Pasechnik wrote:

have a CI/sage-distro repo [...] with all that .github/ etc stuff needed 
for CI, including a part of build/ - and checkout sagelib as a submodule.


Also that does not work. Part of the .github/workflows is to run the CI on 
the pull requests for the Sage library, and the .devcontainer is for making 
GitHub Codespaces available on the pull requests for the Sage library.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/604274c5-e7ac-41ef-a2b4-8bef436a91a8n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 10 April 2024 00:51:33 CEST, Matthias Koeppe  
wrote:
>On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:
>
>How about moving them out of the main Sage tree into separate repos, which 
>can be accessed from the main tree as git submodules?
>
>
>That does not work. 
>.github/workflows orchestrates what runs in the repo -- so it has to be in 
>the repo.
>.devcontainer declares what is offered for the repo in GitHub -- so it has 
>to be in the repo.

Then the other way around - have a CI/sage-distro repo (which can very well 
have relaxed policies) with all that .github/ etc stuff needed for CI, 
including a part of build/ - and checkout sagelib as a submodule.

The orchestration between the two repos looks doable. 


>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/E50C6018-FE63-4F0F-8938-231E7A492A91%40gmail.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Kwankyu Lee]

Oops. Experimenting with this idea, I accidentally pushed a "crazy" commit 
to "develop". Please revoke the commit ASAP! 


I *mv*ed ".github" directory to "github" and made a symlink ".github -> 
github" to see if this works, in my own repo. But I accidentally pushed to 
sagemath/sage! 

I tried to revoke the commit myself, but failed because "develop" is a 
protected branch. I don't know how I could push to the sacred branch in the 
first place.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/1f2c744e-ae75-4787-b87b-4a2015e8777bn%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Kwankyu Lee]

On Wednesday, April 10, 2024 at 7:51:34 AM UTC+9 Matthias Koeppe wrote:

On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:

How about moving them out of the main Sage tree into separate repos, which 
can be accessed from the main tree as git submodules?


That does not work. 
.github/workflows orchestrates what runs in the repo -- so it has to be in 
the repo.
.devcontainer declares what is offered for the repo in GitHub -- so it has 
to be in the repo.


Oops. Experimenting with this idea, I accidentally pushed a "crazy" commit 
to "develop". Please revoke the commit ASAP! 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/6a9b8218-78d4-4fb1-9c8a-c22e6b6a2655n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

On Tuesday, April 9, 2024 at 3:28:27 PM UTC-7 Dima Pasechnik wrote:

How about moving them out of the main Sage tree into separate repos, which 
can be accessed from the main tree as git submodules?


That does not work. 
.github/workflows orchestrates what runs in the repo -- so it has to be in 
the repo.
.devcontainer declares what is offered for the repo in GitHub -- so it has 
to be in the repo.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d0628442-129c-4f7a-a71b-6b3a874dc7b8n%40googlegroups.com.

Re: [sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Dima Pasechnik]

On 9 April 2024 23:11:59 CEST, Matthias Koeppe  wrote:
>Dear Sage developers:
>I propose to consider the following governance change for a small part of 
>the Sage repository:
>1. The directories *.ci, .devcontainer, .github/workflows*. These are 
>special directories that control the GitHub workflows that run for example 
>on pull requests and when release tags are pushed.
>2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain 
>the infrastructure for portability testing of the Sage distribution 
>(https://doc.sagemath.org/html/en/developer/portability_testing.html). 
>
>Some of these files are shipped as part of the Sage distribution, but none 
>of them have any role in the build process or runtime of Sage, and thus 
>none of them are tested by the Release Manager.
>
>*Status quo: *All changes to these files go through the normal review 
>process for Sage PRs; when set to "positive review", Volker merges them 
>into the next development release.
>In the terminology of https://martinfowler.com/articles/ship-show-ask.html 
>(ht Gonzalo Tornaria), this is the "Ask" model.
>
>Acknowledgment: I'm grateful to all who have contributed to the review of 
>my PRs that made changes to these files in the past: thanks for your time 
>and energy.
>
>*Proposed change: *All changes to these files are made through PRs. When 
>the PR is ready, a developer in the Maintainer role directly merges the PR 
>into the "develop" branch.
>In other words, switch to the "Show" model for these changes.

How about moving them out of the main Sage tree into separate repos, which can 
be accessed from the main tree as git submodules?

Then they could be developed in a completely separate process, and the 
corresponding PRs and issues won't be clogging up the main repo (which is 
already overloaded with all sorts of tangentially relevant to sagelib things.)
And the governance of these parts will be a separate thing all together.


Dima

>
>*Why the change:*
>1. Changes to these files do not have any effect on the build and runtime 
>of Sage;
>- thus changes to these files do not risk breaking the mathematical 
>correctness, or the performance of anything in Sage;
>- hence there may not be the same need for formal review compared to 
>changes to the Sage library.
>
>2. Our project has a collective interest in smoothly operating development 
>infrastructure / quality assurance tools;
>- but tragedy of the commons;
>- more specifically, developing/improving such development tools only pays 
>off individually for developers with a sufficiently high volume of activity 
>(cf. 
>https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c);
>- there may also be a technical barrier that prevents developers from even 
>reviewing a PR that makes changes to these files;
>- hence, waiting for reviewers to approve a PR and waiting for the Release 
>Manager to merge it adds too much delay and friction.
>
>3. Examples (all PRs authored by me, waiting for review):
>- "CI build, doc-build: Run containers explicitly, separate jobs for 
>pyright, build, modularized tests, long tests" 
>(https://github.com/sagemath/sage/pull/36498) waiting for review since Oct 
>21, 2023
>- "GH Actions: Build platform-independent wheels of sagemath-environment, 
>sage-setup, sage-sws2rst for PyPI" 
>(https://github.com/sagemath/sage/pull/37099) waiting for review since Feb 5
>- "CI: Update Linux platforms / runners" waiting for review since Feb 14
>- "GH Actions: Build macOS arm64 wheels" 
>(https://github.com/sagemath/sage/pull/37503) waiting for review since Feb 
>28
>- "CI Build: Fix "test modularized distributions" 
>(https://github.com/sagemath/sage/pull/37750) waiting for review since Apr 4
>- "dist.yml: Download optional/experimental tarballs for GitHub Release 
>assets" (https://github.com/sagemath/sage/pull/37762) waiting for review 
>since Apr 6
>
>4. Non-examples (all PRs authored by me, waiting for review):
>- "CI Build: Show segfaults using GitHub annotations" 
>(https://github.com/sagemath/sage/pull/37738, waiting for review) -- this 
>makes changes in sage.doctest, so would continue to be reviewed normally
>- "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run 
>ruff-minimal" (https://github.com/sagemath/sage/pull/37453, waiting for 
>review) -- this also makes changes in src/tox.ini and src/doc, so would 
>continue to be reviewed normally
>- "src/tox.ini (coverage:run): Set concurrency = multiprocessing,threads" 
>(https://github.com/sagemath/sage/pull/37010) -- makes changes in 
>src/tox.ini, so would continue to be reviewed normally
>- "sage -tox -e pyright: Update, speed up, isolate" 
>(https://github.com/sagemath/sage/pull/36515) -- makes changes to 
>pyrightconfig.json and src/tox.ini, so would continue to be reviewed 
>normally
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, 

[sage-devel] Governance proposal: Maintainer/code-owner model for .ci, .devcontainer, .github/workflows, tox.ini

[Matthias Koeppe]

Dear Sage developers:
I propose to consider the following governance change for a small part of 
the Sage repository:
1. The directories *.ci, .devcontainer, .github/workflows*. These are 
special directories that control the GitHub workflows that run for example 
on pull requests and when release tags are pushed.
2. The files *tox.ini* and *build/bin/write-dockerfile.sh*. They contain 
the infrastructure for portability testing of the Sage distribution 
(https://doc.sagemath.org/html/en/developer/portability_testing.html). 

Some of these files are shipped as part of the Sage distribution, but none 
of them have any role in the build process or runtime of Sage, and thus 
none of them are tested by the Release Manager.

*Status quo: *All changes to these files go through the normal review 
process for Sage PRs; when set to "positive review", Volker merges them 
into the next development release.
In the terminology of https://martinfowler.com/articles/ship-show-ask.html 
(ht Gonzalo Tornaria), this is the "Ask" model.

Acknowledgment: I'm grateful to all who have contributed to the review of 
my PRs that made changes to these files in the past: thanks for your time 
and energy.

*Proposed change: *All changes to these files are made through PRs. When 
the PR is ready, a developer in the Maintainer role directly merges the PR 
into the "develop" branch.
In other words, switch to the "Show" model for these changes.

*Why the change:*
1. Changes to these files do not have any effect on the build and runtime 
of Sage;
- thus changes to these files do not risk breaking the mathematical 
correctness, or the performance of anything in Sage;
- hence there may not be the same need for formal review compared to 
changes to the Sage library.

2. Our project has a collective interest in smoothly operating development 
infrastructure / quality assurance tools;
- but tragedy of the commons;
- more specifically, developing/improving such development tools only pays 
off individually for developers with a sufficiently high volume of activity 
(cf. 
https://github.com/sagemath/sage/graphs/contributors?from=2020-01-01=2024-04-09=c);
- there may also be a technical barrier that prevents developers from even 
reviewing a PR that makes changes to these files;
- hence, waiting for reviewers to approve a PR and waiting for the Release 
Manager to merge it adds too much delay and friction.

3. Examples (all PRs authored by me, waiting for review):
- "CI build, doc-build: Run containers explicitly, separate jobs for 
pyright, build, modularized tests, long tests" 
(https://github.com/sagemath/sage/pull/36498) waiting for review since Oct 
21, 2023
- "GH Actions: Build platform-independent wheels of sagemath-environment, 
sage-setup, sage-sws2rst for PyPI" 
(https://github.com/sagemath/sage/pull/37099) waiting for review since Feb 5
- "CI: Update Linux platforms / runners" waiting for review since Feb 14
- "GH Actions: Build macOS arm64 wheels" 
(https://github.com/sagemath/sage/pull/37503) waiting for review since Feb 
28
- "CI Build: Fix "test modularized distributions" 
(https://github.com/sagemath/sage/pull/37750) waiting for review since Apr 4
- "dist.yml: Download optional/experimental tarballs for GitHub Release 
assets" (https://github.com/sagemath/sage/pull/37762) waiting for review 
since Apr 6

4. Non-examples (all PRs authored by me, waiting for review):
- "CI Build: Show segfaults using GitHub annotations" 
(https://github.com/sagemath/sage/pull/37738, waiting for review) -- this 
makes changes in sage.doctest, so would continue to be reviewed normally
- "tox.ini: Add environments ruff, ruff-minimal; GH Actions: run 
ruff-minimal" (https://github.com/sagemath/sage/pull/37453, waiting for 
review) -- this also makes changes in src/tox.ini and src/doc, so would 
continue to be reviewed normally
- "src/tox.ini (coverage:run): Set concurrency = multiprocessing,threads" 
(https://github.com/sagemath/sage/pull/37010) -- makes changes in 
src/tox.ini, so would continue to be reviewed normally
- "sage -tox -e pyright: Update, speed up, isolate" 
(https://github.com/sagemath/sage/pull/36515) -- makes changes to 
pyrightconfig.json and src/tox.ini, so would continue to be reviewed 
normally


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d4a6462d-42ab-4afc-b24e-0be98be20174n%40googlegroups.com.