Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #101113 > unrolled thread

Re: We will be moving to GitHub

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: We will be moving to GitHub Zachary Ware <zachary.ware+pylist@gmail.com> - 2016-01-01 13:58 -0600
    Re: We will be moving to GitHub Paul Rubin <no.email@nospam.invalid> - 2016-01-01 12:33 -0800
      Re: We will be moving to GitHub Zachary Ware <zachary.ware+pylist@gmail.com> - 2016-01-01 14:46 -0600
        Re: We will be moving to GitHub Paul Rubin <no.email@nospam.invalid> - 2016-01-01 13:19 -0800
      Re: We will be moving to GitHub Ben Finney <ben+python@benfinney.id.au> - 2016-01-02 18:02 +1100
      Re: We will be moving to GitHub Michael Torrie <torriem@gmail.com> - 2016-01-02 20:31 -0700
      GitHub's “pull request” is proprietary lock-in (was: We will be moving to GitHub) Ben Finney <ben+python@benfinney.id.au> - 2016-01-03 15:43 +1100
        Re: GitHub's ³pull request² is proprietary lock-in (was: We will be moving to GitHub) Michael Vilain <vilain@NOspamcop.net> - 2016-01-02 20:56 -0800
          Re: GitHub's ³pull request² is proprietary lock-in Random832 <random832@fastmail.com> - 2016-01-03 02:04 -0500
            Re: GitHub's ³pull request² is proprietary lock-in Christian Gollwitzer <auriocus@gmx.de> - 2016-01-03 08:44 +0100
              Re: GitHub's ³pull request² is proprietary lock-in Ben Finney <ben+python@benfinney.id.au> - 2016-01-03 19:03 +1100
                Re: GitHub's ³pull request² is proprietary lock-in Christian Gollwitzer <auriocus@gmx.de> - 2016-01-03 09:33 +0100
                  Re: GitHub's ³pull request² is proprietary lock-in Ben Finney <ben+python@benfinney.id.au> - 2016-01-03 19:45 +1100
                  Re: GitHub's ³pull request² is proprietary lock-in Chris Angelico <rosuav@gmail.com> - 2016-01-03 20:18 +1100
                  Re: GitHub's ³pull request² is proprietary lock-in Random832 <random832@fastmail.com> - 2016-01-03 04:31 -0500
                    Re: GitHub's ³pull request² is proprietary lock-in Paul Rubin <no.email@nospam.invalid> - 2016-01-03 01:50 -0800
                  Re: [python] Re: GitHub's ³pull request² is proprietary lock-in "W. Trevor King" <wking@tremily.us> - 2016-01-03 01:42 -0800
                  Re: GitHub's ³pull request² is proprietary lock-in Ben Finney <ben+python@benfinney.id.au> - 2016-01-03 20:46 +1100
                  Re: GitHub's ³pull request² is proprietary lock-in Chris Angelico <rosuav@gmail.com> - 2016-01-03 21:17 +1100
                  Re: GitHub's ³pull request² is proprietary lock-in Chris Angelico <rosuav@gmail.com> - 2016-01-03 21:24 +1100
                    Re: GitHub's ³pull request² is proprietary lock-in Paul Rubin <no.email@nospam.invalid> - 2016-01-03 02:42 -0800
                      Re: GitHub's ³pull request² is proprietary lock-in Chris Angelico <rosuav@gmail.com> - 2016-01-03 23:33 +1100
                        Re: GitHub's ³pull request² is proprietary lock-in Paul Rubin <no.email@nospam.invalid> - 2016-01-03 21:29 -0800
                          Re: GitHub's ³pull request² is proprietary lock-in Christian Gollwitzer <auriocus@gmx.de> - 2016-01-04 08:02 +0100
            Re: GitHub's ©¯pull request©— is proprietary lock-in Michael Vilain <vilain@NOspamcop.net> - 2016-01-03 12:51 -0800
          Re: GitHub's �pull request� is proprietary lock-in Michael Torrie <torriem@gmail.com> - 2016-01-03 08:05 -0700
          Re: GitHub's �pull request� is proprietary lock-in Michael Torrie <torriem@gmail.com> - 2016-01-03 08:14 -0700
        Re: GitHub's “pull request” is proprietary lock-in Kevin Walzer <kw@codebykevin.com> - 2016-01-03 16:58 -0500
        Re: GitHub's “pull request” is proprietary lock-in m <mvoicem@gmail.com> - 2016-01-04 11:21 +0100
          Re: GitHub's “pull request” is proprietary lock-in Michael Torrie <torriem@gmail.com> - 2016-01-04 10:41 -0700
            Re: GitHub's "pull request" is proprietary lock-in Josef Pktd <josef.pktd@gmail.com> - 2016-01-04 13:29 -0800
            Re: GitHub's “pull request” is proprietary lock-in m <mvoicem@gmail.com> - 2016-01-05 01:24 +0100
      Re: GitHub's “pull request” is proprietary lock-in Random832 <random832@fastmail.com> - 2016-01-03 19:51 -0500
      Re: GitHub's “pull request” is proprietary lock-in Michael Torrie <torriem@gmail.com> - 2016-01-03 21:16 -0700
      Re: GitHub's “pull request” is proprietary lock-in Random832 <random832@fastmail.com> - 2016-01-03 23:58 -0500

