llvm dev - Jan 2019 - [cfe-dev] [Github] RFC: linear history vs merge commits

On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> Mehdi AMINI <joker.eph at gmail.com> writes:
>
> > What is the practical plan to enforce the lack of merges? When we
> > looked into this GitHub would not support this unless also forcing
> > every change to go through a pull request (i.e. no pre-receive hooks
> > on direct push to master were possible). Did this change? Are we
> > hoping to get support from GitHub on this?
> >
> > We may write this rule in the developer guide, but I fear it'll be
> > hard to enforce in practice.
>
> Again, changes aren't going through git yet, right?  Not until SVN is
> decommissioned late this year (or early next).  SVN requires a strict
> linear history so it handles the enforcement for now.
> My personal opinion is that when SVN is decomissioned we should use pull
> requests, simply because that's what's familiar to the very large
> development community outside LLVM.  It will lower the bar to entry for
> new contributors.  This has all sorts of implications we need to discuss
> of course, but we have some time to do that.
My personal opinion is an opposite of that one.

*Does* LLVM want to switch from phabricator to github pr's?
I personally don't recall previous discussions.
Personally, i hope not, i hope phabricator should/will stay.

Low bar for entry is good, but not at the cost of raising the bar
for the existing development community.
In particular, i'm saying that github's ui/workflow/feature set
is inferior to that one of phabricator.

Is the low entry bar the only benefit?
While it is good, it should not be the only factor.
The contributors will already need to know how to build LLVM,
write tests, make meaningful changes to the code.
Additionally having to know how to work with phabricator
isn't that much to ask for, considering the other prerequisites..
> If we don't use PRs, then we're pretty much on the honor system to
> disallow merges AFAIK.
>
>                              -David
Roman.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On Thu, Jan 31, 2019 at 12:52 PM Roman Lebedev via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > Mehdi AMINI <joker.eph at gmail.com> writes:
> >
> > > What is the practical plan to enforce the lack of merges? When we
> > > looked into this GitHub would not support this unless also
forcing
> > > every change to go through a pull request (i.e. no pre-receive
hooks
> > > on direct push to master were possible). Did this change? Are we
> > > hoping to get support from GitHub on this?
> > >
> > > We may write this rule in the developer guide, but I fear
it'll be
> > > hard to enforce in practice.
> >
> > Again, changes aren't going through git yet, right?  Not until SVN
is
> > decommissioned late this year (or early next).  SVN requires a strict
> > linear history so it handles the enforcement for now.
>
> > My personal opinion is that when SVN is decomissioned we should use
pull
> > requests, simply because that's what's familiar to the very
large
> > development community outside LLVM.  It will lower the bar to entry
for
> > new contributors.  This has all sorts of implications we need to
discuss
> > of course, but we have some time to do that.
> My personal opinion is an opposite of that one.
>
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
>
> Low bar for entry is good, but not at the cost of raising the bar
> for the existing development community.
> In particular, i'm saying that github's ui/workflow/feature set
> is inferior to that one of phabricator.
>
+1

>
> Is the low entry bar the only benefit?
> While it is good, it should not be the only factor.
> The contributors will already need to know how to build LLVM,
> write tests, make meaningful changes to the code.
> Additionally having to know how to work with phabricator
> isn't that much to ask for, considering the other prerequisites..
>
> > If we don't use PRs, then we're pretty much on the honor
system to
> > disallow merges AFAIK.
> >
> >                              -David
> Roman.
>
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190131/f8888a70/attachment.html>

Roman Lebedev <lebedev.ri at gmail.com> writes:
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
I find Phab pretty unintuitive.  I just started using it in earnest
about four months ago, so that's one datapoint from people new to it.

                            -David

On Thu, Jan 31, 2019 at 4:56 PM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Roman Lebedev <lebedev.ri at gmail.com> writes:
>
> > *Does* LLVM want to switch from phabricator to github pr's?
> > I personally don't recall previous discussions.
> > Personally, i hope not, i hope phabricator should/will stay.
>
> I find Phab pretty unintuitive.  I just started using it in earnest
> about four months ago, so that's one datapoint from people new to it.
>
Having used both, I find GitHub tends to have many similar views that are
slightly different. The way it decides that there are "outdated
comments"
and that those comments should be hard to does not win it any points in my
book.

>
>                             -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190131/de8f53c2/attachment.html>

https://help.github.com/articles/checking-out-pull-requests-locally/

Script a bot to scrape the patches and post to phabricator?

