llvm dev - Nov 2012 - [LLVMdev] code-owner sporks

I think the main benefit of a scheme like this would be that a pull request
tells a code owner which patches require their attention. As a contributor
it would be nice to see your patch in a queue somewhere rather than just be
buried down the mailing list. When patches are sent to llvm-commits it can
be hard to tell if a code owner has noticed the patch because it is a very
high-volume list.

 

As a code owner I would think it would be nice to see a consolidated list of
the open patches for your area. I suppose it would also be nice to see which
commits have gone into your area and need a post-commit review.

 

-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
by The Linux Foundation

 

 

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eric Christopher
Sent: Thursday, November 15, 2012 5:48 PM
To: Greg Fitzgerald
Cc: llvmdev at cs.uiuc.edu List
Subject: Re: [LLVMdev] code-owner sporks

 

 

 

On Thu, Nov 15, 2012 at 5:17 PM, Greg Fitzgerald <garious at gmail.com>
wrote:

Just brainstorming here, but what if each CODE_OWNER maintained a spork on
Github and accepted Pull Requests?  What's a spork, you ask?  Well it's
fork
with no intent to diverge - it spoons some centralized repo (be it via git
or git-svn).  If you haven't heard the term 'spork' in this context
before,
it's either because I just made it up or that we share the same incapacity
to google effectively.

 

As a contributor, my process would be to fork Github's llvm-mirror and make
my patch locally.  Then I'd crawl up the directory tree from my code changes
until I found a CODE_OWNER.TXT.  Worst case, I get to the root directory and
spot a CODE_OWNER.TXT with a URI to the central repository.  All other
CODE_OWNER.TXT files would contain a git URI pointing to the code owner's
spork.  I'd make a Pull Request and hope for a review from the owner and/or
anyone else monitoring that spork.  Once the owner accepts the Pull Request,
it'd be between the members of the code-owner oligarchy how and when the
patch is upstreamed to the central repository.

 

Thoughts?

 

 

Doesn't sound useful for the code owners. Barrier to entry on submitting
patches to llvm or clang is almost never the version control scheme so I
don't see what the community gains either other than more complexity to
manage.

 

 

-eric

 

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

> I think the main benefit of a scheme like this would be that a pull request
> tells a code owner which patches require their attention. As a contributor
> it would be nice to see your patch in a queue somewhere rather than just be
> buried down the mailing list. When patches are sent to llvm-commits it can
> be hard to tell if a code owner has noticed the patch because it is a very
> high-volume list.
It might seem intimidating at first, but it will blow over really
quick once you get one or two patches in and you learn how to do
incremental development. Ping at appropriate time intervals (~3 days
is sane); I think the most pings I've seen before an answer is Ping^4
("Fix cmake for Hexagon cross compilers"), and the reviewers were very
apologetic about the situation. Looking back at your submission
history, it looks like your patches have been really "meaty" patches;
by that I mean that they affect core functionality and need a careful
review by one of a small number of people who really understand that
part of the code; understandably, these patches are more likely to go
unanswered, especially if you haven't gotten a foothold in that part
of the tree.

You might try sending in some smaller, trivial patches, like
documenting a function which is missing documentation (your patches
show that you apparently know the code quite well, an advantage I
didn't have), or even just spelling fixes (don't go overboard though).
That helps grease the wheels. Look at c27faccb in llvm.git and
2bfdad11 in clang.git for my first two patches, which I caught simply
because I was self-hosting with a bleeding-edge clang with the latest
warnings turned on.
> As a code owner I would think it would be nice to see a consolidated list
of
> the open patches for your area. I suppose it would also be nice to see
which
> commits have gone into your area and need a post-commit review.
A spork does nothing to solve this: most development is small,
incremental changes done by people with commit access *committing
directly to trunk* (possibly after a review if the change isn't
"obvious", or is large, or otherwise tricky). The LLVM development
style tries to make many small, *completely obvious* changes which are
committed to trunk directly, with very strong code review for less
obvious changes (generally pre-commit for more junior committers, and
post-commit for more senior committers).

It *would* be nice for a code-owner to have some way to see what needs
to be reviewed, but a git mirror on github is not going to do that for
them in any way.

-- Sean Silva

