This looks correct to me. Ralph
> On Jan 26, 2018, at 8:45 AM, Denes Arvay <de...@cloudera.com> wrote: > > Hi Flume Community, > > I have squashed the previously mentioned commits on my fork, I'd be happy > if you could have a look on it: > https://github.com/adenes/flume/commits/squashed-log4j-upgrade > > I have compared the source files with the current trunk (commit: ffc5554), > found no difference. > I also compiled trunk and my branch and compared the class files, the only > difference was the > auto-generated > ./flume-ng-core/target/classes/org/apache/flume/package-info.class > file, which contains the branch name, commit hash, etc. > > This is the new commit > https://github.com/adenes/flume/commit/69c66efefdcd74904986f2727bdf0d52dd9a75e5 > which > was created by squashing the following commits: > > fbc7a68 Merge branch 'trunk' into flume-2050 > 6813d9c Upgrade to Log4j 2.10.0 > e4fd6ab Remove more references to log4j 1 > 6b6605c Update configuration to match log4j 1.x > 4bb5e88 FLUME-2050 - modify pattern layout so NDC is ignored if it has no > data > 4a07fbf FLUME-2050 remove spurious files > 140ea5d FLUME-2050 Upgrade to Log4j 2 > > If there are no objections I'll force push this to the trunk. > (Note: it might mess up the git-wip-us.apache.org -> github repo mirroring, > if that happens I'll get in touch with Apache Infra to sort it out) > > Regards, > Denes > > > On Wed, Jan 17, 2018 at 12:00 AM Mike Percy <mpe...@apache.org> wrote: > >> I agree squash-before-push is a good policy to maintain a readable commit >> history. >> >> I'd be +1 to doc this and squash the relevant commits. >> >> Mike >> >> On Wed, Jan 10, 2018 at 5:37 AM, Denes Arvay <de...@cloudera.com> wrote: >> >>> Hi Hari, >>> >>> Thank you for your answer. >>> I think having one single commit with a structured commit message >> belonging >>> to one Jira ticket has several benefits: >>> - it makes it easier to cherry-pick/backport fixes to release branches >>> - simplifies the commit history and avoids having different ways for >>> different committers to merge the changes >>> - makes it possible to give credit to the authors and reviewers >>> >>> So I suggest to keep the squash-before-pushing policy but I'm open for >> more >>> inputs, recommendations as well. >>> >>> Best, >>> Denes >>> >>> On Tue, Jan 9, 2018 at 10:55 PM Hari Shreedharan < >> hshreedha...@apache.org> >>> wrote: >>> >>>> I don't have any objections to that, but I have to wonder if it makes >>> sense >>>> to update the guidelines to actually not have to squash commits. I >> think >>>> the reason we needed to squash those commits was that we were >> originally >>> on >>>> SVN and having multiple commits didn't make much sense in SVN. It is >> easy >>>> to track history with a single commit, but that looks to be the case >>> anyway >>>> (I just see 1 merge commit, which is fine - it is an artifact of pull >>>> request merges). >>>> >>>> That said, I don't have an objection to force-pushing, we just need to >>> make >>>> sure no history is lost. >>>> >>>> On Tue, Jan 9, 2018 at 1:03 AM, Denes Arvay <de...@cloudera.com> >> wrote: >>>> >>>>> Hi Flume Community, >>>>> >>>>> A couple of commits went in to trunk recently which weren't in line >>> with >>>>> our commit guidelines. >>>>> I suggest to squash these commits to one and do a force push to >> resolve >>>>> this issue, plus - as the guidelines are not clear enough - I'd like >> to >>>>> extend the >>>>> https://github.com/apache/flume/blob/trunk/dev-docs/HowToCommit.md >> doc >>>> to >>>>> be more concrete on the requirements for a commit. These rules are >>>>> currently mostly unwritten, so it'd be useful to clarify them. >>>>> >>>>> I'm happy to do these if there is no objection from the community. >>>>> >>>>> Regards, >>>>> Denes >>>>> >>>> >>> >>
