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

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 3843 bytes --]

Janneke Nieuwenhuizen <janneke@gnu.org> writes:

> 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.

I think what you're doing is fine. the only thing I'd suggest to change
is regarding branch naming. This isn't documented, but
data.qa.guix.gnu.org (and QA) ignore branches where the name begins with
wip-.

So if as you say this branch is currently being worked on, but not quite
ready to be merged, then I'd suggest naming it as wip-core-packages-team
(or anything else beginning with wip-). That way, the data service will
ignore it and can spend it's time looking at other branches/patch
series.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]