On 5/8/16 8:34 AM, Rich Freeman wrote: > 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.
i was actually thinking of sec-policy where i remember writing a script back in the CVS days that did some 200 commits, one after another. i was migrating some work for Swift from an overlay to the main tree. 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. a bazillion commits to a category that almost no one touches and except one person or team, like sec-policy or dev-perl etc. so again, i'm against an outright banning of merge commits, but we need to restrict them to reasonable cases, "reasonable" being judged by the community. > 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 > -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
