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

[Christopher Baines <mail@cbaines.net>]

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

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

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

No worries, I hope move things are going well.

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

So, I think the "you must create a new guix-patches issue each time you
create a branch" makes more sense in the context of [1] which is also
suggesting that branches are just the combination of one or more patch
series.

1: https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html

As I say above, my hope with this is that it would help avoid long
running branches which could become harder to work with. I think this
also makes sense in the context of the limited resources we have, in
particular time/hardware for building things for non-x86_64-linux
architectures. Rather than building all branches that people are working
on for all architectures, it's more useful to focus on building the
branches that people think are ready to merge.

One change I also made at some point is that the data service/QA ignore
branches prefixed with wip-, so while this currently isn't mentioned in
the docs (maybe it should be), one workflow currently is to create a
wip-foo branch and iterate on that, and then when it's ready, push the
changes as foo and create the merge issue.

Going back to your concerns about testing branches/changes before you
think they're ready to merge though, I definitely think there's room for
improvement in tooling and processes in this area though.

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