[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘core-updates’ is gone; long live ‘core-packages-team’!
From: |
Maxim Cournoyer |
Subject: |
Re: ‘core-updates’ is gone; long live ‘core-packages-team’! |
Date: |
Sun, 15 Dec 2024 12:59:38 +0900 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Chris,
Sorry for reviving a 14 weeks old thread, I'm still catching up
post-move :-).
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? The previous way seemed
more natural to me; the 'request for merge' issue would be created when
the branch was mostly built or at least tested and deemed ready for
being merged. Now we won't know; we will depend on the person creating
the branch being around to let us know of its state (plus the QA/CI
indicatorcs of course).
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.
My 2 cents.
--
Thanks,
Maxim
- Re: ‘core-updates’ is gone; long live ‘core-packages-team’!,
Maxim Cournoyer <=
Re: ‘core-updates’ is gone; long live ‘core-packages-team’!, Christopher Baines, 2024/12/15