Page 1 of 2  [1] 2  Next page →

#101113 — Re: We will be moving to GitHub

On Jan 1, 2016 1:47 PM, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Sat, Jan 2, 2016 at 6:39 AM, Mark Lawrence <breamoreboy@yahoo.co.uk>
wrote:
> > Please see
> > https://mail.python.org/pipermail/core-workflow/2016-January/000345.html
> >
> > This should encourage developers at all levels to help out, such that
the
> > list of open issues on the bug tracker falls drastically.
>
> How does that interact with the still-Draft status of PEP 481? The
> email seems to mainly be saying "not GitLab", but until PEP 481 is
> accepted, I'm not certain that GitHub is accepted either.
>
> It's not entirely clear whether that message is an acceptance of PEP 481
or not.

I've lost track of the pep numbers, but Brett's decision is final; the
canonical CPython repository will be moving to GitHub in the near future.
Note that we will *not* be using the GitHub issue tracker or wiki, just the
hosting and review/pull request system. There are still several details to
be worked out, though.

--
Zach
(On a phone)

[toc] | [next] | [standalone]

#101117

Zachary Ware <zachary.ware+pylist@gmail.com> writes:
> ... the canonical CPython repository will be moving to GitHub in the
> near future.  Note that we will *not* be using the GitHub issue
> tracker or wiki, just the hosting and review/pull request system.

Will everyone wanting to submit patches be required to use a Github
account?  Or will it be enough to put the patch in an outside repo and
link to it in the Python issue tracker?  I'm glad that (it sounds like)
no Github account will be needed to submit bug reports.

[toc] | [prev] | [next] | [standalone]

#101118

On Jan 1, 2016 2:35 PM, "Paul Rubin" <no.email@nospam.invalid> wrote:
>
> Zachary Ware <zachary.ware+pylist@gmail.com> writes:
> > ... the canonical CPython repository will be moving to GitHub in the
> > near future.  Note that we will *not* be using the GitHub issue
> > tracker or wiki, just the hosting and review/pull request system.
>
> Will everyone wanting to submit patches be required to use a Github
> account?  Or will it be enough to put the patch in an outside repo and
> link to it in the Python issue tracker?  I'm glad that (it sounds like)
> no Github account will be needed to submit bug reports.

Correct, no GitHub account will be required for interactions on the
bugs.python.org tracker, and a patch can move all the way through to commit
entirely on the b.p.o tracker (just as currently).

--
Zach
(On a phone)

[toc] | [prev] | [next] | [standalone]

#101121

