On 2/13/26 18:14, Rutherther wrote:
Hugo Buddelmeijer via "Development of GNU Guix and the GNU System
distribution." <[email protected]> writes:
A caveat for merging master into develop is that it only works well when
there are no version numbers hardcoded in master. So we'd need to have
release branches, or get the version from the git tag/branch.
We already have release branches.
I meant release branch that are never brought back into master (or
develop), like a "1.5.x" branch, from which 1.5.1 will be tagged if
necessary.
Such branches can be useful when hotfixes need to be back ported. There
other procedures for such scenarios though.
P.S. about the CI merging devel into master: I strongly believe that
no-one should be able to merge into master locally and then push.
Because people that can do that will be a target for hackers.
IMO, merges to master should *only* be done through codeberg. But I
don't have experience with how to do that with signing commits.
We cannot do that with signing commits. Even when Forgejo supports it,
the signing keys should be given only to humans as far as I understand
the current policies.
I don't really understand the argument, though. If one's computer
becomes compromised, why wouldn't the malware be able to send a request
to codeberg...
Let's phrase it in a different way, I personally think it would be good
to (slowly?) move towards to a system where a commit on master can only
be done by two people working together, not any one individual.
We could make such collaboration smoother by doing part of the process
on codeberg. How this should technically be done, I don't know. We can
keep such ideas in the back of our mind even though we have more urgent
concerns now.
But I'm not a committer myself, so I don't need to worry about this yet.
I brought it up as a side note, we don't need to discuss it now.
Hugo
