Vagrant Cascadian <vagr...@debian.org> writes: > On 2024-09-06, Ludovic Courtès wrote: >> Simon Tournier <zimon.touto...@gmail.com> skribis: >> >>> In this picture of “merge train”, the CI workload and world rebuilds >>> will increase, no? >>> >>> Consider the two teams: science and this new core-packages. Then >>> science takes care of openblas (6000+ dependent packages) and >>> core-packages of grep (6000+ dependent packages). >>> >>> When science team wants to merge to master, they ask for a rebuild. >>> >>> When core-packages team wants to merge to master, they ask for a >>> rebuild. >>> >>> Therefore, we have two world rebuilds. Or the both teams need to >>> synchronize and thus the branches are indeed developed independently but >>> not tested independently. Are they? >> >> I don’t have a clear answer to that. >> >> The way I see it, one of the branches would be tested independently. >> The second one would also be tested independently, but on a limited >> scope—e.g., x86_64-only, because (1) we usually have more build power >> for that architecture, and (2) perhaps we know the problems with those >> branches are unlikely to be architecture-specific. >> >> Then we’d rebase that second branch on top of the first one, and build >> the combination for all architectures. > > Is it just me, or is rebasing branches disconcerting, as it likely means > the person signing the commit is not necessarily the original person > pushing the commit? This is worst for the now deprecated core-updates > branch with many rebased commits... are people still updating the > signed-off-by tags or whatnot?
Are you finding something specific about that disconcerting? Personally I think having the ability to rebase branches should lead to a cleaner Git history (which is more readable and therefore hopefully more secure). I dislike the idea of treating branches as stateful as that makes them much harder to manage and use, it should be possible to push some commits to a non-master branch, then decide that's a bad idea and remove them without fuss. Maybe it also comes down to whether committers are interchangeable or not. If one persons signature on a commit is viewed differently to someone elses, then maybe there's an issue. I don't believe the Signed-off lines are being added to when rebasing, that still reflects the person or people who took the patch and initially pushed it to a branch. There should still be the extra information about the committer and signature key though.
signature.asc
Description: PGP signature