Zachary Ware <zachary.ware+pylist@gmail.com> writes:
> Correct, no GitHub account will be required for interactions on the
> bugs.python.org tracker, and a patch can move all the way through to commit
> entirely on the b.p.o tracker (just as currently).

Thanks.

[toc] | [prev] | [next] | [standalone]

#101131

Zachary Ware <zachary.ware+pylist@gmail.com> writes:

> On Jan 1, 2016 2:35 PM, "Paul Rubin" <no.email@nospam.invalid> wrote:
> > Will everyone wanting to submit patches be required to use a Github
> > account? Or will it be enough to put the patch in an outside repo
> > and link to it in the Python issue tracker? I'm glad that (it sounds
> > like) no Github account will be needed to submit bug reports.
>
> Correct, no GitHub account will be required for interactions on the
> bugs.python.org tracker, and a patch can move all the way through to
> commit entirely on the b.p.o tracker (just as currently).

My experience with contributing to repositories hosted on GitHub, from
repositories hosted elsewhere, necessitates the question:

What is being done to stave off the common response, addressed by GitHub
users to people submitting a change as a link to their Git repository,
of “can you please submit that as a GitHub pull request”?

That common response makes for an unnecessary and IMO unacceptable
pressure toward centralisation. GitHub's “pull request” workflow is
entirely proprietary and can only be done within GitHub.

What will be done to ensure other Git repositories remain on a level
playing field not only technically, but socially?

-- 
 \     “Ours is a world where people don't know what they want and are |
  `\       willing to go through hell to get it.” —Donald Robert Perry |
_o__)                                                          Marquis |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#101184

On 01/02/2016 12:02 AM, Ben Finney wrote:
> What is being done to stave off the common response, addressed by GitHub
> users to people submitting a change as a link to their Git repository,
> of “can you please submit that as a GitHub pull request”?
> 
> That common response makes for an unnecessary and IMO unacceptable
> pressure toward centralisation. GitHub's “pull request” workflow is
> entirely proprietary and can only be done within GitHub.

Really?  This seems like an entirely artificial github requirement.
There's absolutely no reason why github couldn't do a pull request from
any arbitrary, valid git url.

[toc] | [prev] | [next] | [standalone]

#101186 — GitHub's “pull request” is proprietary lock-in (was: We will be moving to GitHub)

Michael Torrie <torriem@gmail.com> writes:

> On 01/02/2016 12:02 AM, Ben Finney wrote:
> > GitHub's “pull request” workflow is entirely proprietary and can
> > only be done within GitHub.
>
> Really?  This seems like an entirely artificial github requirement.

Yes, it is.

> There's absolutely no reason why github couldn't do a pull request from
> any arbitrary, valid git url.

Right. The proprietary GitHub “pull request” has many more features
(including a code review tool and discussion thread that are
automatically tied to the pull request) which make it attractive.

The fact these features (unlike Git) are wholly proprietary, and the
valuable processes and data they generate cannot be exported and
continued easily in another instance when a community chooses, are what
makes GitHub's “pull request” an attractive nuisance.

That and other vendor-locked workflow aspects of GitHub makes it a poor
choice for communities that want to retain the option of control over
their processes and data.

-- 
 \     “Try adding “as long as you don't breach the terms of service – |
  `\          according to our sole judgement” to the end of any cloud |
_o__)                      computing pitch.” —Simon Phipps, 2010-12-11 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#101187 — Re: GitHub's ³pull request² is proprietary lock-in (was: We will be moving to GitHub)

In article <mailman.192.1451796242.11925.python-list@python.org>,
 Ben Finney <ben+python@benfinney.id.au> wrote:

