Hi Chris, Sorry for reviving a 14 weeks old thread, I'm still catching up post-move :-).
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? The previous way seemed more natural to me; the 'request for merge' issue would be created when the branch was mostly built or at least tested and deemed ready for being merged. Now we won't know; we will depend on the person creating the branch being around to let us know of its state (plus the QA/CI indicatorcs of course). 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. My 2 cents. -- Thanks, Maxim
