On Sun, May 8, 2016 at 8:18 AM, Kent Fredric <kentfred...@gmail.com> wrote: > On 9 May 2016 at 00:09, Anthony G. Basile <bluen...@gentoo.org> wrote: >> 1. announce to gentoo-dev@ the intention to start a branch intending to >> merge >> >> 2. hack hack hack >> >> 3. test the merge for any conflicts etc, >> >> 4. announce to the list a date/time to merge >> >> 5. if okay, ermge > > It would make much sense for this series to be visible on Master as a > "add Perl 5.24 to tree" commit, because all the changes are inherently > interdependent, > and it would make little sense to rewind to a specific point within > that series and use it as a portage tree. > > But that's not significant enough to warrant a lot of formal fluffing around. > > It for sure would be best if that 100 commit range was rebased before > merging, but it should still be a non-fast-forward merge just to keep > the history logical. >
++ merges shouldn't just be used for random pull-requests. However, when you're touching multiple packages/etc they should be considered. They should also be considered if for some reason you had a bazillion commits to a single package that for some reason shouldn't be rebased. I imagine that they'll be a small portion of commits as a result. However, for the situations where they're appropriate they make a lot of sense. This was some of Duncan's point, but I will comment that we'll never have as clean a history as the kernel simply because we don't have a release-based workflow with the work cascading up various trees. The kernel is almost an ideal case for a merge-based workflow. I imagine that half of Gentoo's commit volume is random revbumps and keyword changes and that is just going to be noise no matter what. If we were release-based we could do that stuff in its own branch and merge it all in at once, but that just isn't us. -- Rich