> Michael Torrie <torriem@gmail.com> writes:
> 
> > On 01/02/2016 12:02 AM, Ben Finney wrote:
> > > GitHub's ³pull request² workflow is entirely proprietary and can
> > > only be done within GitHub.
> >
> > Really?  This seems like an entirely artificial github requirement.
> 
> Yes, it is.
> 
> > There's absolutely no reason why github couldn't do a pull request from
> > any arbitrary, valid git url.
> 
> Right. The proprietary GitHub ³pull request² has many more features
> (including a code review tool and discussion thread that are
> automatically tied to the pull request) which make it attractive.
> 
> The fact these features (unlike Git) are wholly proprietary, and the
> valuable processes and data they generate cannot be exported and
> continued easily in another instance when a community chooses, are what
> makes GitHub's ³pull request² an attractive nuisance.
> 
> That and other vendor-locked workflow aspects of GitHub makes it a poor
> choice for communities that want to retain the option of control over
> their processes and data.

We used stash/bitbucket at my last contract.  It's the second site I've 
come across that used Atlasian's toolset.  Yes, I know it's not 
statistically significant.

Anyway, the pull/merge request workflow is becoming pretty standard.  I 
used it with another programmer on a project to review the code I was 
generating and checking into the stash git archive.  He told me the 
"gitflow" methodology is becoming more and more used in companies 
(except Google who use their own repository product and way of doing 
*everything*).

The "lock-in" to this methodology is seems like a strawman to me.  And 
based on the language of the python development team, moot.  If you 
don't like their choice of repository and code review, I'm sure there 
are LOTS of open source proejects where you can lend a hand if you don't 
like how python is being run.

This isn't the first time I've seen this sort of "use this tool and I'm 
outta here" attitude.  A friend refuses to work for any company that 
uses Clearcase (or Clearcurse as he calls it).  He'll end an interview 
on the spot if he finds this out.  He also has specific requirements 
about placement of {}.  But, that can be dealt with using 
standardization formatting tool when you check code into git via a 
webhook.

Seriously, don't like git and the gitflow, find a project where they do 
things more to your liking.

-- 
DeeDee, don't press that button!  DeeDee!  NO!  Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]

[toc] | [prev] | [next] | [standalone]

#101189 — Re: GitHub's ³pull request² is proprietary lock-in

Michael Vilain <vilain@NOspamcop.net> writes:
> We used stash/bitbucket at my last contract.  It's the second site I've 
> come across that used Atlasian's toolset.  Yes, I know it's not 
> statistically significant.
>
> Anyway, the pull/merge request workflow is becoming pretty standard.

I think you're missing a distinction between "pull/merge request
workflow" and the specific artifact that github _calls_ a "pull
request", which includes references to specific github accounts, a
discussion thread on their proprietary discussion software (vs an email
list or the python issue tracker) maintained on their servers and not
servers that PSF controls, etc.

[toc] | [prev] | [next] | [standalone]

#101190 — Re: GitHub's ³pull request² is proprietary lock-in

Am 03.01.16 um 08:04 schrieb Random832:
> Michael Vilain <vilain@NOspamcop.net> writes:
>> We used stash/bitbucket at my last contract.  It's the second site I've
>> come across that used Atlasian's toolset.  Yes, I know it's not
>> statistically significant.
>>
>> Anyway, the pull/merge request workflow is becoming pretty standard.
>
> I think you're missing a distinction between "pull/merge request
> workflow" and the specific artifact that github _calls_ a "pull
> request", which includes references to specific github accounts, a
> discussion thread on their proprietary discussion software (vs an email
> list or the python issue tracker) maintained on their servers and not
> servers that PSF controls, etc.

Arguably, the most valuable outcome of the pull request in the end is 
the patch, which is of course contained in the git repository. GitHub 
also sends email notifications if a pull request is edited. So if the 
account holder for GitHub keeps an archive of all mail from 
notifications@github.com, then also the big part of this discussion is 
preserved. I doubt that many people want to go back to see the arguments 
for a certain merge; this thread will also soon be abandoned, people 
will know that Python lives on GitHub and live with it, move on and do 
something more valuable.

	Christian

[toc] | [prev] | [next] | [standalone]

#101191 — Re: GitHub's ³pull request² is proprietary lock-in

