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? Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121115/b3b2ac8a/attachment.html>
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/3c36e09b/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. 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>
Greg,
Unfortunately, I don't expect pulling would not work better as our expected.
For example, GIT_AUTHOR is not honored for 3rd committer to
git-svn-dcommit, even if GIT_AUTHORS is registered person.
I am planning to implement the pre-commit tester, like Buildbot's "Try
builder". Then changesources could be our Phab.
I think to provide a method to confirm consistency with unit tests
would help us. How do you think?
ps. It would be helpful; To mention "My proposal is also available in
{{sha1}} in github/person/repo.git" like pull-request, in a proposal.
Pulling commits from other git repos is easier to some of us.
...Takumi
2012/11/16 Greg Fitzgerald <garious at gmail.com>:> 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?
>
> Thanks,
> Greg
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> 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.I'm not sure what drives the desire to propose these kinds of things, but I also had a similar feeling at some point before I started contributing patches. I think the psychology of it boils down to: "LLVM is really cool and I want to contribute" + "but I haven't really contributed anything, even though I've been lurking for a while" => "there must be some barrier to entry" coupled with: "git is awesome, github is t3h k00l, SVN sucks amirite" + "LLVM uses SVN for trunk" => "of course, the barrier to entry which is blocking me *must* be that LLVM is using svn and not git!" leading to: "I should get LLVM to use git, so that I can get unblocked and start contributing". At least, I think for me it was roughly like that. My memory is, as usual, prone to error; I also question my (nonexistent) qualifications for psychological analysis. Regardless, I can tell you with certainty: the barrier to entry is not that LLVM isn't using git. There is one and only one way to get started contributing patches: get patches reviewed and committed. It's a bit of a strategy game at first. You *have to optimize for getting the code committed*, implying *reviewed*. Start small (fix documentation, compiler warnings, spelling), since these changes are easiest to review and get committed. Don't underestimate the difference between "random patch from some guy" and "patch from that guy for that part of the tree he was looking at"---the difference is enormous, even if "that part of the tree he was looking at" was fixing a spelling mistake *which he sent in a patch for and got committed*. There's a strong social effect to being "that guy" instead of "some guy", but also, getting a spelling fix committed demonstrates that your patch is above a certain very low bar (but a bar nonetheless) of "not going to be annoying to review and commit" (e.g., not having to figure out that I need to pass something weird like `-p3` to git-apply in order to apply this patch, or be `cd`'d into a particular directory (git-format-patch avoids all these problems, btw)). As you get a foothold, you can grow larger. There are sometimes relatively mechanical changes that need to be made, but which are kind of tedious and so they go undone: these are good candidates for your "training wheels" phase (last paragraph was "tricycle") of more substantial patches which will teach you how to do incremental development (e.g., learning that "well while I'm here, I'll fix this trivial whitespace issue" is evil); if you need ideas, ping me. I promise you that once you have gotten a couple patches committed like that you will read this message you just sent and have a "what was I thinking" moment. -- Sean Silva On Thu, Nov 15, 2012 at 8: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? > > Thanks, > Greg > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >