[llvm-dev] [cfe-dev] [lldb-dev] GitHub anyone?
Craig, Ben via llvm-dev
llvm-dev at lists.llvm.org
Fri Jun 3 11:17:48 PDT 2016
On 6/3/2016 12:56 PM, dag at cray.com wrote:
> "Craig, Ben" <ben.craig at codeaurora.org> writes:
>
>> If we have automation that looks at public topic branches (possibly
>> because of a github pull request), then people will start making
>> branches public sooner rather than later. That's when we start getting
>> into fixup territory.
> Automation should never be a substitute for developer testing [...]
I disagree with this statement. From my point of view, it would be
awesome if I could just post a change through a github pull request and
have tests run on every supported platform on someone else's hardware.
Just running the lit tests on my hardware with my setup is inferior,
from my perspective. All those vendors trying to sell my cloud time
would also likely disagree with your statement.
Is it practical to make automation run everywhere on every public
commit? Probably not from the build bot owner's perspective.
> , because
> it leads to exactly what you're describing. If we don't have one
> already, there should be a policy about this.
If we squash before merging into master, then all the fixups disappear.
A squashed patch is easy to revert, easy to keep linear, and easy to
look at through git log without any extra flags. There are downsides
and places where squashing doesn't make sense. Squashing doesn't make
sense when there is a series of patches that cannot be merged
individually, but still provide value independently. Squashing doesn't
make sense when you have one long term, high quality branch, with lots
of changes on it, and you want to bring that into another branch. I
think that these cases are the exception. One other downside is that
squashing patches does leave the source branch / fork mostly "orphaned",
as we've now taken source, but rewritten history in the transition. I
think this is fine too.
So yes, I think people should run lots of tests before making things
public, and I would prefer not to get lots of github spam from people
doing fixups on private forks. I also don't want to put newbies through
the git wringer though when there's a straightforward server side fix.
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
More information about the llvm-dev
mailing list