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 2 of 2 — ← Prev page 1 [2]

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

Chris Angelico <rosuav@gmail.com> writes:
> 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.

What's the point of GH in that situation?  

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

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

On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>> 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.
>
> What's the point of GH in that situation?

Mainly hosting, plus you can use gh-pages and other features. Plenty.

ChrisA

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

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

Chris Angelico <rosuav@gmail.com> writes:

> On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin <no.email@nospam.invalid> wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>>> If you're not using a GitHub PR, then what you're doing is using GH to
>>> host your repository.
>> What's the point of GH in that situation?
> Mainly hosting, plus you can use gh-pages and other features. Plenty.

GH pages are just normal web pages with markdown processing, right?
What other features?  And doesn't that come back around to getting
locked into the walled garden?

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

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

Am 04.01.16 um 06:29 schrieb Paul Rubin:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin <no.email@nospam.invalid> wrote:
>>> Chris Angelico <rosuav@gmail.com> writes:
>>>> If you're not using a GitHub PR, then what you're doing is using GH to
>>>> host your repository.
>>> What's the point of GH in that situation?
>> Mainly hosting, plus you can use gh-pages and other features. Plenty.
>
> GH pages are just normal web pages with markdown processing, right?

Yes. The processor is freely available (jekyll, written in Ruby). It's 
usual to put up a local server (jekyl --serve) while updating the pages, 
befor you publish them, which is done by a git commit/push to the 
gh-pages branch.

> What other features?  And doesn't that come back around to getting
> locked into the walled garden?


For the pages definitely not.

	Christian

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

#101217 — Re: GitHub's ©¯pull request©— is proprietary lock-in

In article <mailman.194.1451804661.11925.python-list@python.org>,
 Random832 <random832@fastmail.com> wrote:

> 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.

Atlassian's bitbucket (formerly stash) does this exactly same from the 
web site that is the front end to the repository.  You review changes 
from your user account if you've been named as a reviewer and comment on 
changed items on the web page.  

We didn't use the "must require N number of reviewers to merge" feature.  
My fellow team member reviewed what I did, asked questions, mostly on 
"what does this mean" (he was trying to learn the ins and outs of 
puppet).  If there was a change that conflicted (e.g. we both made 
changes to the same file that couldn't be merged automatically), we'd 
decide who would change what.  Usually, I'd just make another commit in 
the branch to fix the problem.  We did all of this in a branch off 
master.

Having to build a git server with a front-end that offered the level of 
project granularity (e.g. multiple groups of people, each with their own 
projects and repos) was why we chose bitbucket over github.  I 
understand you can use Garret as a front-end to get LDAP groups, but the 
site didn't use LDAP or AD authentication, so we looked for something 
else.

I haven't used a bare git repo without the Atlassian/Github front-end to 
do a merge/pull request with email review.  How do you do it manually?

-- 
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]

#101208 — Re: GitHub's �pull request� is proprietary lock-in

On 01/02/2016 09:56 PM, Michael Vilain wrote:
> Seriously, don't like git and the gitflow, find a project where they do 
> things more to your liking.

I do like git and the git work-flow.  Seems like github is doing an
end-run around several of the key features of git and the git work-flow
to keep people from going outside their environment.  This is definitely
not the work flow Linus originally had in mind, though he is not
terribly upset about it all as I think kernel development is now
exclusively on github.

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

#101209 — Re: GitHub's �pull request� is proprietary lock-in

On 01/03/2016 08:09 AM, Bernardo Sulzbach wrote:
> On Sun, Jan 3, 2016 at 1:05 PM, Michael Torrie <torriem@gmail.com> wrote:
>> kernel development is now exclusively on github.
>>
> 
> No it is not. If they have (now) 88 PR is because people don't RTFM.

Good to know.

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

#101218 — Re: GitHub's “pull request” is proprietary lock-in

On 1/2/16 11:43 PM, Ben Finney wrote:
> 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.

The Tcl community has moved to Fossil with great success:

http://www.fossil-scm.org

Lightweight DCVS, integrated bug tracking, rock-solid code (authored by 
D. Richard Hipp, uses SQLite as its store).