Christian Gollwitzer <auriocus@gmx.de> writes:

> Arguably, the most valuable outcome of the pull request in the end is
> the patch, which is of course contained in the git repository.

Arguably, the most valuable outcome of a database system is the query
result, which is of course contained in the result set of tuples
contained in the response data.

Arguably, the most valuable outcome of a version control system is the
source code tree, which is of course contained in a filesystem directory.

Arguably, the most valuable outcome of a programming language is the
programs we write with it, which is of course contained in the compiled
binary.

By your reasoning, that means we should not care about handing the
control over our database system, our version control system, or our
programming language to a vendor-locked, proprietary, gratuitously
centralised technology.

I hope the analogy makes it clear why that's not an argument I think
anyone would accept as sound.

> I doubt that many people want to go back to see the arguments for a
> certain merge

I doubt many people want to go into the source code for my operating
system and tell me exactly what it's doing, where my data is stored, how
to get it from this operating system to a different one.

My freedom to migrate from that system to a different one when I choose,
is entirely dependent on *anyone* being able to do that, no matter how
few people express an interest where you might see it.

-- 
 \               “There's no excuse to be bored. Sad, yes. Angry, yes. |
  `\    Depressed, yes. Crazy, yes. But there's no excuse for boredom, |
_o__)                                          ever.” —Viggo Mortensen |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#101192 — Re: GitHub's ³pull request² is proprietary lock-in

Am 03.01.16 um 09:03 schrieb Ben Finney:
> Christian Gollwitzer <auriocus@gmx.de> writes:
>
>> Arguably, the most valuable outcome of the pull request in the end is
>> the patch, which is of course contained in the git repository.
>
> Arguably, the most valuable outcome of a database system is the query
> result, which is of course contained in the result set of tuples
> contained in the response data.
>
> Arguably, the most valuable outcome of a version control system is the
> source code tree, which is of course contained in a filesystem directory.
>
> Arguably, the most valuable outcome of a programming language is the
> programs we write with it, which is of course contained in the compiled
> binary.
>
> By your reasoning, that means we should not care about handing the
> control over our database system, our version control system, or our
> programming language to a vendor-locked, proprietary, gratuitously
> centralised technology.
>
> I hope the analogy makes it clear why that's not an argument I think
> anyone would accept as sound.

There are layers. Below your Python code there is CPython, below that 
the C compiler, the OS, and finally the hardware. If you are using an 
Intel CPU, you can't control the interpreter of the x86-64 machine 
opcodes. At some point, nobody cares. It's a question where to put the 
border. In former times, people sent emails with patches attached. 
Nobody complains that those emails are lost to the community. Then 
somebody invented VCS and all became better. Pull requests are nothing 
but elaborated emails.

>> I doubt that many people want to go back to see the arguments for a
>> certain merge
>
> I doubt many people want to go into the source code for my operating
> system and tell me exactly what it's doing, where my data is stored, how
> to get it from this operating system to a different one.
>
> My freedom to migrate from that system to a different one when I choose,
> is entirely dependent on *anyone* being able to do that, no matter how
> few people express an interest where you might see it.

You can still migrate, because git stays git.

	Christian

[toc] | [prev] | [next] | [standalone]

#101194 — Re: GitHub's ³pull request² is proprietary lock-in

Christian Gollwitzer <auriocus@gmx.de> writes:

> There are layers. Below your Python code there is CPython, below that
> the C compiler, the OS, and finally the hardware.

Yes. There are continual motivations to take the technology at any of
those levels and make it less free, make it more locked to single
vendors, make it more difficult to migrate our valuable data to a system
under our control.

Asserting that one level is currently less free, is in no measure an
argument to allow a different level to be moved further from the
community's control.

> At some point, nobody cares.

You clearly do care, since you are participating in this discussion and
attempting to argue that people *should not* care.

> In former times, people sent emails with patches attached. Nobody
> complains that those emails are lost to the community.

You make my point for me: Nothing about that method of transferring code
changes was actively controlled by a single vendor, nor gratuitously
centralised, nor handed to an unexaminable, unaccountable system.

> Then somebody invented VCS and all became better. Pull requests are
> nothing but elaborated emails.

Email is decentralised; it has no gratuitous barriers between diverse
implementations of the standards; it has standards that are
energetically guarded against vendor lock-in.

Anyone can take email data from the email server, migrate it to a
different implementation of the same email system, keep it running with
the same data and allow the same people to continue interacting with it
as before.

Those are traits I think a community should require of any system that
controls vital discussions like pull requests.

If GitHub pull requests could be verified to work that way, I would have
no complaint here. Until they do, it is foolish for a community to
willingly put their correspondence data into it.

-- 
 \       “Come on Milhouse, there’s no such thing as a soul! It’s just |
  `\      something they made up to scare kids, like the Boogie Man or |
