Maxim Cournoyer writes: > Hi, > > Christopher Baines 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.