[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