The transition was non-trivial: the Tcl core developers had to move over 
a decade of commit history from CVS at Sourceforge to Fossil, which they 
did, successfully. One of the reasons Fossil was chosen is exactly this: 
to maintain the code independent of a third-party platform. (At the time 
of the transition, in 2011, Sourceforge was removing support for CVS, 
they had a server outage for over a week, and other issues were giving 
the community pause on continuing to use SF for hosting.)

I'm not a hardcore Git user so have no substantive opinions on the 
merits of Git or Github per se: I have a Github account and have 
contributed code via pull requests to projects hosted on it. But I found 
learning Fossil very simple. And using Fossil does not preclude 
mirroring the codebase in Git; there is a Tcl/Tk mirror at Github.

Just a thought.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

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

#101242 — Re: GitHub's “pull request” is proprietary lock-in

W dniu 03.01.2016 o 05:43, Ben Finney pisze:
> 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.

I'm also afraid that Github will make to git the same thing as Google
did to Jabber/XMPP.

Decade ago, I had plenty of friends on my jabber contacts list. Next,
Google made it's talk compatible with jabber, then my friends slowly
migrated to gtalk, because if they used gmail anyway, then why not use
it also for jabber?

And then Google turned off XMPP support and suddenly I lost ability to
contact with 80% of my friends without having stupid hangouts running,
or without falling back to email (which is not so bad BTW).

The same can be with Github and git. PPL will forget how to use git
without github. When Github will make git-incompatible changes, vast
majority will need/want to follow the changes and eg. will use Gitlabs
propertiary binary.

r. m.

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

#101245 — Re: GitHub's “pull request” is proprietary lock-in

On 01/04/2016 03:21 AM, m wrote:
> W dniu 03.01.2016 o 05:43, Ben Finney pisze:
>> 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.
> 
> I'm also afraid that Github will make to git the same thing as Google
> did to Jabber/XMPP.
> 
> Decade ago, I had plenty of friends on my jabber contacts list. Next,
> Google made it's talk compatible with jabber, then my friends slowly
> migrated to gtalk, because if they used gmail anyway, then why not use
> it also for jabber?
> 
> And then Google turned off XMPP support and suddenly I lost ability to
> contact with 80% of my friends without having stupid hangouts running,
> or without falling back to email (which is not so bad BTW).

I use gtalk with Pidgin every day using XMPP.  So Google still supports
XMPP.  However what they stopped doing was allowing federated XMPP,
which pretty much breaks XMPP, at least the spirit of it.  So the only
way to chat with gtalk users is to use your gtalk account.  But you
certainly don't need hangouts.  XMPP works fine between your client and
the Google server.

I agree that Google really pulled a bad one with gtalk though.  Dropping
federated XMPP support was definitely not in keeping with their original
"do no evil" mantra.

> The same can be with Github and git. PPL will forget how to use git
> without github. When Github will make git-incompatible changes, vast
> majority will need/want to follow the changes and eg. will use Gitlabs
> propertiary binary.

Yup you are correct.  However for the foreseeable future, you can still
do a git clone from github, and you can still use your local repository
normally.  In fact I think this is really part of the github workflow.
But who knows what the future will bring.  I can sure see the wisdom of
the GPLv3 as we move into a world of software as a service, where even
Microsoft uses Linux, and charges us for it.

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

#101247 — Re: GitHub's "pull request" is proprietary lock-in

On Monday, January 4, 2016 at 12:41:32 PM UTC-5, Michael Torrie wrote:
> On 01/04/2016 03:21 AM, m wrote:
> > W dniu 03.01.2016 o 05:43, Ben Finney pisze:
> >> 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.
> > 
> > I'm also afraid that Github will make to git the same thing as Google
> > did to Jabber/XMPP.
> > 
> > Decade ago, I had plenty of friends on my jabber contacts list. Next,
> > Google made it's talk compatible with jabber, then my friends slowly
> > migrated to gtalk, because if they used gmail anyway, then why not use
> > it also for jabber?
> > 
> > And then Google turned off XMPP support and suddenly I lost ability to
> > contact with 80% of my friends without having stupid hangouts running,
> > or without falling back to email (which is not so bad BTW).
> 
> I use gtalk with Pidgin every day using XMPP.  So Google still supports
> XMPP.  However what they stopped doing was allowing federated XMPP,
> which pretty much breaks XMPP, at least the spirit of it.  So the only
> way to chat with gtalk users is to use your gtalk account.  But you
> certainly don't need hangouts.  XMPP works fine between your client and
> the Google server.
> 
> I agree that Google really pulled a bad one with gtalk though.  Dropping
> federated XMPP support was definitely not in keeping with their original
> "do no evil" mantra.
> 
> > The same can be with Github and git. PPL will forget how to use git
> > without github. When Github will make git-incompatible changes, vast
> > majority will need/want to follow the changes and eg. will use Gitlabs
> > propertiary binary.
> 
> Yup you are correct.  However for the foreseeable future, you can still
> do a git clone from github, and you can still use your local repository
> normally.  In fact I think this is really part of the github workflow.
> But who knows what the future will bring.  I can sure see the wisdom of
> the GPLv3 as we move into a world of software as a service, where even
> Microsoft uses Linux, and charges us for it.


