Re: ‘core-updates’ is gone; long live ‘core-packages-team’!

[Christopher Baines]

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2024-09-06, Ludovic Courtès wrote:
>> Simon Tournier <zimon.toutoune@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