ter 15 jul 2025 às 17:13:38 (1752610418), l...@gnu.org enviou: > Hi! > > Andreas Enge <andr...@enge.fr> writes: > > > Apparently they do not work with feature or team branches, as we had > > decided to do during Guix Days 2024, but instead all commits go to a > > separate staging branch, which is continually built. If this works out > > well, then the branch is pushed to master. If not, the commits are dropped, > > and the people who submitted them need to get back to square zero and > > submit repaired patches for the next round. > > How are these commits dropped, concretely? Do they get reverted by the > person in charge of this staging branch? >
Since we have a teams coordinator, they could assume a role on this supposed new staging branch where they routinely rebase on top of master and apply team branches on their published states[1]. This branch would then be evaluated, any[2] newly failed builds would amount to the rejection of the whole branch where it came from. The coordinator would then notify the responsible team[3] about the failures and revert the merging of their branch on staging. Staging is then applied on top of master[4]. Appart from this, direct commits to master would be reserved for simple (maybe leaf) package updates, additions, removals, fixes and etc. I'm not sure what would be the best policy in terms of merge conflics between branches, but I assume we could entrust the coordinator on their discretion when those arise if only team members don't, by default, expect the teams coordinator to assume the role of resolving those merges and instead take upon themselves to resolve any conflicts between their branches and master or staging when they want it to be merged. I also don't know if this is feasible with the build farm. Maybe I'm just having a fanciful dream of ease with a nice interplay of holes. 1. This assumes teams are also routinely rebasing their branches on top of master (prefereably after the latest staging merge) and that they are testing and checking their branches to be on a workable, mergeable state or otherwise marked as WIP (and so excluded from the routine rebase). 2. Some inacceptable threshold. 3. Question arises when one team causes breakages on another, at first I'd say that the lower team (the one who causes breaks on another whithout being affected by it) takes priority and get merged but also assumes responsibility to help the affected team on getting back to a working state before going ahead with even more changes on their own branches. 4. And teams whose branches were applied are then responsible for reverting or fixing any problems that may have only shown up after this merge, aka, the coordinator is not to blame for teams own proposed changes.
