It makes sense to me that Apache try to curate the strong developer
communities that exist on GitHub. There is an ease of sending patches via
GitHub that is at odds with the process of, at the minimum, registering
for the dev list for a specific project and submitting a patch that way.
My goal here is to enable different communities, whether they are within
Apache or not, to contribute code to Apache projects. As long as the legal
stuff is covered, then I don't see a problem. The belief of "Community
Over Code" in my mind reflects this goal.
My answers in-line below.
On 5/24/12 1:28 PM, "Daniel Shahaf" <d.s_at_daniel.shahaf.name> wrote:
>Filip Maj wrote on Thu, May 24, 2012 at 03:57:51 -0700:
>> My answers in-line below.
>>
>> On 5/24/12 12:48 PM, "Daniel Shahaf" <d.s_at_daniel.shahaf.name> wrote:
>>
>> >(wearing both an infra hat and an svn hat...)
>> >
>> >Filip Maj wrote on Thu, May 24, 2012 at 03:22:19 -0700:
>> >> Without a doubt getting access to the project mirrors on GitHub is a
>> >> must-have. Setting up different teams on GitHub is trivial. Could
>>have a
>> >> "committers" team, and any other team deemed necessary. We can then
>>add
>> >> permissions such as ability to administer the github project to these
>> >> teams.
>> >>
>> >
>> >Are you aware of Apache's requirements here? Example: every commit
>>must
>> >generate an email notification. Can you grant people access to github
>> >in a manner that preserves this requirement?
>>
>> Yep. Every pull request sends an email to the dev list (as per below).
>>Any
>> other issues you foresee w.r.t. meeting Apache's requirements?
>>
>
>Read what I wrote again perhaps? It has nothing to do with pull requests.
Right, commits, not pull requests. This happens already. Adding
administrative rights to the github mirrors would not change the commit
method already in place. All commits go to the Apache git servers - the
GitHub projects are just mirrors, after all. Pull requests on github are
just an easy way to suggest patches. Committers would still review the
patch, discuss the patch, and then pull in the patch / merge it in, then
finally commit it back to the Apache git servers.
>
>> >
>> >> As for sending the patch, I don't see anything wrong with accepting a
>> >> patch via GitHub. I fail to see the difference between accepting a
>>patch
>> >> via e-mail on dev lists vs. doing so via GitHub. In fact, I would say
>> >>that
>> >> accepting the patch on GitHub is *easier* than any other approved
>>method
>> >> in Apache so far (that I've experienced). You can comment on specific
>> >> lines of code in a clearer fashion, keep track of changes to the
>>patch
>> >>(if
>> >> necessary) also very cleanly, in a timeline sort of fashion, where
>> >>changes
>> >> to the patch as well as overall comments are chronologically ordered.
>> >>Very
>> >> easy to see how a patch evolves.
>> >>
>> >
>> >We have a different process, that also allows us to comment on specific
>> >lines of the patch. It has worked well for us for the last 10 years.
>>
>> Sweet, so then it should be no problem to have an analogous process
>>within
>> GitHub.
>>
>
>Wrong. It is not possible to port our existing process to github.
OK, I am not familiar with your process so I may be missing something.
That said, if all we're talking about is commenting on lines of code in a
patch, then yes, GitHub does offer this ability.
>
>> >
>> >> As a current committer on an incubating project that went from a
>> >> GitHub-based project to an Apache project (incubator-apache-cordova),
>> >>this
>> >> issue resounds very strongly in me. I would love to help out in any
>>way
>> >>I
>> >> can to get this figured out.
>> >>
>> >
>> >What issue?
>>
>> "We" the committers have no way to administer the project on GitHub.
>>Like
>> it was mentioned below, changing the description tagline (simpler/less
>> important). More important for me would be the ability to close pull
>> requests. Right now they sort of hang out in limbo. The only way to
>> "close" them is to merge the patch into the mainline and wait for the
>> mirror to update. My understanding is the mirrors update every 24 hours.
>> Not sure why we can't integrate git hooks to update the mirror on every
>> commit. Why this becomes even more important is if you rebase the patch
>>in
>> instead of merging. This changes the SHA of the commits and thus GitHub
>>no
>> longer recognizes the patch commits as relating to the pull request - so
>> they exist forever.
>>
>
>There are one or two outstanding JIRAs about pull requests. Feel free
>to join the discussion --- on the infra lists, please.
>
>It's this one:
>13218 L 11Nov24,18:36 Henri Yandell (Cr (0.7K) [jira] [Created]
>(INFRA-4152) Can't close GitHub pull requests
>
>Also in the neighbourhood:
>11983 L 12Jan14,00:56 Jukka Zitting (Cr (0.9K) [jira] [Created]
>(INFRA-4331) Git pull request notifications broken
>13203 L 12Apr28,19:30 Dave Cottlehuber (1.5K) [jira] [Created]
>(INFRA-4726) CouchDB Github mirror does not allow ASF committers wit
>13395 L 12Apr03,22:08 Marvin Humphrey ( (0.8K) [jira] [Created]
>(INFRA-4651) Add SHA sums to Github pull request notifications
Thanks for pointing these out, cheers.
>
>
>> >There are several git-related tasks in the INFRA issue
>> >tracker (https://issues.apache.org/jira/browse/INFRA), including one
>> >about allowing PMC's to interact with pull requests (in a manner other
>> >than 'accept them unmodified'). If you want to help, just drop a line
>> >to the infra list.
>>
>> Awesome, I will search for "git" in the JIRA and help out where I can.
>>I'm
>> already on the infra-dev list and must have missed the discussion about
>> this issue on there.
>>
>
>I don't recall what list the discussion was on.
>
>> Cheers,
>> Fil Maj
>>
>> >
>> >Daniel
>> >
>> >> Cheers,
>> >> Fil Maj
>> >>
>> >> On 5/24/12 10:54 AM, "Greg Stein" <gstein_at_gmail.com> wrote:
>> >>
>> >> >Git people,
>> >> >
>> >> >The community is discussing what to do about this particular
>>approach
>> >> >for sending a patch (we have a defined and published method for
>> >> >sending a patch to our community). That is a separate thread, but
>> >> >pending that... I have a separate meta/infra issue for you.
>> >> >
>> >> >The Subversion PMC does not seem to have access to manage our
>>presence
>> >> >on GitHub, yet people seem to believe it is a viable approach to
>>send
>> >> >us patches. At a minimum, the PMC needs a way to manage our presence
>> >> >on GitHub: the description, the readme, pull requests, etc.
>> >> >
>> >> >I doubt that the PMC and community wants to shut this down, but *we*
>> >> >are the ones to define our presence to the larger community. The
>> >> >Subversion PMC is the group to manage pull requests, and other
>>aspects
>> >> >of our project. In short, this GitHub repository is representing
>> >> >"Apache Subversion" without the PMC providing any actual oversight
>>or
>> >> >any mechanism to manage it.
>> >> >
>> >> >Please let us know our options for managing our GitHub presence.
>> >> >
>> >> >Thanks,
>> >> >Greg Stein
>> >> >VP, Apache Subversion
>> >> >
>> >> >On Thu, May 24, 2012 at 4:12 AM, Git at Apache <git_at_git.apache.org>
>> >>wrote:
>> >> >> GitHub user techtonik opened a pull request:
>> >> >>
>> >> >> https://github.com/apache/subversion/pull/1
>> >> >>
>> >> >> port to new style classes -
>> >> >>http://stackoverflow.com/questions/54867/old...
>> >> >>
>> >> >>
>> >>
>>
>>>>>>http://stackoverflow.com/questions/54867/old-style-and-new-style-clas
>>>>>>se
>> >>>>s-
>> >> >>in-python
>> >> >>
>> >> >> You can merge this pull request into a Git repository by running:
>> >> >>
>> >> >> $ git pull https://github.com/techtonik/subversion patch-1
>> >> >>
>> >> >> Alternatively you can review and apply these changes as the patch
>>at:
>> >> >>
>> >> >> https://github.com/apache/subversion/pull/1.patch
>> >> >>
>> >> >> ----
>> >> >> commit cb3fa71cceef1060b1074299dbdbd4fcf8fd6869
>> >> >> Author: anatoly techtonik <techtonik_at_gmail.com>
>> >> >> Date: 2012-05-24T01:12:03-07:00
>> >> >>
>> >> >> port to new style classes -
>> >>
>>
>>>>>>http://stackoverflow.com/questions/54867/old-style-and-new-style-clas
>>>>>>se
>> >>>>s-
>> >> >>in-python
>> >> >>
>> >> >> ----
>> >> >>
>> >>
>>
Received on 2012-05-24 13:58:58 CEST