On Fri, 1 Feb 2019 at 04:22, Roman Lebedev via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> >
> > Mehdi AMINI <joker.eph at gmail.com> writes:
> >
> > > What is the practical plan to enforce the lack of merges? When we
> > > looked into this GitHub would not support this unless also
forcing
> > > every change to go through a pull request (i.e. no pre-receive
hooks
> > > on direct push to master were possible). Did this change? Are we
> > > hoping to get support from GitHub on this?
> > >
> > > We may write this rule in the developer guide, but I fear
it'll be
> > > hard to enforce in practice.
> >
> > Again, changes aren't going through git yet, right?  Not until SVN
is
> > decommissioned late this year (or early next).  SVN requires a strict
> > linear history so it handles the enforcement for now.
>
> > My personal opinion is that when SVN is decomissioned we should use
pull
> > requests, simply because that's what's familiar to the very
large
> > development community outside LLVM.  It will lower the bar to entry
for
> > new contributors.  This has all sorts of implications we need to
discuss
> > of course, but we have some time to do that.
> My personal opinion is an opposite of that one.
>
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
>
> Low bar for entry is good, but not at the cost of raising the bar
> for the existing development community.
> In particular, i'm saying that github's ui/workflow/feature set
> is inferior to that one of phabricator.
>
> Is the low entry bar the only benefit?
> While it is good, it should not be the only factor.
> The contributors will already need to know how to build LLVM,
> write tests, make meaningful changes to the code.
> Additionally having to know how to work with phabricator
> isn't that much to ask for, considering the other prerequisites..
>
> > If we don't use PRs, then we're pretty much on the honor
system to
> > disallow merges AFAIK.
> >
> >                              -David
> Roman.
>
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190201/0685dc66/attachment.html>

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of David
> Greene via cfe-dev
> Sent: Thursday, January 31, 2019 4:56 PM
> To: Roman Lebedev
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-dev at lists.llvm.org); LLDB Dev
> Subject: Re: [cfe-dev] [llvm-dev] [Github] RFC: linear history vs merge
> commits
> 
> Roman Lebedev <lebedev.ri at gmail.com> writes:
> 
> > *Does* LLVM want to switch from phabricator to github pr's?
> > I personally don't recall previous discussions.
> > Personally, i hope not, i hope phabricator should/will stay.
> 
> I find Phab pretty unintuitive.  I just started using it in earnest
> about four months ago, so that's one datapoint from people new to it.
Heh. Years ago I described it as "actively user-hostile."  Merely
being
unintuitive is a huge step forward.  I don't know how much of that is
the local LLVM instance being massaged toward usefulness as opposed to
improvements in the underlying product.
--paulr

On 01/31/2019 09:51 AM, Roman Lebedev via llvm-dev
wrote:
> On Thu, Jan 31, 2019 at 8:29 PM David Greene via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>>
>> Mehdi AMINI <joker.eph at gmail.com> writes:
>>
>>> What is the practical plan to enforce the lack of merges? When we
>>> looked into this GitHub would not support this unless also forcing
>>> every change to go through a pull request (i.e. no pre-receive
hooks
>>> on direct push to master were possible). Did this change? Are we
>>> hoping to get support from GitHub on this?
>>>
>>> We may write this rule in the developer guide, but I fear it'll
be
>>> hard to enforce in practice.
>>
>> Again, changes aren't going through git yet, right?  Not until SVN
is
>> decommissioned late this year (or early next).  SVN requires a strict
>> linear history so it handles the enforcement for now.
> 
>> My personal opinion is that when SVN is decomissioned we should use
pull
>> requests, simply because that's what's familiar to the very
large
>> development community outside LLVM.  It will lower the bar to entry for
>> new contributors.  This has all sorts of implications we need to
discuss
>> of course, but we have some time to do that.
> My personal opinion is an opposite of that one.
> 
> *Does* LLVM want to switch from phabricator to github pr's?
> I personally don't recall previous discussions.
> Personally, i hope not, i hope phabricator should/will stay.
> 
This hasn't been decided yet, but this is a whole other discussion
that deserves it own thread (not saying we need to decide this now though).

-Tom
> Low bar for entry is good, but not at the cost of raising the bar
> for the existing development community.
> In particular, i'm saying that github's ui/workflow/feature set
> is inferior to that one of phabricator.
> 
> Is the low entry bar the only benefit?
> While it is good, it should not be the only factor.
> The contributors will already need to know how to build LLVM,
> write tests, make meaningful changes to the code.
> Additionally having to know how to work with phabricator
> isn't that much to ask for, considering the other prerequisites..
> 
>> If we don't use PRs, then we're pretty much on the honor system
to
>> disallow merges AFAIK.
>>
>>                              -David
> Roman.
> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>