You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Git at Apache <gi...@git.apache.org> on 2012/05/24 10:12:21 UTC
subversion pull request: port to new style classes - http://stackoverflow.c...
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-classes-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 <te...@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-classes-in-python
----
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jukka Zitting wrote on Thu, May 24, 2012 at 13:39:48 +0200:
> The GitHub pull request notification you saw on dev@subversion, is a
> result of our work to better integrate GitHub workflows with those at
> Apache. The idea here is to send the issue to dev@ from where the
> project community can deal with it in whichever way it prefers, for
> example by telling the contributor to use other channels, by filing a
> bug for the issue, or by simply directly applying the contributed
> patch.
>
> Currently the pull request notification doesn't come with a full diff,
> but we can add that if desired.
Subversion has a specific process for incoming patches: we expect
patches to contain at least a log message (written according to
<http://subversion.apache.org/docs/community-guide/conventions#log-messages>)
and a unidiff. We also expect to be discussed --- this can take the
form of a "cover letter" in the submission, or of a normal dev@ thread
before diving into the code.
Can the git.a.o tooling support our workflow?
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jukka Zitting wrote on Thu, May 24, 2012 at 13:39:48 +0200:
> The GitHub pull request notification you saw on dev@subversion, is a
> result of our work to better integrate GitHub workflows with those at
> Apache. The idea here is to send the issue to dev@ from where the
> project community can deal with it in whichever way it prefers, for
> example by telling the contributor to use other channels, by filing a
> bug for the issue, or by simply directly applying the contributed
> patch.
>
> Currently the pull request notification doesn't come with a full diff,
> but we can add that if desired.
Subversion has a specific process for incoming patches: we expect
patches to contain at least a log message (written according to
<http://subversion.apache.org/docs/community-guide/conventions#log-messages>)
and a unidiff. We also expect to be discussed --- this can take the
form of a "cover letter" in the submission, or of a normal dev@ thread
before diving into the code.
Can the git.a.o tooling support our workflow?
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Jukka Zitting <ju...@apache.org>.
Hi,
On Thu, May 24, 2012 at 10:54 AM, Greg Stein <gs...@gmail.com> wrote:
> 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.
We have quite a bit of control over that, though access to the
github.com/apache settings is limited to just a few admins (currently
me, Gavin and Tony). Do you already have specific changes that you'd
like implemented?
> 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.
As mentioned by Daniel, the Git mirror was created as a response to
http://markmail.org/message/gachaz3dcxukrpph. By default all
git.apache.org mirrors also show up on github.com/apache, but we can
change that per-project if needed.
The GitHub pull request notification you saw on dev@subversion, is a
result of our work to better integrate GitHub workflows with those at
Apache. The idea here is to send the issue to dev@ from where the
project community can deal with it in whichever way it prefers, for
example by telling the contributor to use other channels, by filing a
bug for the issue, or by simply directly applying the contributed
patch.
Currently the pull request notification doesn't come with a full diff,
but we can add that if desired.
> Please let us know our options for managing our GitHub presence.
Just let us know what you want changed and we'll take care of it.
BR,
Jukka Zitting
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Filip Maj wrote on Thu, May 24, 2012 at 04:58:15 -0700:
> 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....@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....@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.
Okay, if people can have admin rights on github without having commit
rights, then my concern is addressed.
I am quite surprised that it is this way, though: in my country, people
who have admin rights also have write rights...
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Filip Maj wrote on Thu, May 24, 2012 at 04:58:15 -0700:
> 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....@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....@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.
Okay, if people can have admin rights on github without having commit
rights, then my concern is addressed.
I am quite surprised that it is this way, though: in my country, people
who have admin rights also have write rights...
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
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....@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....@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" <gs...@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 <gi...@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 <te...@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
>> >> >>
>> >> >> ----
>> >> >>
>> >>
>>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
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....@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....@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" <gs...@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 <gi...@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 <te...@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
>> >> >>
>> >> >> ----
>> >> >>
>> >>
>>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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....@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.
> >
> >> 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.
> >
> >> 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
> >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" <gs...@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 <gi...@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 <te...@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
> >> >>
> >> >> ----
> >> >>
> >>
>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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....@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.
> >
> >> 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.
> >
> >> 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
> >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" <gs...@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 <gi...@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 <te...@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
> >> >>
> >> >> ----
> >> >>
> >>
>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
My answers in-line below.
On 5/24/12 12:48 PM, "Daniel Shahaf" <d....@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" <gs...@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 <gi...@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 <te...@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
>> >>
>> >> ----
>> >>
>>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
My answers in-line below.
On 5/24/12 12:48 PM, "Daniel Shahaf" <d....@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" <gs...@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 <gi...@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 <te...@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
>> >>
>> >> ----
>> >>
>>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
(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?
> 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.
> 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? 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.
Daniel
> Cheers,
> Fil Maj
>
> On 5/24/12 10:54 AM, "Greg Stein" <gs...@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 <gi...@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-classes-
> >>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 <te...@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-classes-
> >>in-python
> >>
> >> ----
> >>
>
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Daniel Shahaf <da...@apache.org>.
On Thu, May 24, 2012 at 04:54:45AM -0400, Greg Stein wrote:
> In short, this GitHub repository is representing "Apache Subversion" without
> the PMC providing any actual oversight or any mechanism to manage it.
Greg made a good point on IRC: PMC's should at least be _made aware_ that a
github mirror for them was created, as that is another site/interface that
they need to manage/oversee.
In this instance, the mirror was created by Paul Querna --- a long-time ASF
member, yes, but the request was not made on behalf of the Subversion PMC or
even with its knowledge.
Daniel
(infra hat on I'd like to remind everybody that when a JIRA ticket is filed,
the authority of the person filing it to request what they did ought to be
ascertained before the ticket is acted upon.)
RE: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Greg Stein <gs...@gmail.com>.
On May 24, 2012 7:55 AM, "Gavin McDonald" <ga...@16degrees.com.au> wrote:
>
>
>
> > -----Original Message-----
> > From: jukka.zitting@gmail.com [mailto:jukka.zitting@gmail.com] On Behalf
> > Of Jukka Zitting
> > Sent: Thursday, 24 May 2012 9:12 PM
> > To: gavin@16degrees.com.au
> > Cc: infrastructure-dev@apache.org; Git at Apache; davisp@apache.org;
> > dev@subversion.apache.org
> > Subject: Re: subversion pull request: port to new style classes -
> > http://stackoverflow.c...
> >
> > Hi,
> >
> > On Thu, May 24, 2012 at 1:38 PM, Gavin McDonald
> > <ga...@16degrees.com.au> wrote:
> > > Ive created a 'Apache Subversion' "Team" which can
> 'push,pull,administer'
> > > the apache/subversion repo.
> >
> > Please don't!
> >
> > The GitHub mirrors are strictly read-only for a purpose. We don't want
> > development to diverge between the official Apache repositories and
those
> > at GitHub.
>
> Ok, reverted.
>
> I thought we could trust Greg to be admin like on the Subversion repo, but
> ok.
hehe... I can be trusted, but we don't need push privs, as Daniel and Jukka
noted.
I'm sitting on a plane, and am about to go dark for 5.5 hours. We'll see
where we are then. At a minimum, I'll disable Fil, as he is not part of the
svn project.
Thanks for the access Gav!
-g
RE: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Greg Stein <gs...@gmail.com>.
On May 24, 2012 7:55 AM, "Gavin McDonald" <ga...@16degrees.com.au> wrote:
>
>
>
> > -----Original Message-----
> > From: jukka.zitting@gmail.com [mailto:jukka.zitting@gmail.com] On Behalf
> > Of Jukka Zitting
> > Sent: Thursday, 24 May 2012 9:12 PM
> > To: gavin@16degrees.com.au
> > Cc: infrastructure-dev@apache.org; Git at Apache; davisp@apache.org;
> > dev@subversion.apache.org
> > Subject: Re: subversion pull request: port to new style classes -
> > http://stackoverflow.c...
> >
> > Hi,
> >
> > On Thu, May 24, 2012 at 1:38 PM, Gavin McDonald
> > <ga...@16degrees.com.au> wrote:
> > > Ive created a 'Apache Subversion' "Team" which can
> 'push,pull,administer'
> > > the apache/subversion repo.
> >
> > Please don't!
> >
> > The GitHub mirrors are strictly read-only for a purpose. We don't want
> > development to diverge between the official Apache repositories and
those
> > at GitHub.
>
> Ok, reverted.
>
> I thought we could trust Greg to be admin like on the Subversion repo, but
> ok.
hehe... I can be trusted, but we don't need push privs, as Daniel and Jukka
noted.
I'm sitting on a plane, and am about to go dark for 5.5 hours. We'll see
where we are then. At a minimum, I'll disable Fil, as he is not part of the
svn project.
Thanks for the access Gav!
-g
RE: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: jukka.zitting@gmail.com [mailto:jukka.zitting@gmail.com] On Behalf
> Of Jukka Zitting
> Sent: Thursday, 24 May 2012 9:12 PM
> To: gavin@16degrees.com.au
> Cc: infrastructure-dev@apache.org; Git at Apache; davisp@apache.org;
> dev@subversion.apache.org
> Subject: Re: subversion pull request: port to new style classes -
> http://stackoverflow.c...
>
> Hi,
>
> On Thu, May 24, 2012 at 1:38 PM, Gavin McDonald
> <ga...@16degrees.com.au> wrote:
> > Ive created a 'Apache Subversion' "Team" which can
'push,pull,administer'
> > the apache/subversion repo.
>
> Please don't!
>
> The GitHub mirrors are strictly read-only for a purpose. We don't want
> development to diverge between the official Apache repositories and those
> at GitHub.
Ok, reverted.
I thought we could trust Greg to be admin like on the Subversion repo, but
ok.
Gav...
>
> BR,
>
> Jukka Zitting
RE: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Gavin McDonald <ga...@16degrees.com.au>.
> -----Original Message-----
> From: jukka.zitting@gmail.com [mailto:jukka.zitting@gmail.com] On Behalf
> Of Jukka Zitting
> Sent: Thursday, 24 May 2012 9:12 PM
> To: gavin@16degrees.com.au
> Cc: infrastructure-dev@apache.org; Git at Apache; davisp@apache.org;
> dev@subversion.apache.org
> Subject: Re: subversion pull request: port to new style classes -
> http://stackoverflow.c...
>
> Hi,
>
> On Thu, May 24, 2012 at 1:38 PM, Gavin McDonald
> <ga...@16degrees.com.au> wrote:
> > Ive created a 'Apache Subversion' "Team" which can
'push,pull,administer'
> > the apache/subversion repo.
>
> Please don't!
>
> The GitHub mirrors are strictly read-only for a purpose. We don't want
> development to diverge between the official Apache repositories and those
> at GitHub.
Ok, reverted.
I thought we could trust Greg to be admin like on the Subversion repo, but
ok.
Gav...
>
> BR,
>
> Jukka Zitting
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Jukka Zitting <ju...@apache.org>.
Hi,
On Thu, May 24, 2012 at 1:38 PM, Gavin McDonald <ga...@16degrees.com.au> wrote:
> Ive created a 'Apache Subversion' "Team" which can 'push,pull,administer'
> the apache/subversion repo.
Please don't!
The GitHub mirrors are strictly read-only for a purpose. We don't want
development to diverge between the official Apache repositories and
those at GitHub.
BR,
Jukka Zitting
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Jukka Zitting <ju...@apache.org>.
Hi,
On Thu, May 24, 2012 at 1:38 PM, Gavin McDonald <ga...@16degrees.com.au> wrote:
> Ive created a 'Apache Subversion' "Team" which can 'push,pull,administer'
> the apache/subversion repo.
Please don't!
The GitHub mirrors are strictly read-only for a purpose. We don't want
development to diverge between the official Apache repositories and
those at GitHub.
BR,
Jukka Zitting
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
I think all we want is the administration rights, but GitHub fails here in
that you can't separate admin vs. push rights.
Sigh.
On 5/24/12 1:53 PM, "Daniel Shahaf" <d....@daniel.shahaf.name> wrote:
>Gavin McDonald wrote on Thu, May 24, 2012 at 21:08:43 +0930:
>> As per suggestion,
>>
>> Ive created a 'Apache Subversion' "Team" which can
>>'push,pull,administer'
>> the apache/subversion repo.
>>
>
>-1 on push rights (svn hat). The canonical place for new code to enter
>the Subversion codebase is https://svn.apache.org/repos/asf/subversion/.
>Please revert.
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
I think all we want is the administration rights, but GitHub fails here in
that you can't separate admin vs. push rights.
Sigh.
On 5/24/12 1:53 PM, "Daniel Shahaf" <d....@daniel.shahaf.name> wrote:
>Gavin McDonald wrote on Thu, May 24, 2012 at 21:08:43 +0930:
>> As per suggestion,
>>
>> Ive created a 'Apache Subversion' "Team" which can
>>'push,pull,administer'
>> the apache/subversion repo.
>>
>
>-1 on push rights (svn hat). The canonical place for new code to enter
>the Subversion codebase is https://svn.apache.org/repos/asf/subversion/.
>Please revert.
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gavin McDonald wrote on Thu, May 24, 2012 at 21:08:43 +0930:
> As per suggestion,
>
> Ive created a 'Apache Subversion' "Team" which can 'push,pull,administer'
> the apache/subversion repo.
>
-1 on push rights (svn hat). The canonical place for new code to enter
the Subversion codebase is https://svn.apache.org/repos/asf/subversion/.
Please revert.
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Gavin McDonald wrote on Thu, May 24, 2012 at 21:08:43 +0930:
> As per suggestion,
>
> Ive created a 'Apache Subversion' "Team" which can 'push,pull,administer'
> the apache/subversion repo.
>
-1 on push rights (svn hat). The canonical place for new code to enter
the Subversion codebase is https://svn.apache.org/repos/asf/subversion/.
Please revert.
RE: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Gavin McDonald <ga...@16degrees.com.au>.
As per suggestion,
Ive created a 'Apache Subversion' "Team" which can 'push,pull,administer'
the apache/subversion repo.
Consider this a test at this point, also consider it committer priviliges
that have same rules as for svn.
I've added gstein and filmaj to this team.
Thanks
Gav...
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Thursday, 24 May 2012 6:25 PM
> To: Git at Apache; infrastructure-dev@apache.org; Jukka Zitting;
> davisp@apache.org
> Cc: dev@subversion.apache.org
> Subject: Re: subversion pull request: port to new style classes -
> http://stackoverflow.c...
>
> 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 <gi...@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-class
> > es-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 <te...@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-class
> > es-in-python
> >
> > ----
> >
RE: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Gavin McDonald <ga...@16degrees.com.au>.
As per suggestion,
Ive created a 'Apache Subversion' "Team" which can 'push,pull,administer'
the apache/subversion repo.
Consider this a test at this point, also consider it committer priviliges
that have same rules as for svn.
I've added gstein and filmaj to this team.
Thanks
Gav...
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: Thursday, 24 May 2012 6:25 PM
> To: Git at Apache; infrastructure-dev@apache.org; Jukka Zitting;
> davisp@apache.org
> Cc: dev@subversion.apache.org
> Subject: Re: subversion pull request: port to new style classes -
> http://stackoverflow.c...
>
> 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 <gi...@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-class
> > es-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 <te...@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-class
> > es-in-python
> >
> > ----
> >
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Paul Davis <pa...@gmail.com>.
On Thu, May 24, 2012 at 3:54 AM, Greg Stein <gs...@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 <gi...@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-classes-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 <te...@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-classes-in-python
>>
>> ----
>>
Greg,
As I see it, there are basically two main parts to this question.
First is the ability to allow PMC members (or all committers?) for a
given project to manage various parts of the GitHub repository. As far
as I'm aware the end result is a forgone conclusion and the only
sticking point is the underlying infrastructure to make it happen. My
basic goal here is to have a script that'll query ldap to get the list
of authorized people and mirror that using the "GitHub Organization
Teams" API. That should allow us to have a fairly natural mapping of
ASF privileges to GH privileges.
The second half is in monitoring interaction with the GH account from
dev@ mailing lists. Jukka has done some initial work to at least make
projects aware of their PR's but as people are starting to see they're
still a bit lacking because of things like continued discussion on the
PR. There's more to the PR API that we can use to mirror these bits of
discussion over to the dev@ list but that type of integration is only
in a single direction. Ie, it should be just a bit of work to echo all
GH discussion to the dev@ lists, but the follow up question is how we
might respond to people on GH that aren't necessarily subscribed to
dev@. That might just be a matter of including links back to GH where
people can respond, or perhaps figuring out GH's email reply system.
In the end I also think this is mostly a technical issue as the
process/meta issue is pretty clear that it all needs to go through
dev@ so its just a matter of making that happen in a way that people
agree upon (or making it configurable to make projects happy).
Paul Davis
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Paul Davis <pa...@gmail.com>.
On Thu, May 24, 2012 at 3:54 AM, Greg Stein <gs...@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 <gi...@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-classes-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 <te...@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-classes-in-python
>>
>> ----
>>
Greg,
As I see it, there are basically two main parts to this question.
First is the ability to allow PMC members (or all committers?) for a
given project to manage various parts of the GitHub repository. As far
as I'm aware the end result is a forgone conclusion and the only
sticking point is the underlying infrastructure to make it happen. My
basic goal here is to have a script that'll query ldap to get the list
of authorized people and mirror that using the "GitHub Organization
Teams" API. That should allow us to have a fairly natural mapping of
ASF privileges to GH privileges.
The second half is in monitoring interaction with the GH account from
dev@ mailing lists. Jukka has done some initial work to at least make
projects aware of their PR's but as people are starting to see they're
still a bit lacking because of things like continued discussion on the
PR. There's more to the PR API that we can use to mirror these bits of
discussion over to the dev@ list but that type of integration is only
in a single direction. Ie, it should be just a bit of work to echo all
GH discussion to the dev@ lists, but the follow up question is how we
might respond to people on GH that aren't necessarily subscribed to
dev@. That might just be a matter of including links back to GH where
people can respond, or perhaps figuring out GH's email reply system.
In the end I also think this is mostly a technical issue as the
process/meta issue is pretty clear that it all needs to go through
dev@ so its just a matter of making that happen in a way that people
agree upon (or making it configurable to make projects happy).
Paul Davis
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Daniel Shahaf <da...@apache.org>.
On Thu, May 24, 2012 at 04:54:45AM -0400, Greg Stein wrote:
> In short, this GitHub repository is representing "Apache Subversion" without
> the PMC providing any actual oversight or any mechanism to manage it.
Greg made a good point on IRC: PMC's should at least be _made aware_ that a
github mirror for them was created, as that is another site/interface that
they need to manage/oversee.
In this instance, the mirror was created by Paul Querna --- a long-time ASF
member, yes, but the request was not made on behalf of the Subversion PMC or
even with its knowledge.
Daniel
(infra hat on I'd like to remind everybody that when a JIRA ticket is filed,
the authority of the person filing it to request what they did ought to be
ascertained before the ticket is acted upon.)
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Jukka Zitting <ju...@apache.org>.
Hi,
On Thu, May 24, 2012 at 10:54 AM, Greg Stein <gs...@gmail.com> wrote:
> 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.
We have quite a bit of control over that, though access to the
github.com/apache settings is limited to just a few admins (currently
me, Gavin and Tony). Do you already have specific changes that you'd
like implemented?
> 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.
As mentioned by Daniel, the Git mirror was created as a response to
http://markmail.org/message/gachaz3dcxukrpph. By default all
git.apache.org mirrors also show up on github.com/apache, but we can
change that per-project if needed.
The GitHub pull request notification you saw on dev@subversion, is a
result of our work to better integrate GitHub workflows with those at
Apache. The idea here is to send the issue to dev@ from where the
project community can deal with it in whichever way it prefers, for
example by telling the contributor to use other channels, by filing a
bug for the issue, or by simply directly applying the contributed
patch.
Currently the pull request notification doesn't come with a full diff,
but we can add that if desired.
> Please let us know our options for managing our GitHub presence.
Just let us know what you want changed and we'll take care of it.
BR,
Jukka Zitting
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
(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?
> 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.
> 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? 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.
Daniel
> Cheers,
> Fil Maj
>
> On 5/24/12 10:54 AM, "Greg Stein" <gs...@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 <gi...@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-classes-
> >>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 <te...@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-classes-
> >>in-python
> >>
> >> ----
> >>
>
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Philip Martin <ph...@wandisco.com>.
Filip Maj <fi...@adobe.com> writes:
> 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.
>
> 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.
>
> 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.
I had a look at incubator-callback-dev and I didn't see much discussion
about pull requests or patches. I did find one:
http://mail-archives.apache.org/mod_mbox/incubator-callback-dev/201203.mbox/%3CCADjNb+n-_q9Zo602zWAmpEprVfox5FcwDx3Rc__fBt_41ez2Yg@mail.gmail.com%3E
which leads to
https://github.com/apache/incubator-cordova-mobile-spec/pull/1
The discussion about the patch appears to be split across the dev list
and the github site.
The Subversion project discusses patches on dev@subversion.a.o. For me
it is much simpler if the patch appears in my email client. When I want
to comment on a patch it's available to quote and the discussion stays
in one place archived on the dev list. Your work flow appears to push
some/all patch discussion off the dev list and onto github.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Philip Martin <ph...@wandisco.com>.
Filip Maj <fi...@adobe.com> writes:
> 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.
>
> 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.
>
> 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.
I had a look at incubator-callback-dev and I didn't see much discussion
about pull requests or patches. I did find one:
http://mail-archives.apache.org/mod_mbox/incubator-callback-dev/201203.mbox/%3CCADjNb+n-_q9Zo602zWAmpEprVfox5FcwDx3Rc__fBt_41ez2Yg@mail.gmail.com%3E
which leads to
https://github.com/apache/incubator-cordova-mobile-spec/pull/1
The discussion about the patch appears to be split across the dev list
and the github site.
The Subversion project discusses patches on dev@subversion.a.o. For me
it is much simpler if the patch appears in my email client. When I want
to comment on a patch it's available to quote and the discussion stays
in one place archived on the dev list. Your work flow appears to push
some/all patch discussion off the dev list and onto github.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
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.
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.
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.
Cheers,
Fil Maj
On 5/24/12 10:54 AM, "Greg Stein" <gs...@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 <gi...@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-classes-
>>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 <te...@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-classes-
>>in-python
>>
>> ----
>>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Filip Maj <fi...@adobe.com>.
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.
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.
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.
Cheers,
Fil Maj
On 5/24/12 10:54 AM, "Greg Stein" <gs...@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 <gi...@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-classes-
>>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 <te...@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-classes-
>>in-python
>>
>> ----
>>
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Greg Stein <gs...@gmail.com>.
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 <gi...@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-classes-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 <te...@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-classes-in-python
>
> ----
>
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by anatoly techtonik <te...@gmail.com>.
On Thu, May 24, 2012 at 6:03 PM, Stefan Sperling <st...@elego.de> wrote:
> On Thu, May 24, 2012 at 05:37:17PM +0300, anatoly techtonik wrote:
>> Hi Julian,
>>
>> Thanks for the notice. The pull request was premature (I actually made
>> by editing the file from GitHub web interface) - there are more
>> patches to come, but as soon as they are ready I'll send an update to
>> this thread.
>
> Please start a new thread to submit your updated patch,
> with [PATCH] in the subject line, as described here:
> http://subversion.apache.org/docs/community-guide/general.html#patches
>
> This thread has turned into a discussion about whether the
> Subversion project should handle github pull request. Let's
> not mix this with a technical discussion about your patch.
>
> Thanks!
Sure. No problem.
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 24, 2012 at 05:37:17PM +0300, anatoly techtonik wrote:
> Hi Julian,
>
> Thanks for the notice. The pull request was premature (I actually made
> by editing the file from GitHub web interface) - there are more
> patches to come, but as soon as they are ready I'll send an update to
> this thread.
Please start a new thread to submit your updated patch,
with [PATCH] in the subject line, as described here:
http://subversion.apache.org/docs/community-guide/general.html#patches
This thread has turned into a discussion about whether the
Subversion project should handle github pull request. Let's
not mix this with a technical discussion about your patch.
Thanks!
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by anatoly techtonik <te...@gmail.com>.
Hi Julian,
Thanks for the notice. The pull request was premature (I actually made
by editing the file from GitHub web interface) - there are more
patches to come, but as soon as they are ready I'll send an update to
this thread. Feel free to comment separate revisions in the meanwhile.
https://github.com/apache/subversion/pull/1 - note that the title now
is "svnlook.py: Make it usable as a library"
--
anatoly t.
On Thu, May 24, 2012 at 12:59 PM, Julian Foad
<ju...@btopenworld.com> wrote:
> What I said there is my personal opinion; not necessarily that of the Subversion community.
>
> - Julian
>
>
>
> I (Julian Foad) wrote:
>>
>> Hi Anatoly.
>>
>> The Subversion team has just received this pull request from you. The current
>> patch submission process is here
>> <http://subversion.apache.org/docs/community-guide/general.html#patches>,
>> and in particular we would require an email on this mailing list and a log
>> message to explain the patch. The ability to address GitHub pull-requests to
>> the Subversion development team has only just been enabled for experimental use
>> and is not yet a recognized channel for patch submissions.
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Julian Foad <ju...@btopenworld.com>.
What I said there is my personal opinion; not necessarily that of the Subversion community.
- Julian
I (Julian Foad) wrote:
>
> Hi Anatoly.
>
> The Subversion team has just received this pull request from you. The current
> patch submission process is here
> <http://subversion.apache.org/docs/community-guide/general.html#patches>,
> and in particular we would require an email on this mailing list and a log
> message to explain the patch. The ability to address GitHub pull-requests to
> the Subversion development team has only just been enabled for experimental use
> and is not yet a recognized channel for patch submissions.
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Julian Foad <ju...@btopenworld.com>.
Hi Anatoly.
The Subversion team has just received this pull request from you. The current patch submission process is here <http://subversion.apache.org/docs/community-guide/general.html#patches>, and in particular we would require an email on this mailing list and a log message to explain the patch. The ability to address GitHub pull-requests to the Subversion development team has only just been enabled for experimental use and is not yet a recognized channel for patch submissions.
Regards,
- Julian
----- Original Message -----
> From: Git at Apache <gi...@git.apache.org>
> To: dev@subversion.apache.org
> Cc:
> Sent: Thursday, 24 May 2012, 9:12
> Subject: subversion pull request: port to new style classes - http://stackoverflow.c...
>
> 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-classes-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 <te...@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-classes-in-python
>
> ----
>
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Greg Stein <gs...@gmail.com>.
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 <gi...@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-classes-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 <te...@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-classes-in-python
>
> ----
>
Re: subversion pull request: port to new style classes -
http://stackoverflow.c...
Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 24, 2012 at 11:32:42AM +0100, Philip Martin wrote:
> I don't like it. The email doesn't contain the patch or the log
> message. The email has the address of the patch author in the body and
> not in the headers. Patches should be visible and discussed on dev.
>
> Since you mention it: I think submitting patches as "attachments" through
> subversion.tigris.org is broken as well. Getting an email telling me a
> patch has been added to an issue but not sending me the patch itself is
> unhelpful.
+1
Email is my primary interface to the community and it works
well for me. Keeping track of what happens at external websites
people use to manage their code is an extra burden for me. I want to
review patches and log messages in my mail reader and/or editor,
not in a web browser. And I want to be able to follow patch submission
reviews made by others, without tracking separate channels.
We have a saying that "if it didn't happen on dev@, it didn't happen".
I would appreciate if that applied to patch submissions, too.
The above is not a statement on how other ASF projects should
handle patch submissions. Each project should define their own
way of handing patch submissions. Patch submitters should provide
patches in a way the project is prepared to handle.
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Philip Martin <ph...@wandisco.com>.
Greg Stein <gs...@gmail.com> writes:
> My feeling is: this is not how we want to accept patches. This
> approach is completely disconnected from our community. How do we talk
> to the person providing the change? How do we ask for modifications?
> How to interact?
>
> But even larger: our goal is to get people *involved* in our
> community. There isn't any obvious way to get 'techtonik' brought into
> our community unless they come to the dev@ list.
>
> That said... we *do* accept patches via the issue tracker on
> subversion.tigris.org. Are we ready to accept patches through a
> separate channel? Personally, I'm not ready to say "hey, any channel
> on the planet is fine. please... feel free! devise new channels! we
> are willing to review 100 channels for incoming patches!"
>
> I like GitHub. It is a very, very well-done site. But I'm not ready to
> say that it is a viable mechanism for people to deliver patches. My
> preference is for those to arrive here on dev@, where we can interact
> with the person. Not as some drive-by, fait accompli.
>
> Thoughts?
I don't like it. The email doesn't contain the patch or the log
message. The email has the address of the patch author in the body and
not in the headers. Patches should be visible and discussed on dev.
Since you mention it: I think submitting patches as "attachments" through
subversion.tigris.org is broken as well. Getting an email telling me a
patch has been added to an issue but not sending me the patch itself is
unhelpful.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Stein wrote:
> I moderated this through, in order to start a discussion.
>
> My feeling is: this is not how we want to accept patches. This
> approach is completely disconnected from our community. How do we talk
> to the person providing the change? How do we ask for modifications?
> How to interact?
About this particular pull request: The patch just makes two apparently unrelated trivial changes in one of our example scripts. It looks like it could easily be somebody just experimenting with using Git -- maybe they pressed the "pull request" button by mistake. I sent a query, pointing out our current submission procedure is currently required.
> But even larger: our goal is to get people *involved* in our
> community. There isn't any obvious way to get 'techtonik' brought into
> our community unless they come to the dev@ list.
About the principle of accepting
pull requests: At this time, I'd say unquestionably a dev-list
presentation is required. But I'd be open to suggestions of how we can start to
use the GitHub channel as part of our submission process as well, if we
want to.
- Julian
> That said... we *do* accept patches via the issue tracker on
> subversion.tigris.org. Are we ready to accept patches through a
> separate channel? Personally, I'm not ready to say "hey, any channel
> on the planet is fine. please... feel free! devise new channels! we
> are willing to review 100 channels for incoming patches!"
>
> I like GitHub. It is a very, very well-done site. But I'm not ready to
> say that it is a viable mechanism for people to deliver patches. My
> preference is for those to arrive here on dev@, where we can interact
> with the person. Not as some drive-by, fait accompli.
>
> Thoughts?
> -g
>
>On Thu, May 24, 2012 at 4:12 AM, Git at Apache <gi...@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...
[...]
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Blair Zajac <bl...@orcaware.com>.
On 05/24/2012 01:32 AM, Greg Stein wrote:
> Hey all,
>
> I moderated this through, in order to start a discussion.
>
> My feeling is: this is not how we want to accept patches. This
> approach is completely disconnected from our community. How do we talk
> to the person providing the change? How do we ask for modifications?
> How to interact?
As someone who spends more time coding and deploying three-tier systems
dependent upon a large number of different projects (Scala, Guava,
Spring, Boost, Python, Ice, etc) than working on svn (except when we run
into an issue with svn itself ;) ) I appreciate the ease to quickly get
a patch into a project I'm dependent upon. I prefer to submit patches
than maintain private copies of upstream code. So I like the idea that
people can do a small amount of work and get it into the project, even
if it's as tiny as documentation patches when I'm reading the project's
docs.
I care to try to follow the project's coding conventions and log
messages, but that's because I've been trained in this project and know
that projects can be sensitive to that. So I can see this being an
issue for drive-by patches.
> But even larger: our goal is to get people *involved* in our
> community. There isn't any obvious way to get 'techtonik' brought into
> our community unless they come to the dev@ list.
I think that's a good goal, but people don't want to be turned off by a
lot of process in accepting a patch either.
> That said... we *do* accept patches via the issue tracker on
> subversion.tigris.org. Are we ready to accept patches through a
> separate channel? Personally, I'm not ready to say "hey, any channel
> on the planet is fine. please... feel free! devise new channels! we
> are willing to review 100 channels for incoming patches!"
>
> I like GitHub. It is a very, very well-done site. But I'm not ready to
> say that it is a viable mechanism for people to deliver patches. My
> preference is for those to arrive here on dev@, where we can interact
> with the person. Not as some drive-by, fait accompli.
I think that's too hard. I would rather accept work from somebody who
doesn't have the goal of joining Subversion then not getting the work at
all. Many of the projects I've contributed to was work to get done what
I needed for my projects, but that still helped the open-source project
that I was using over all. I don't have the time to join every project
I use.
Blair
Re: subversion pull request: port to new style classes - http://stackoverflow.c...
Posted by Greg Stein <gs...@gmail.com>.
Hey all,
I moderated this through, in order to start a discussion.
My feeling is: this is not how we want to accept patches. This
approach is completely disconnected from our community. How do we talk
to the person providing the change? How do we ask for modifications?
How to interact?
But even larger: our goal is to get people *involved* in our
community. There isn't any obvious way to get 'techtonik' brought into
our community unless they come to the dev@ list.
That said... we *do* accept patches via the issue tracker on
subversion.tigris.org. Are we ready to accept patches through a
separate channel? Personally, I'm not ready to say "hey, any channel
on the planet is fine. please... feel free! devise new channels! we
are willing to review 100 channels for incoming patches!"
I like GitHub. It is a very, very well-done site. But I'm not ready to
say that it is a viable mechanism for people to deliver patches. My
preference is for those to arrive here on dev@, where we can interact
with the person. Not as some drive-by, fait accompli.
Thoughts?
-g
On Thu, May 24, 2012 at 4:12 AM, Git at Apache <gi...@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-classes-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 <te...@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-classes-in-python
>
> ----
>