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?
>
>> 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.
>
>> 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 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.
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-classe
>>>>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-classe
>>>>s-
>> >>in-python
>> >>
>> >> ----
>> >>
>>
Received on 2012-05-24 12:58:39 CEST