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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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