[LLVMdev] code-owner sporks

[Sean Silva]

> 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
>