llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] GitHub anyone?

> No matter what, once you push your branch and make it public, anyone
> could pull it and then rewriting history gets trickier.  IME it's best
> to avoid doing that as much as possible.
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.

If we don't put any of that automation in place, and we only run tests 
post-commit, then yeah, I think that keeping changes private as long as 
possible is probably best.

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160603/ce7b8079/attachment.html>

"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, 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 don't put any of that automation in place, and we only run tests
> post-commit, then yeah, I think that keeping changes private as long
> as possible is probably best.
Do you mean post-merge?

I think it's fine if we simply have a policy that says limit history
rewrites once a branch is pushed to the server.  I think most people are
knowledgeable/responsible and when people inevitably make mistakes we
can do some gentle reminders.  It's not a huge deal, just something to
be aware of.

                              -David

> On Jun 3, 2016, at 6:46 AM, Craig, Ben via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
>> No matter what, once you push your branch and make it public, anyone
>> could pull it and then rewriting history gets trickier.  IME it's
best
>> to avoid doing that as much as possible.
> 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.
We're getting off-track, but about this particular point we don't need
to allow public branch in the official repository for that (I hope we won't
allow it). For the purpose of testing private changes, there is always the
possibility of opening a pull-request from a private fork.

-- 
Mehdi

> 
> If we don't put any of that automation in place, and we only run tests
post-commit, then yeah, I think that keeping changes private as long as possible
is probably best.
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

Mehdi Amini <mehdi.amini at apple.com> 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.
>
> We're getting off-track, but about this particular point we don't
need
> to allow public branch in the official repository for that (I hope we
> won't allow it). For the purpose of testing private changes, there is
> always the possibility of opening a pull-request from a private fork.
That seems like a good solution to me.

                         -David