_o__)                          Michael Jackson.” —Bart, _The Simpsons_ |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#101195 — Re: GitHub's ³pull request² is proprietary lock-in

On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Anyone can take email data from the email server, migrate it to a
> different implementation of the same email system, keep it running with
> the same data and allow the same people to continue interacting with it
> as before.
>
> Those are traits I think a community should require of any system that
> controls vital discussions like pull requests.
>
> If GitHub pull requests could be verified to work that way, I would have
> no complaint here. Until they do, it is foolish for a community to
> willingly put their correspondence data into it.

They are. Ultimately, a GitHub pull request is backed by a git pull
request. Here's an example:

https://github.com/MikeiLL/appension/pull/187

That's a request to pull https://github.com/Rosuav/appension's
log_to_file branch
(https://github.com/Rosuav/appension/tree/log_to_file) into the master
branch. That can be fetched and merged into a local repository:

git pull https://github.com/Rosuav/appension log_to_file

If the official workflow is built on these commands, then it doesn't
depend on GitHub at all. Someone puts through a GH PR and it'll create
an email that provides all the necessary info; but equally, someone
can use any other git hosting and send through an identical pull
request without ever touching GH. Since actual bug discussion isn't
being moved away from bugs.python.org, this should be safe.

ChrisA

[toc] | [prev] | [next] | [standalone]

#101196 — Re: GitHub's ³pull request² is proprietary lock-in

Chris Angelico <rosuav@gmail.com> writes:
> They are. Ultimately, a GitHub pull request is backed by a git pull
> request.

There is no such thing as a "git pull request", except in the
ordinary english meaning of the word request. It is true that a
pull request is, from one angle, a formalized request for someone
to execute a git pull command.  But there is no command to create
a "pull request", nowhere for such a thing to exist in the
repository, etc.

It is, in essence, a parallel bug tracker, with its own discussion
system, its own statuses, etc.

> Here's an example:
>
> https://github.com/MikeiLL/appension/pull/187
>
> That's a request to pull https://github.com/Rosuav/appension's
> log_to_file branch
> (https://github.com/Rosuav/appension/tree/log_to_file) into the master
> branch. That can be fetched and merged into a local repository:
>
> git pull https://github.com/Rosuav/appension log_to_file
>
> If the official workflow is built on these commands, then it doesn't
> depend on GitHub at all. Someone puts through a GH PR and it'll create
> an email that provides all the necessary info; but equally, someone
> can use any other git hosting and send through an identical pull
> request without ever touching GH.

When I tried github it was also very unclear how someone can pull
to a github repository from a source other than another github
repository with an associated github pull request. I suppose they
could pull into their local repository and then push to github.

Also if someone puts through a github pull request and then their
patch is accepted, my understanding is that the pull request has
to be "closed" through a github online interface and merely
merging the patch through the git command line will not update the
status on the pull request.

> Since actual bug discussion isn't
> being moved away from bugs.python.org, this should be safe.

I don't think you can really narrow "actual bug discussion" like
that.  Some discussion takes place on the bug tracker, some
discussion takes place here, some discussion takes place on
python-ideas, some discussion takes place on other mailing
lists... and it's suspected that some discussion will take place
on github.  All of that discussion has value, and it's not good to
have any of it locked up in a place that cannot be exported.

[toc] | [prev] | [next] | [standalone]

#101199 — Re: GitHub's ³pull request² is proprietary lock-in

Random832 <random832@fastmail.com> writes:
> All of that discussion has value, and it's not good to
> have any of it locked up in a place that cannot be exported.

I have a dim recollection of Python moving from Trac to a proprietary,
hosted bug tracker for a while, but now they're back to an open(?)
system but are about to do the same thing with Github.  It's ironic that
Git itself was written to escape the debacle of the Linux kernel using
hosted (Bitkeeper) source control for a while.  As for patch review
discussions, didn't Guido himself write Gerrit?  Somehow it's never been
mentioned here.

[toc] | [prev] | [next] | [standalone]

#101197 — Re: [python] Re: GitHub's ³pull request² is proprietary lock-in

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jan 03, 2016 at 04:31:55AM -0500, Random832 wrote:
> But there is no command to create a "pull request", nowhere for such
> a thing to exist in the repository, etc.

There is this [1].

> Also if someone puts through a github pull request and then their
> patch is accepted, my understanding is that the pull request has to
> be "closed" through a github online interface and merely merging the
> patch through the git command line will not update the status on the
> pull request.

This is incorrect.  GitHub will automatically mark PRs as “Merged”
when their tip commit lands in the target branch.  I haven't looked up
docs for when this landed (if it was even announced), but next to
GitHub's “Merge pull request” button there's currently an “or view
command line instructions” link which sketches out some command-line
Git to accomplish the same thing.

But I agree that it's nice to keep the discussion around pull requests
somewhere portable.

Cheers,
Trevor

[1]: http://git-scm.com/docs/git-request-pull

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[toc] | [prev] | [next] | [standalone]

#101198 — Re: GitHub's ³pull request² is proprietary lock-in

Chris Angelico <rosuav@gmail.com> writes:

> On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> > Anyone can take email data from the email server, migrate it to a
> > different implementation of the same email system, keep it running
> > with the same data and allow the same people to continue interacting
> > with it as before.
> >
> > Those are traits I think a community should require of any system
> > that controls vital discussions like pull requests.
>
> They are. Ultimately, a GitHub pull request is backed by a git pull
> request. Here's an example:
>
> https://github.com/MikeiLL/appension/pull/187

Yes, of course the VCS data is in Git and therefore can be accessed with
Git. Please stop raising that when *I'm not talking about* the VCS data
alone, I'm talking also about the data of the pull request feature.


The discussion data, code review data, etc. is all part of “GitHub pull
request”. How do we export, along with the VCS data, the data and system
that control the code review discussino and other useful features
entailed by “GitHub pull request”?

How do we get that data and confidently and quickly set up a system
hosted on a different provider that allows everyone involved to continue
the same code reviews and discussions etc. without GitHub?

To my knowledge we can't, short of re-implementing an expressly
proprietary non-standard system against the wishes of the vendor.

That's valuable community data being locked into a single-vendor system,
who explicitly rejects community access to the system and the data
needed to continue on a different provider.

It boggles my mind that so many people – even when the conversation has
directly raised the notion of different layers of technology that
control different layers of valuable data – blithely ignore the fact
that *the discussion itself* is dependent on a software system and data.

Control over that software system and data is important to control over
the valuable discussions, just as control over the VCS system and data
is important to control over the valuable source code.


Conversely, as Ned Batchelder points out, without all the proprietary
vendor lock-in centralised features, GitHub is a fairly unimpressive Git
hosting provider. The “but Git is free software, no one is locked in!”
is trivially true, and has an obvious response in “then there's no good
reason to move anything there”.

Please, those who are going to advocate for GitHub especially over other
Git hosting providers because it has specially valuable features, be
honest that you're advocating moving control of valuable information
away from the community that values them.

-- 
 \       “First things first, but not necessarily in that order.” —The |
  `\                                              Doctor, _Doctor Who_ |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#101200 — Re: GitHub's ³pull request² is proprietary lock-in

On Sun, Jan 3, 2016 at 8:46 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>> > Anyone can take email data from the email server, migrate it to a
>> > different implementation of the same email system, keep it running
>> > with the same data and allow the same people to continue interacting
>> > with it as before.
>> >
>> > Those are traits I think a community should require of any system
>> > that controls vital discussions like pull requests.
>>
>> They are. Ultimately, a GitHub pull request is backed by a git pull
>> request. Here's an example:
>>
>> https://github.com/MikeiLL/appension/pull/187
>
> Yes, of course the VCS data is in Git and therefore can be accessed with
> Git. Please stop raising that when *I'm not talking about* the VCS data
> alone, I'm talking also about the data of the pull request feature.

Uh, that's a pull request link. I'm talking specifically about the
pull request feature here.

> The discussion data, code review data, etc. is all part of “GitHub pull
> request”. How do we export, along with the VCS data, the data and system
> that control the code review discussino and other useful features
> entailed by “GitHub pull request”?
>
> How do we get that data and confidently and quickly set up a system
> hosted on a different provider that allows everyone involved to continue
> the same code reviews and discussions etc. without GitHub?

That's why I talked about what it's like if discussion continues to
happen on b.p.o. Which is the current proposal.

ChrisA

[toc] | [prev] | [next] | [standalone]

#101201 — Re: GitHub's ³pull request² is proprietary lock-in

On Sun, Jan 3, 2016 at 8:31 PM, Random832 <random832@fastmail.com> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> They are. Ultimately, a GitHub pull request is backed by a git pull
>> request.
>
> There is no such thing as a "git pull request", except in the
> ordinary english meaning of the word request. It is true that a
> pull request is, from one angle, a formalized request for someone
> to execute a git pull command.  But there is no command to create
> a "pull request", nowhere for such a thing to exist in the
> repository, etc.

As Trevor mentioned, git does have such a thing - it's not as well
known as some other uses of the term, but it definitely does exist.
Ultimately, though, it's simply a request: "please pull from here".
There's not a lot to store.

> When I tried github it was also very unclear how someone can pull
> to a github repository from a source other than another github
> repository with an associated github pull request. I suppose they
> could pull into their local repository and then push to github.

If you're not using a GitHub PR, then what you're doing is using GH to
host your repository. So yes, you pull into your local repo and then
push to GH. That's exactly what you'd do with pretty much any other
workflow; currently, how would a core committer apply a patch to
CPython? Apply it locally, then push. DVCSes pretty much exclusively
work that way.

> Also if someone puts through a github pull request and then their
> patch is accepted, my understanding is that the pull request has
> to be "closed" through a github online interface and merely
> merging the patch through the git command line will not update the
> status on the pull request.

GitHub is smart enough to recognize a straight-forward merge;
otherwise (maybe you cherry-picked some commits only, or something),
you can use standard notation like "Closes #1234" to signal what
you're doing. But...

>> Since actual bug discussion isn't
>> being moved away from bugs.python.org, this should be safe.

... this is still true.

> I don't think you can really narrow "actual bug discussion" like
> that.  Some discussion takes place on the bug tracker, some
> discussion takes place here, some discussion takes place on
> python-ideas, some discussion takes place on other mailing
> lists... and it's suspected that some discussion will take place
> on github.  All of that discussion has value, and it's not good to
> have any of it locked up in a place that cannot be exported.

Sure, some discussion takes place on mailing lists. And I'm sure some
of the discussion takes place on IRC, and in elevators on the way up
to the 34th floor of some building somewhere. Are we going demand a
logging IRCbot, and panic because we still can't capture the latter?
No. If the discussion is important enough to be kept, it can be done
on a place that's designed for keeping it: b.p.o.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web