about:
> PPL will forget how to use git without github.

We cannot forget what we never learned. 

git is way to complicated for regular users without support like what github provides.

I haven't done a merge without the Green Button in a long time. And when I did I always had to triple check to make sure to avoid any mistakes.
I never needed to check what a pull request would be in pure git.

Josef

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

#101251 — Re: GitHub's “pull request” is proprietary lock-in

W dniu 04.01.2016 o 18:41, Michael Torrie pisze:
>> Decade ago, I had plenty of friends on my jabber contacts list. Next,
>> > Google made it's talk compatible with jabber, then my friends slowly
>> > migrated to gtalk, because if they used gmail anyway, then why not use
>> > it also for jabber?
>> > 
>> > And then Google turned off XMPP support and suddenly I lost ability to
>> > contact with 80% of my friends without having stupid hangouts running,
>> > or without falling back to email (which is not so bad BTW).
> I use gtalk with Pidgin every day using XMPP.  So Google still supports
> XMPP.  However what they stopped doing was allowing federated XMPP,
> which pretty much breaks XMPP, at least the spirit of it.  So the only
> way to chat with gtalk users is to use your gtalk account.  

Exactly. My friends slowly migrated to using gtalk instead of jabber
client, because if they have open gmail anyways, then why should they
bother with installing additional software. 80% never came back to
jabber client. They don't need to, they still have communication between
them and I'm minority which uses strange not supported technology :).

> But you
> certainly don't need hangouts.  XMPP works fine between your client and
> the Google server.

Oh, and it's definitively what I want - talk with google server ;).

> 
> I agree that Google really pulled a bad one with gtalk though.  Dropping
> federated XMPP support was definitely not in keeping with their original
> "do no evil" mantra.
> 
>> > The same can be with Github and git. PPL will forget how to use git
>> > without github. When Github will make git-incompatible changes, vast
>> > majority will need/want to follow the changes and eg. will use Gitlabs
>> > propertiary binary.
> Yup you are correct.  However for the foreseeable future, you can still
> do a git clone from github, and you can still use your local repository
> normally.  

And I can do nothing with it, because nobody will want to cooperate with
me - they will use github instead of git.

Sad thing is that it's rather inevitable and not moving python repo to
github or not won't stop the process. However - wise would be to have
github-like software on own servers.

p. m.

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

#101222 — Re: GitHub's “pull request” is proprietary lock-in

Just as a general comment, I note there are now at least four mangled
versions of this subject header, and threading is already fragile enough
on this list.  I think in the future it would be best to avoid non-ASCII
characters in subject lines.

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

#101229 — Re: GitHub's “pull request” is proprietary lock-in

On 01/03/2016 05:51 PM, Random832 wrote:
> Just as a general comment, I note there are now at least four mangled
> versions of this subject header, and threading is already fragile enough
> on this list.  I think in the future it would be best to avoid non-ASCII
> characters in subject lines.

I noticed this too. Though threading based on message-id is working
quite well, as designed!

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

#101231 — Re: GitHub's “pull request” is proprietary lock-in

Michael Torrie <torriem@gmail.com> writes:
> I noticed this too. Though threading based on message-id is working
> quite well, as designed!

It doesn't work as well here as elsewhere, though, because message-ids
get rewritten by the usenet gateway, so the IDs referenced in people's
headers differ depending on whether they're replying via usenet or the
mailing list or gmane.  Threads already get mangled enough by this even
when the subject stays the same.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web