Re: work-in-progress team branches

[Christopher Baines <mail@cbaines.net>]

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

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

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

Yep, sounds reasonable.

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