Maxim Cournoyer writes: > Sorry for reviving a 14 weeks old thread, I'm still catching up > post-move :-).
Ah that explains why I missed this... > Christopher Baines <m...@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? [..] > 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. Greetings, Janneke -- Janneke Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond https://LilyPond.org Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
