work-in-progress team branches (was: Re: ‘core-updates’ is gone; long live ‘core-packages-team’!)

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

Hi,

Christopher Baines <mail@cbaines.net> writes:

[...]

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

I see; that sounds workable, although it was nice to get
substitutes for the 'gnome-team' branch even though it was a WIP (in the
sense that we weren't sure the new reviewed commits would
build/integrate fine before pushing them to the gnome-team branch).
We'll need to register another branch (the wip-* one) to Cuirass for
this use case I guess.

Does the following doc addition makes sense?  I've placed it at the end
of the 'Managing Patches and Branches' section:

--8<---------------cut here---------------start------------->8---
1 file changed, 11 insertions(+)
doc/contributing.texi | 11 +++++++++++

modified   doc/contributing.texi
@@ -2362,6 +2362,17 @@ Managing Patches and Branches
 Once the branch has been merged, the issue should be closed and the
 branch deleted.
 
+@cindex work-in-progress branches, wip
+@cindex wip branches
+Sometimes, branches may be a work in progress, for example, for larger
+efforts such as updating the GNOME desktop.  For such cases, the branch
+name should reflect this by having the ``wip-'' prefix.  The QA
+infrastructure will avoid building work-in-progress branches, so that
+the available resources can be better focused on building the branches
+that are ready to me merged.  When the branch is not longer a work in
+progress, it should be renamed, with the ``wip-`` prefix removed, and
+only then should the merge requests be created, as documented earlier.
+
 @node Debbugs User Interfaces
 @subsection Debbugs User Interfaces
--8<---------------cut here---------------end--------------->8---

-- 
Thanks,
Maxim