On Thu, Nov 15, 2012 at 9:30 PM, David Peixotto <dpeixott at
codeaurora.org> wrote:
> I think the main benefit of a scheme like this would be that a pull request
> tells a code owner which patches require their attention. As a contributor
> it would be nice to see your patch in a queue somewhere rather than just be
> buried down the mailing list. When patches are sent to llvm-commits it can
> be hard to tell if a code owner has noticed the patch because it is a very
> high-volume list.
>
>
>
> As a code owner I would think it would be nice to see a consolidated list
of
> the open patches for your area. I suppose it would also be nice to see
which
> commits have gone into your area and need a post-commit review.
>
>
>
> -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted
> by The Linux Foundation
>
>
>
>
>
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] On
> Behalf Of Eric Christopher
> Sent: Thursday, November 15, 2012 5:48 PM
> To: Greg Fitzgerald
> Cc: llvmdev at cs.uiuc.edu List
> Subject: Re: [LLVMdev] code-owner sporks
>
>
>
>
>
>
>
> On Thu, Nov 15, 2012 at 5:17 PM, Greg Fitzgerald <garious at
gmail.com> wrote:
>
> Just brainstorming here, but what if each CODE_OWNER maintained a spork on
> Github and accepted Pull Requests?  What's a spork, you ask?  Well
it's fork
> with no intent to diverge - it spoons some centralized repo (be it via git
> or git-svn).  If you haven't heard the term 'spork' in this
context before,
> it's either because I just made it up or that we share the same
incapacity
> to google effectively.
>
>
>
> As a contributor, my process would be to fork Github's llvm-mirror and
make
> my patch locally.  Then I'd crawl up the directory tree from my code
changes
> until I found a CODE_OWNER.TXT.  Worst case, I get to the root directory
and
> spot a CODE_OWNER.TXT with a URI to the central repository.  All other
> CODE_OWNER.TXT files would contain a git URI pointing to the code
owner's
> spork.  I'd make a Pull Request and hope for a review from the owner
and/or
> anyone else monitoring that spork.  Once the owner accepts the Pull
Request,
> it'd be between the members of the code-owner oligarchy how and when
the
> patch is upstreamed to the central repository.
>
>
>
> Thoughts?
>
>
>
>
>
> Doesn't sound useful for the code owners. Barrier to entry on
submitting
> patches to llvm or clang is almost never the version control scheme so I
> don't see what the community gains either other than more complexity to
> manage.
>
>
>
>
>
> -eric
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Sean Silva wrote:
> I think the most pings I've seen before an answer is Ping^4
> ("Fix cmake for Hexagon cross compilers"), and the reviewers were
very
And now I have another 6 patches at ping^6
[1/6] Hexagon TC: Update toolchain to add appropriate include paths

Sebastian
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The
Linux Foundation

"David Peixotto" <dpeixott at codeaurora.org> writes:
> I think the main benefit of a scheme like this would be that a pull
> request tells a code owner which patches require their attention. As a
> contributor it would be nice to see your patch in a queue somewhere
> rather than just be buried down the mailing list. When patches are
> sent to llvm-commits it can be hard to tell if a code owner has
> noticed the patch because it is a very high-volume list.
This is right.  The highest barrier to entry for patches is that they
are not seen.

                             -David

Sean Silva <silvas at purdue.edu> writes:
>> I think the main benefit of a scheme like this would be that a pull
request
>> tells a code owner which patches require their attention. As a
contributor
>> it would be nice to see your patch in a queue somewhere rather than
just be
>> buried down the mailing list. When patches are sent to llvm-commits it
can
>> be hard to tell if a code owner has noticed the patch because it is a
very
>> high-volume list.
>
> It might seem intimidating at first, but it will blow over really
> quick once you get one or two patches in and you learn how to do
> incremental development. 
This is simply not true, IME.
> Ping at appropriate time intervals (~3 days is sane); 
3 days is *not* sane.  The fact that we require pings at all indicates a
broken process.  I don't understand why there is such resistance to a
patch queue.  I don't even care about the revision control system as
much as I do about a managed patch system.  We have a system for bugs,
which are _much_ less frequent occurrences than patches.

I can't stall my work for 3 days waiting for someone not to see my
patch.
> I think the most pings I've seen before an answer is Ping^4 ("Fix
> cmake for Hexagon cross compilers"), and the reviewers were very
> apologetic about the situation.
The reviewers are *always* very apologetic.  That doesn't help the
developer, unfortunately.
> Looking back at your submission history, it looks like your
> patches have been really "meaty" patches; by that I mean that
they
> affect core functionality and need a careful review by one of a small
> number of people who really understand that part of the code;
> understandably, these patches are more likely to go unanswered,
> especially if you haven't gotten a foothold in that part of the tree.
Why is that at alkl understandable?  It's understandable that it might
take a while top review them but to not get an acknowledgement at all?
That is never understandable.
> It *would* be nice for a code-owner to have some way to see what needs
> to be reviewed, but a git mirror on github is not going to do that for
> them in any way.
Ok, so lets do it some other way.

                           -David

On Fri, Nov 16, 2012 at 9:52 AM, <dag at cray.com> wrote:
> "David Peixotto" <dpeixott at codeaurora.org> writes:
>
> > I think the main benefit of a scheme like this would be that a pull
> > request tells a code owner which patches require their attention. As a
> > contributor it would be nice to see your patch in a queue somewhere
> > rather than just be buried down the mailing list. When patches are
> > sent to llvm-commits it can be hard to tell if a code owner has
> > noticed the patch because it is a very high-volume list.
>
> This is right.  The highest barrier to entry for patches is that they
> are not seen.
>
>

This is opinion. I see everyone's patches, but my review time is precious
and the patch may not hit the criteria of what I'm willing to spend my time
on.

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