Hi Guix,
I'm in support of having a forge, but not exactly thrilled to structure
my workflow around it(s web interface). IMHO, Forgejo/Codeberg is a
good choice however, so I won't debate that.
Am Dienstag, dem 28.01.2025 um 15:33 +0100 schrieb Ludovic Courtès:
> To keep track of bug reports and patches, Guix historically chose
> tools that were *simple* in their design:
>
> - bug reports and patches can be sent by plain email, without
> having to create an account or even subscribe to a mailing list;
> - discussion and patch review happen naturally by email, without
> requiring special tools;
I think we should still have simple tools at our disposal, even if they
end up talking to Forgejo in the end.
Perhaps instead of
> - Within **30 days** after acceptance of this GCD, mailing list
> administrators will set up the `bug-guix` and `guix-patches`
> mailing
> lists in “Emergency Moderation” mode in the Mailman
> interface—meaning that messages will not get through anymore. It
> will still be possible to interact on individual issues via
> `n...@debbugs.gnu.org`.
we can make it so that emails to these addresses get forwarded to
Forgejo's bug tracker?
> Since Guix requires signed commits by people listed in
> `.guix-authorizations`, we will *not* be able to click the “Merge”
> button nor to enable auto-merge on build success. This is a security
> feature that we want but it limits scalability as actual merges lays
> on the shoulders of committers. To reduce the load on committers, we
> could use a scheme as follows:
>
> - contributors create pull requests against a `staging` branch
> (TODO:
> check PR templates to force `staging` by default);
> - the `staging` branch is *not* signed and team members can somehow
> enact (TODO: figure how) merging into that branch;
I think we could go harder on the automation through the use of a merge
bot. On a successful build+lint of a pull request, that request would
be merged into staging for a reviewer to look at.
Either way, having a single staging branch might be an issue if
submissions target different branches; e.g. one for python-team, one
for gnome-team. Perhaps "teams" should be given their own
repositories, where they are free to create feature branches as they
like and have their "staging" branch(es) tail a particular branch.
Another idea would be that "staging" keeps the patches themselves as
files in a particular directory (e.g. patches/${bugnumber}), and
committers can apply them by doing something like
$ # git worktree add staging staging
$ git am staging/patches/${bugnumber}/latest/* --signoff
OTOH, whether this is preferable to grabbing the actual issue/PR is
debatable.
> That way, pushes to `master` will be limited to changes that have
> already been validated and built.
Perhaps we should rename 'master' to something else too. Food for
thought for a future GCD :)
Cheers
