On Sunday, May 12, 2024 at 4:42:42 PM UTC+1 Matthias Koeppe wrote:
On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote:
If I read your proposal correctly, it is about removing review from changes
made by "maintainers" [...]
That's right -- for the specified files.
Mostly,
Dear Julian,
On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote:
If I read your proposal correctly, it is about removing review from changes
made by "maintainers" [...]
That's right -- for the specified files.
Mostly, I am opposed to this because changes to the files you
On Thursday, May 9, 2024 at 2:18:41 AM UTC-7 Volker Braun wrote:
+1 to the general idea of maintainers for distinct subtrees
As far as the implementation, I'd rather follow a model where there is a
single merge queue at the end (currently me, could be automated when the CI
is stricter and
Splitting responsibilities for different parts of the codebase is standard
operating procedure for every large software project. And monorepo
(everything in one git tree) is by now the well-established gold standard
for managing the source code, especially for all components where you need
On Friday, May 10, 2024 at 4:19:14 PM UTC-7 julian...@fsfe.org wrote:
There are some means to reuse workflows in GitHub
That's correct.
They are called "reusable workflows", and I use them to provide portability
testing to upstream projects of Sage.
You can read about them in
Dear Matthias,
If I read your proposal correctly, it is about removing review from changes
made by "maintainers" and merging things directly into develop without
waiting for the Release Manager.
Mostly, I am opposed to this because changes to the files you list are not
automatically
On Wednesday, May 8, 2024 at 12:18:51 PM UTC-7 Dima Pasechnik wrote:
I've already said while the previous version of this was discussed, is
that it's a huge mess to have different commit rights for different
parts of the tree,
I'm pretty sure that Volker and I can figure this out; there's no
On Wednesday, May 8, 2024 at 6:51:49 PM UTC-7 Kwankyu Lee wrote:
The command "tox -e update_docker_platforms" involves a change of the list
of tested platforms. The change become effective when a beta release is
made by the release manager, since the docker image files are created only
at the
+1 to the general idea of maintainers for distinct subtrees
As far as the implementation, I'd rather follow a model where there is a
single merge queue at the end (currently me, could be automated when the CI
is stricter and developers do not / cannot ignore it any more). Otherwise
we'll just
On Thursday, May 9, 2024 at 3:25:54 AM UTC+9 Matthias Koeppe wrote:
On Monday, May 6, 2024 at 10:49:07 PM UTC-7 Kwankyu Lee wrote:
I propose a governance change for a small part of the main Sage repository:
1. The directories *.ci, .devcontainer, .github/workflows*. [...]
2. The file
I've already said while the previous version of this was discussed, is
that it's a huge mess to have different commit rights for different
parts of the tree, and I proposed to spin the CI into a separate
repository, as an alternative which simplifies a lot of things.
Dima
On Wed, May 8, 2024 at
On Monday, May 6, 2024 at 10:49:07 PM UTC-7 Kwankyu Lee wrote:
I propose a governance change for a small part of the main Sage repository:
1. The directories *.ci, .devcontainer, .github/workflows*. [...]
2. The file *tox.ini*. [...]
3. The file
On Wednesday, May 8, 2024 at 6:20:52 AM UTC-7 julian...@fsfe.org wrote:
It was a bit unclear to me how your v2 proposal is different from the
initial proposal on this sage-devel thread. Maybe it's helpful to clarify
that build/bin/write-dockerfile.sh was removed from the proposal and
Hi Matthias,
It was a bit unclear to me how your v2 proposal is different from the
initial proposal on this sage-devel thread. Maybe it's helpful to clarify
that build/bin/write-dockerfile.sh was removed from the proposal and
src/doc/en/developer/portability_platform_table.rst was added.
I propose a governance change for a small part of the main 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, as well as the Dev
Dear Sage developers:
I include an updated proposal below, with changes brought by the merged
https://github.com/sagemath/sage/pull/37841, a clarification, and updated
examples).
I ask everyone to focus the discussion on the specifics of the proposal.
I plan to call a vote on this in a week or
On Tuesday, April 9, 2024 at 3:36:32 PM UTC-7 Kwankyu Lee wrote:
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
On Tuesday, April 9, 2024 at 3:36:32 PM UTC-7 Kwankyu Lee wrote:
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
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
19 matches
Mail list logo
