Hi, Christopher Baines <m...@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
