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

[Janneke Nieuwenhuizen]

Maxim Cournoyer writes:

> Sorry for reviving a 14 weeks old thread, I'm still catching up
> post-move :-).

Ah that explains why I missed this...

> Christopher Baines <mail@cbaines.net> writes:
>
> [...]
>
>>> The manual currently says it goes to 'staging' [1], and that this will
>>> be merged within six weeks. Is this actually true? I don't see any
>>> sign of it on Guix' git [2], and an unsure if the manual is out of
>>> sync with the branches workflow.
>>>
>>> While 'staging' seems like it could have similar difficulties to
>>> core-updates if it gets out of hand. The alternative choice of each
>>> time someone making a branch
>>> 'ffmpeg-and-stuff-i-collected-with-over-300-rebuilds' doesn't seem
>>> like a better choice ;-)
>>
>> That page needs updating I think.
>>
>>>> Recently, Christopher Baines further suggested that, as much as
>>>> possible, branches should be “stateless” in the sense that their changes
>>>> can be rebased anytime on top of ‘master’.  This is what we’ve been
>>>> doing for the past couple of months with ‘core-updates’; that sometimes
>>>> made it hard to follow IMO, because there were too many changes, but for
>>>> more focused branches, that should work well.
>>> (...)
>>>
>>> Long-lived branches and ones that don't cleanly apply onto master
>>> cause lots of difficulties from what I've seen. Perhaps a lesson is
>>> that branches should both be stateless *and* should not exist for more
>>> than 3 months. We already have a rule that encourages atomic changes
>>> within any patch in order to make things faster/easier to review. By
>>> extension, lets do the same with branches - merge them more often.
>>
>> Initially the documentation on branches said to create an issue when you
>> want to merge a branch, but this was changed to when you create a branch
>> to try and avoid situations like this, where a branch sits around and
>> gets stale for many months.
>
> Hm.  So is the intention that the moment a branch is created, it is
> expected to be in a good shape to be merged?

[..]

> For multi-people team endeavours (e.g., GNOME, although Liliana has been
> doing most of the work (thanks!)), it seems a bit unreasonable to expect
> the branch to be ready from the moment it lives.

That's the case with the current `core-packages-team'; sorry I if
derailed this fresh new policy/idea just after it was conceived...

The `core-packages-team' branch focusses on the gcc-14 transition, so
that we may offload to 64bit childhurds: the 64bit Hurd needs gcc-14 and
updating gcc for one architecture/platform only was rejected as overly
complicated.  This means, however, that while I'm looking mainly at
x86_64 and reconfigure'ing my system on `core-packages-team', Efraim has
been looking at the impact on other architectures.  I don't see how we
would co-ordinate our efforts without a common work-in-progress branch?

We've been seeing a regular stream of `squash' commits fixing our and
eachother's patches and I'm keeping `core-packages-team' rebased
regularly and hope that we don't need to merge it once it's ready, but
can just push the final rebase.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com