Re: debian github organization ?
Ben Caradoc-Davies b...@transient.nz writes: On 19/07/15 23:36, Florian Weimer wrote: The single account policy means that users would have to share authentication information across different roles, which may not be acceptable. I am not sure why this would be unacceptable to anyone. Authentication is your ability to prove who you are. GitHub accounts provide this. Authorization is your permission to commit to repositories. Your authorization to commit to one repository has no effect on other repositories to which you have commit access. I can very well see how this could be an issue to some. I at least keep a relatively strict separation between my work-related accounts and everything I do privately. That obviously applies to ssh keys for me. A security breach at work will not compromise my Debian access tokens, and vice versa. While this is pretty obvious to me regarding ssh keys, if that doesn't do it for you yet, try imagining to have the same *password* for your work and Debian accounts. These are things that should be avoided IMO. And if you are forced to share a GitHub account across organisations, you loose your ability to have a bit of separation. -- CYa, ⡍⠁⠗⠊⠕ pgpqGPN1ACkfv.pgp Description: PGP signature
Re: debian github organization ?
* Jérémy Lal: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lheciif3@mid.deneb.enyo.de
Re: debian github organization ?
* Andrew Shadura: On 19 July 2015 at 11:52, Florian Weimer f...@deneb.enyo.de wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github. That's not true, you can have organisations and teams. Please read what I wrote. The single account policy means that users would have to share authentication information across different roles, which may not be acceptable. (You could argue that organization objecting to such sharing should pay for an account for their users, though.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87si8kfkgs@mid.deneb.enyo.de
Re: debian github organization ?
On 19/07/15 21:52, Florian Weimer wrote: * Jérémy Lal: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github. GitHub organizations are free for open source, and each GitHub user can be a member of multiple unrelated organizations: https://github.com/blog/674-introducing-organizations -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ab84f4.8080...@transient.nz
Re: debian github organization ?
* Ben Caradoc-Davies: On 19/07/15 21:52, Florian Weimer wrote: * Jérémy Lal: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github. GitHub organizations are free for open source, and each GitHub user can be a member of multiple unrelated organizations: https://github.com/blog/674-introducing-organizations I am aware of that, and it's not what I'm concerned about. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uacgzuv@mid.deneb.enyo.de
Re: debian github organization ?
On 19 July 2015 at 11:52, Florian Weimer f...@deneb.enyo.de wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github. That's not true, you can have organisations and teams. -- Cheers, Andrew -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CACujMDN1j8M+jsHPQw1Yza=cuafprsghnac1qnciht0kq6j...@mail.gmail.com
Re: debian github organization ?
On 19/07/15 23:18, Florian Weimer wrote: * Ben Caradoc-Davies: On 19/07/15 21:52, Florian Weimer wrote: * Jérémy Lal: i was wondering if debian had a github account as an organization, where maintainers could be added. Github has a single-account-per-person policy (unless you pay, I think), so for those of us with multiple affiliations, it is difficult to join a Debian organization on Github. GitHub organizations are free for open source, and each GitHub user can be a member of multiple unrelated organizations: https://github.com/blog/674-introducing-organizations I am aware of that, and it's not what I'm concerned about. You are correct on single-account-per-person: GitHub terms of service include: One person or legal entity may not maintain more than one free account. https://help.github.com/articles/github-terms-of-service/ What is your concern? That membership of an organization may be construed as endorsement, copyright ownership, or other status of a third-party with whom you have a relationship? These are governance concerns outside the scope of GitHub workflow. Contributors to any project must consult their contracts, employment agreements (for employees), or terms of service (for statutory office holders), and obtain clearance in writing as necessary. Some obligations extend beyond the workplace. Some of your rights cannot be infringed by your employer (right to attribution). Even if GitHub permitted multiple accounts, this would not solve the underlying real world problem. GitHub organizations just make it easier to manage the mechanics of granting access to repositories. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ab935a.8020...@transient.nz
Re: debian github organization ?
On 19/07/15 23:36, Florian Weimer wrote: The single account policy means that users would have to share authentication information across different roles, which may not be acceptable. I am not sure why this would be unacceptable to anyone. Authentication is your ability to prove who you are. GitHub accounts provide this. Authorization is your permission to commit to repositories. Your authorization to commit to one repository has no effect on other repositories to which you have commit access. If your GitHub account were granted membership of a Debian organization, how would that affect third parties in a way that might be of concern to them? I am interested to know if you have experienced such a case. (You could argue that organization objecting to such sharing should pay for an account for their users, though.) Indeed. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ab9670.7020...@transient.nz
Re: debian github organization ?
Ben Caradoc-Davies writes (Re: debian github organization ?): On 19/07/15 23:36, Florian Weimer wrote: The single account policy means that users would have to share authentication information across different roles, which may not be acceptable. I am not sure why this would be unacceptable to anyone. Authentication is your ability to prove who you are. GitHub accounts provide this. You're talking as if what is identified is a human being. But of course, it isn't. When you do a git push (or whatever) what is pushed is controlled by the computer you are using. I would not want to use my workstation at work to push to Debian. Nor would I want to have to feed all the pushes I would do during my job through my netbook so they can be appropriately authorised. The github authorisation is in terms of ssh keys. I have ssh keys that live on my workstation at work. And I have ones that live on my own infrastructure. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21932.15961.964701.620...@chiark.greenend.org.uk
Re: debian github organization ?
On 20/07/15 12:18, Ian Jackson wrote: Ben Caradoc-Davies writes (Re: debian github organization ?): I am not sure why this would be unacceptable to anyone. Authentication is your ability to prove who you are. GitHub accounts provide this. You're talking as if what is identified is a human being. But of course, it isn't. When you do a git push (or whatever) what is pushed is controlled by the computer you are using. Of course. Humans lack a network interface. Authentication is the process whereby humans use tools they control to prove their identity. The integrity of these tools, the degree of control, and the care with which these tools are used appears to be your concern. I would not want to use my workstation at work to push to Debian. Nor would I want to have to feed all the pushes I would do during my job through my netbook so they can be appropriately authorised. What is your concern? That your workstation might be misused or compromised by someone in your workplace? Key logger? Remote access snooping? And that this compromise might be used for malicious purposes against Debian? The github authorisation is in terms of ssh keys. I have ssh keys that live on my workstation at work. And I have ones that live on my own infrastructure. GitHub recommend using SSH key passphrases, which provide a degree of protection against machine compromise: https://help.github.com/articles/working-with-ssh-key-passphrases/ Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ac4db4.4010...@transient.nz
Re: debian github organization ?
Ben Caradoc-Davies b...@transient.nz writes: On 20/07/15 12:18, Ian Jackson wrote: You're talking as if what is identified is a human being. But of course, it isn't. When you do a git push (or whatever) what is pushed is controlled by the computer you are using. Of course. Humans lack a network interface. Authentication is the process whereby humans use tools they control to prove their identity. The integrity of these tools, the degree of control, and the care with which these tools are used appears to be your concern. Er, you're responding to Ian as if you've never before heard of the concept of using separate authentication credentials for different purposes, but this is a very old and respected technique and a standard security approach. It's a form of privilege separation and roles? Consider, for example, having entirely separate work and personal computing hardware with separate keys. (I highly recommend anyone who isn't self-employed do the latter, btw. It keeps things much simpler, particularly if you change employers.) I wouldn't care that there is only one GitHub account if I was able to designate separate keys for different purposes and control which of them can commit to which repositories. That way, systems can be kept isolated from each other and not have credentials to commit to repositories that are inappropriate for that system. There are some repositories that I would want to treat with a much higher level of care and only allow access from specific hosts. What is your concern? That your workstation might be misused or compromised by someone in your workplace? Key logger? Remote access snooping? And that this compromise might be used for malicious purposes against Debian? Yes, all those things, and innumerable other ways of attacking hosts. GitHub recommend using SSH key passphrases, which provide a degree of protection against machine compromise: https://help.github.com/articles/working-with-ssh-key-passphrases/ Which protects only against a tiny fraction of those attacks. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87si8jbkzy@hope.eyrie.org
Re: debian github organization ?
On 20/07/15 14:50, Russ Allbery wrote: Er, you're responding to Ian as if you've never before heard of the concept of using separate authentication credentials for different purposes, but this is a very old and respected technique and a standard security approach. It's a form of privilege separation and roles? Consider, for example, having entirely separate work and personal computing hardware with separate keys. (I highly recommend anyone who isn't self-employed do the latter, btw. It keeps things much simpler, particularly if you change employers.) The first post in this thread noted that GitHub permit only a single free account per person, which precludes the use of separate accounts for separate roles (unless paid accounts are purchased, as was also noted earlier). My remarks are in this context. The problem with per-role accounts is the loss of connection and reputation on loss of account. The growth of social media and social coding is changing the workplace. No longer is a role associated with a job. Rather, reputation and authority follow individuals. This is a shock to corporate culture, who are just going to have to suck it up and adapt. The world has changed. Consider the growth of Bring Your Own Device. Do you also discard your Google, StackExchange, and LinkedIn profiles when you change jobs? I think not. GitHub is no different. The downside for workers is the blurring of the boundary between work and private life, and the need for careful identity and professional reputation management. The adaptation for business is access control that is not based on the business owning the identity of an employee. In any case, I think it would be great to have one or more Debian organizations on GitHub. A decent technology that can ease collaborative development by building maintainer teams. I acknowledge the identity management and security concerns raised on this list as valid, but they need not prevent use of GitHub organizations. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ac6a36.1040...@transient.nz
Re: debian github organization ?
Ben Caradoc-Davies b...@transient.nz writes: The problem with per-role accounts is the loss of connection and reputation on loss of account. The growth of social media and social coding is changing the workplace. No longer is a role associated with a job. Rather, reputation and authority follow individuals. This is a shock to corporate culture, who are just going to have to suck it up and adapt. The world has changed. Consider the growth of Bring Your Own Device. Do you also discard your Google, StackExchange, and LinkedIn profiles when you change jobs? I think not. GitHub is no different. I get what you're saying (although yes, of course I discard my Google profile when I change jobs -- duh). And indeed it's nice to have ones contributions follow one in GitHub. However, this is entirely orthogonal to Ian's point, which is that this model is inherently insecure. A model where you can spin off separate commit identities for one institutional identity would be ideal. Failing that, people do use multiple accounts because security is more important than coherent identity for their application. In any case, I think it would be great to have one or more Debian organizations on GitHub. Debian's primary objection to GitHub has nothing to do with the questions of identity. I think that was just a side comment. GitHub is not free software. Debian is never going to get past that (nor should it). There are lots of great platforms and great applications out there that aren't free software, but that's not the role that Debian plays in the world. The whole *point* of this project is to develop and use free software. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877fpvbh0t@hope.eyrie.org
Funding FusionForge development for missing features on Alioth (like pull request) - Was: Re: debian github organization ?
Hi. Olivier Berger ober...@debian.org writes: Russ Allbery r...@debian.org writes: That said, something more akin to GitHub (including the nice integration API and fork/pull model) running on a service like Alioth would be very neat. Feel free to add to : - https://fusionforge.org/tracker/index.php?func=detailaid=741group_id=6atid=114 Btw, it may be that FF already supports bits necessary for pull requests and the tracker item is just outdated ;) Sorry, I'm lagging too much behind. Having asked upstream during today's FusionForge meeting, it seems no one is currently working on implementing pull-request + merge workflows on FusionForge which could be as convenient as GitHub's. So the ticket pointed above is unfortunately up to date. It is on the roadmap to (discuss how/what, at least) though. It also seems that some sponsoring of upstream FusionForge development could help. If Debian has money to spend, I guess we have good contacts to upstream developers that may happily accept to job (not speaking of myself, in case it isn't clear). Any comments ? Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mo5sp2t@inf-11879.int-evry.fr
Re: debian github organization ?
On Apr 22, 2015, at 11:01 AM, Paul Wise wrote: Seems to work fairly well, certainly it is robust enough to not have 500 Internal Server Errors. File a bug? :) Cheers, -Barry pgp393q5a3UIo.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Thursday 16 April 2015 08:34 PM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net http://gitlab.debian.net :) gitlab folks are willing to sponsor gitlab.debian.net I will try to take that offer forward. signature.asc Description: OpenPGP digital signature
Re: debian github organization ?
Russ Allbery r...@debian.org writes: That said, something more akin to GitHub (including the nice integration API and fork/pull model) running on a service like Alioth would be very neat. Feel free to add to : - https://fusionforge.org/tracker/index.php?func=detailaid=741group_id=6atid=114 Btw, it may be that FF already supports bits necessary for pull requests and the tracker item is just outdated ;) Sorry, I'm lagging too much behind. My 2 cents, Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4llled4@inf-11879.int-evry.fr
Re: debian github organization ?
Hi, * Pirate Praveen prav...@onenetbeyond.org [2015-04-21 20:24:09 +0530]: On Thursday 16 April 2015 08:34 PM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net http://gitlab.debian.net :) gitlab folks are willing to sponsor gitlab.debian.net I will try to take that offer forward. I sure hope that won't mean getting Debian onboard the proprietary edition of their software, but rather them helping the proper packaging of their software. Cheers, -- Nicolas Dandrimont BOFH excuse #82: Yeah, yo mama dresses you funny and you need a mouse to delete files. signature.asc Description: Digital signature
Re: debian github organization ?
On Apr 16, 2015, at 07:19 PM, Andrew Shadura wrote: I'd rather see gitlab.debian.net :) Why Gitlab when there's Kallithea? :) Kallithea is under consideration as forge for upstream Python: http://legacy.python.org/dev/peps/pep-0462/ Cheers, -Barry pgpxAfgqu1BlU.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 16, 2015, at 11:13 PM, Russ Allbery wrote: Launchpad, similarly, is probably suffering a lot from the decision to only support bzr. That will probably be solved soon. From watching the commits to Launchpad trunk, it looks like git support is progressing nicely. I expect after some reasonable amount of testing it will land in production. I'm quite looking forward to it, as I think the Launchpad bug tracker is really nice. I love being able to create multiple bug tasks for a single bug targeting multiple versions and projects. Cheers, -Barry pgpKZK1RmqAfa.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Apr 16, 2015, at 09:04 AM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net :) +1 I've started moving my personal projects to gitlab and like it a lot. Cheers, -Barry pgpEtXwHRd4zO.pgp Description: OpenPGP digital signature
Re: debian github organization ?
It will be an instance of gitlab CE, under MIT license and managed by Debian. Gitlab folks will just sponsor the hosting. Nicolas Dandrimont എഴുതി: Hi, * Pirate Praveen prav...@onenetbeyond.org [2015-04-21 20:24:09 +0530]: On Thursday 16 April 2015 08:34 PM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net http://gitlab.debian.net :) gitlab folks are willing to sponsor gitlab.debian.net I will try to take that offer forward. I sure hope that won't mean getting Debian onboard the proprietary edition of their software, but rather them helping the proper packaging of their software. Cheers, -- Nicolas Dandrimont BOFH excuse #82: Yeah, yo mama dresses you funny and you need a mouse to delete files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1429672743241.c656ee42a5b94@mozgaia
Re: debian github organization ?
Awesome that you are considering to move to Git. GitLab B.V. would be more than happy to help with gitlab.debian.net and pay for the hosting. This in collaboration with volunteers such as Praveen and while ensuring that Debian is fully in control. Best regards, Sytse 'Sid' Sijbrandij CEO GitLab B.V. On Tue, Apr 21, 2015 at 2:21 PM, Barry Warsaw ba...@python.org wrote: On Apr 16, 2015, at 11:13 PM, Russ Allbery wrote: Launchpad, similarly, is probably suffering a lot from the decision to only support bzr. That will probably be solved soon. From watching the commits to Launchpad trunk, it looks like git support is progressing nicely. I expect after some reasonable amount of testing it will land in production. I'm quite looking forward to it, as I think the Launchpad bug tracker is really nice. I love being able to create multiple bug tasks for a single bug targeting multiple versions and projects. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cajtzhg-icncupem7wuhiyvrih+q40ugs2whu3b8kxykti7x...@mail.gmail.com
Re: debian github organization ?
On Wed, Apr 22, 2015 at 4:23 AM, Barry Warsaw wrote: On Apr 16, 2015, at 09:04 AM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net :) +1 I've started moving my personal projects to gitlab and like it a lot. I don't like it due to the JavaScript requirement, many things just give 500 Internal Server Error unless you have JS turned on. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Gua+1HDrjy8fuV6Se3hW+tPhFos_26Jfv1t3i29=e...@mail.gmail.com
Re: debian github organization ?
On Apr 22, 2015, at 10:40 AM, Paul Wise wrote: I don't like it due to the JavaScript requirement, many things just give 500 Internal Server Error unless you have JS turned on. Can you navigate github without JS? Cheers, -Barry pgp2Hk9JVhtjQ.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Wed, Apr 22, 2015 at 10:47 AM, Barry Warsaw wrote: Can you navigate github without JS? Seems to work fairly well, certainly it is robust enough to not have 500 Internal Server Errors. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6e4bvss4khcw4pm_latauh5xcmcer0t0sfcgevwsv7...@mail.gmail.com
Re: debian github organization ?
On Tue, Apr 21, 2015 at 05:41:56PM +0200, Nicolas Dandrimont wrote: I sure hope that won't mean getting Debian onboard the proprietary edition of their software, but rather them helping the proper packaging of their software. +1 And, besides, we should have by now all learned that 3rd party hosting is not a strategically smart move, with all the forges closing down these days. If anything, we should run our own GitLab (or Kallithea, FWIW). Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: debian github organization ?
On Apr 18, 2015, at 02:56 PM, Stuart Prescott wrote: arch 7 bzr199 cvs11 darcs 832 git12439 hg 65 mtn23 svn3593 I hope at some point soon after Jessie is released that the DPMT will officially switch from svn to git. Cheers, -Barry pgpZjFyDVmRKn.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Sun, 19 Apr 2015 at 18:25 Vincent Bernat ber...@debian.org wrote: This is not the case anymore. Deleting a branch leaves the pull request as is. Also, editing commits leave the history of the pull request in the timeline. Comments on edited commits are also still accessible. Oh, if that is the case that is really good. I will have to try it out sometime. I suspect not many people know about this however (did I miss an announcement from github on this?), and I suspect it may not be possible to make changes to the pull request without write access to the branch. Unlike with gerrit, where I believe is possible to other people to post improved versions of the patch.
Re: debian github organization ?
On Sat, 2015-04-18 at 12:07 +0200, Jérémy Lal wrote: gitg is quite good for simple tasks. I'm guessing it isn't good enough to be a replacement for the github web UI though and that there is no equivalent free software desktop UI. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: debian github organization ?
On 17 April 2015 at 18:13, Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Thankfully, git is by far the best VCS on the market and the vast majority of people seem to agree. But imagine the outcry if ten years ago Sourceforge had said our VCS is svn and we don't support anything else. Er, they did, didn't they? I could have sworn that they only supported CVS initially, and then only added Subversion, and getting Git support took forever. Launchpad, similarly, is probably suffering a lot from the decision to only support bzr. (It suffers from some other things as well, such as asset licensing and how difficult it is to stand up your own, but I think the VCS is a major problem right now.) https://dev.launchpad.net/Code/Git - git support is there in nascent form now and under active development. I think a couple of months will see it looking pretty solid. So you're of course right -- there's a tradeoff. However, I still stand by the decision to only support a single VCS, at least when you start, because you can move a lot faster and implement a lot more functionality that people care a great deal about. If you can find the right VCS to use that 90% of people are content with (and I think Sourceforge started there), I think your resources are much better put into adding other features than adding more VCS support. I have no interest in ever using bzr again, but I strongly suspect Launchpad got a lot farther and does a lot more because the choice was made to only support bzr. Now, of course, they need to switch to Git, or at least support it, and that's going to be a ton of work, but I suspect the order in which they did that made for a better system in the long run than if they'd tried to support both bzar and Git (and Mercurial and the other ones that were looking viable) at the start. When Launchpad started before bzr or git or hg existed - back in 2004 - we started with arch. When we started bzr as a project, (again, before git or hg :)) we were doing it with lessons-learnt from arch, and a clear picture about what we'd need from the web site. Our intention then was to use repository conversions to get content into Launchpad, rather than being polyglot - because polyglot implies a raft of tradeoffs. In hindsight, what that strategy actually did was make high fidelity incremental imports a key success factor, and that has itself a raft of tradeoffs - so we spent a huge chunk of effort on that (and its there and working) - but I think now that taking a federated approach for the non-hosting needs (read from X systems directly for building etc) would have been a lot faster to deliver, and would have allowed more of the VCS work to focus on hosting needs rather than conversion needs - conversions could be scaled out amongst users wanting to use the platform, rather than the platforms developers. OTOH a chunk of the planned features around VCS driven builds were tightly coupled on understanding branches within the VCS and triggers on changes etc - but all of those could have been only supplied for hosted branches, with a low code complexity cost. Actively supporting hosting of multiple VCSs would have been a huge distraction in 2005 when the explosion happened. Supporting a VCS for hosting isn't as simple as just parsing the output of $tool log. Users need support. They need documentation and assistance. Creating repositories needs to ask what VCS type to use in addition to any other questions needed, all such questions tend to decrease the % of users that get through the become-a-user funnel. You need backup glue that works with [whatever] mechanism the VCS has to deliver atomic commits. You need a scale-out strategy that is suitable for the VCS in question. You need a user model that works for that VCS (and some are radically different to others) - darcs was very visible at the time we started, for one of the most different-to-mainline-VCS models. Lastly at that stage LP was not yet open source, so it simply wasn't possible for possible users to scratch their own itch and submit patches - and thus when assessing strategy we assumed we'd have to write everything, so supporting two systems really need to get twice as much utility for Ubuntu developers (the primary audience then) - but Ubuntu had already decided to standardise on a single VCS, as part of the basic design of the tooling, there was no expectation of increased utility. -Rob -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tjj5lle@hope.eyrie.org -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Re: debian github organization ?
On 18 April 2015 at 08:03, Ben Finney ben+deb...@benfinney.id.au wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? It doesn't deny it at all. Writing code is inherently distributed - folk do it on their local machines. Other artifacts of software development, like this mailing list and the Debian BTS, are inherently centralised: they are discussions between actors, not local output. Upstream is using a decentralised VCS, it seems a little condescending to assume they are incapable of using it. As has already been said, noone is making that assumption. For all intents and purposes every upstream has made a decision about code review and patch acceptance processes[*] and patches that don't follow those processes incur a higher cost and increased likely hood of being ignored. Those processes end up something like this: - your patch should apply to branch X in repo Y before you send it. - put your patches in place Z for us to find them [e.g gerrit at url U, PR's at url U, mailing list x-...@example.com]... - we'll discuss the patch using tool T Absolutely none of those three things are distributed in nature. They can be worked with with distributed tooling, but that is beside the point - to work with upstream U, requires *working with upstream U*, whatever their tooling is, wherever they are to be found. That is in fact exactly what upstream means. Of course, some upstreams don't document the process super-well, and some are more restrictive than others (e.g. hg won't accept patches in their bug database - patches have to go to the list). But there is a process, and its tuned for the bottleneck that that project has. To pick a specific example, if you want to get a patch into OpenStack you *must*: - sign up for the OpenStack gerrit system - sign a CLA - put your patch into git and push it into gerrit Anything else simply won't be accepted. *: A very very small number say 'any patch anywhere, we'll handle the rest', or something similar. -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ3HoZ0yS=gteouknvpsr9c_tsekk2rufyvvcgmqq74a6e_...@mail.gmail.com
Re: debian github organization ?
On Sun, 19 Apr 2015 21:12:57 +1200 Robert Collins robe...@robertcollins.net wrote: On 18 April 2015 at 08:03, Ben Finney ben+deb...@benfinney.id.au wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. To pick a specific example, if you want to get a patch into OpenStack you *must*: - sign up for the OpenStack gerrit system - sign a CLA - put your patch into git and push it into gerrit Anything else simply won't be accepted. Indeed, this is precisely why - in Linaro - we chose to push LAVA upstream repos to github as mirrors just so that contributors did not need to register for a Linaro account but could use an existing github account. We've already received useful contributions via github and so support will continue. Those who choose to or who make regular contributions are, of course, welcome to register for a Linaro community account and submit directly to review.linaro.org, the gerrit instance for Linaro. An account isn't a big deal but as there is a trivial way of allowing contributions without it, we thought it would be daft not to use github as an upstream mirror - I don't even need to explicitly push to it. We were asked to do it by github users, we are happy to oblige as the setup is trivial and it just works. (So I'm in Linaro and Debian organisations now on github. Yay!) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp92vtlLHcr9.pgp Description: OpenPGP digital signature
Re: debian github organization ?
❦ 19 avril 2015 08:55 GMT, Brian May br...@microcomaustralia.com.au : I suspect not many people know about this however (did I miss an announcement from github on this?), and I suspect it may not be possible to make changes to the pull request without write access to the branch. Yes, that's not possible. Unlike with gerrit, where I believe is possible to other people to post improved versions of the patch. People can still clone the branch and do their own PR, referencing the original one. -- Use the fundamental control flow constructs. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: debian github organization ?
❦ 19 avril 2015 07:34 GMT, Brian May br...@microcomaustralia.com.au : Unfortunately, github pull requests have limitations compared with patches, archived for example on a mailing list. For blog post on this see: https://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation IIRC, my understanding is that creating a patch request means you can't ever delete the branch associated with the pull request or you can't see the patch any more from the pull request. Yes, the patch request remains important even after the patch has been merged, because it can include discussions on how a particular set of decisions was made concerning the change in question. This is not the case anymore. Deleting a branch leaves the pull request as is. Also, editing commits leave the history of the pull request in the timeline. Comments on edited commits are also still accessible. -- Make it clear before you make it faster. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: debian github organization ?
On Sat, 18 Apr 2015 at 18:01 Neil Williams codeh...@debian.org wrote: The github pull request is just a nice UI over a patch. What on earth is wrong with that? Unfortunately, github pull requests have limitations compared with patches, archived for example on a mailing list. For blog post on this see: https://julien.danjou.info/blog/2013/rant-about-github-pull-request-workflow-implementation IIRC, my understanding is that creating a patch request means you can't ever delete the branch associated with the pull request or you can't see the patch any more from the pull request. Yes, the patch request remains important even after the patch has been merged, because it can include discussions on how a particular set of decisions was made concerning the change in question. Also worth noting that, while git is a distributed service, some of the services github provides are not distributed, most notably the issue tracker and pull requests (not sure it is possible to disable pull requests). You can only get these discussions from the central github server and emails from the server. If github went down you would lose all this information (yes, you can back it up - does anyone do so?) (side note: github's wiki is based on git and open source software - gollum - so can - at least in theory - be distributed. Although last I checked open source software had features not implemented in github because github was using an old version of gollum - not sure if that is still the case or not; at the time it meant my pages didn't work both in guthub and gollum at the same time) I am not saying that we should not use github - I use it all the time (with and without gerrit), however we should be aware of its limitations.
Re: debian github organization ?
On Sat, 18 Apr 2015 18:04:40 +0800 Paul Wise p...@debian.org wrote: On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: git won the DVCS argument a long time ago. github won the DVCS UI argument a long time ago - it is clearly the one UI that the largest number of git contributors actually want to use. Are there any good DFSG-free desktop UIs for git? For desktop UI, I find qgit to be usable. However, that's just for viewing branches, diffs and history - contributions need to come via something off desktop and qgit does little to help me when reviewing patches submitted by others beyond what I would see anyway with a web-based diff frontend or the superb 'meld'. (I don't know where I would be without conflict resolution support in meld - big *thank you* to the meld maintainers upstream - I grew to like meld when I was on svn, it has become even more important and useful with git). So I should clarify that, github won the DVCS web UI ... it's contribution support and repository creation / browsing / searching support is far better than any of the other tools I have to use (command-line, desktop or web). Integration with an issue tracker actually works when most alternatives do not, the wiki is fast, usable and has a nicer rendering than any other wiki I regularly use. I also look at github and sites like it when planning how to implement new web UI features in my own free software. More important than all that, it's where the users are. It's a circular argument, I know, but I use it because that's where people expect to find stuff and where people expect to be able to contribute. TBH I'm far from worried about a web service like github being run on non-free software. It's not the sole source for anything I care about, it provides a useful service to me but if it went away, meh, it went away - I'd just have to find out where the users went and probably follow. It's not that github is the best possible answer, it is the best current answer and has a large, interested, user base. It's primarily the user base that matters, the UI support is very good but secondary to me. Ignoring or snubbing github won't affect github or reduce it's usefulness to others - it will just cut off a possibly interesting source of new contributors. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5UNEbc4czE.pgp Description: OpenPGP digital signature
Re: debian github organization ?
2015-04-18 12:16 GMT+02:00 Dmitry Smirnov only...@debian.org: On Sat, 18 Apr 2015 12:07:22 Jérémy Lal wrote: Are there any good DFSG-free desktop UIs for git? gitg is quite good for simple tasks. 0.2.7 is still good but unfortunately upstream ruined newer versions... :( I guess it's a matter of taste. I like gitg + meld + gedit (with git plugin) all at ~ 3.14.
Re: debian github organization ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/18/2015 01:09 PM, Neil Williams wrote: On Sat, 18 Apr 2015 18:04:40 +0800 Paul Wise p...@debian.org wrote: On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: git won the DVCS argument a long time ago. github won the DVCS UI argument a long time ago - it is clearly the one UI that the largest number of git contributors actually want to use. Are there any good DFSG-free desktop UIs for git? For desktop UI, I find qgit to be usable. However, that's just for viewing branches, diffs and history - contributions need to come via something off desktop and qgit does little to help me when reviewing patches submitted by others beyond what I would see anyway with a web-based diff frontend or the superb 'meld'. (I don't know where I would be without conflict resolution support in meld - big *thank you* to the meld maintainers upstream - I grew to like meld when I was on svn, it has become even more important and useful with git). So I should clarify that, github won the DVCS web UI ... it's contribution support and repository creation / browsing / searching support is far better than any of the other tools I have to use (command-line, desktop or web). Integration with an issue tracker actually works when most alternatives do not, the wiki is fast, usable and has a nicer rendering than any other wiki I regularly use. I also look at github and sites like it when planning how to implement new web UI features in my own free software. More important than all that, it's where the users are. It's a circular argument, I know, but I use it because that's where people expect to find stuff and where people expect to be able to contribute. TBH I'm far from worried about a web service like github being run on non-free software. It's not the sole source for anything I care about, it provides a useful service to me but if it went away, meh, it went away - I'd just have to find out where the users went and probably follow. It's not that github is the best possible answer, it is the best current answer and has a large, interested, user base. It's primarily the user base that matters, the UI support is very good but secondary to me. Ignoring or snubbing github won't affect github or reduce it's usefulness to others - it will just cut off a possibly interesting source of new contributors. So we now just need somehow make every DD (or DM or other packaging contributor) to package one dependency for Gitlab and then make gitlab.debian.net infrastructure and everyone is happy I guess. Cheers, zlatan - -- Its not the COST, its the VALUE -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVMkw3AAoJEC5cILs3kzv9OjMQAK0CyVxnzL/DvF19hNNDVOgD hBRh6VLrnryfKpcNTdIRpgvh9nRqKdhmoxB5AXK6ZblvCwVYxqJe0iT7qVek0a69 kjkC+nbkLqQzdMKrOMsbiH8qUKacW+sHAysMwy4EgGea/jRCp7QcSHBJ1YsgUOtq jZpTk1pBVwuPaVLTxn03VL6ZaWd3bDo6XZsmBoqhuk9Uw2y2pPWmTFcZcUfK5it7 BIddKBAHBiIpmF7d/00iVk4EGebAyYT8onEXE1ndZklqUPzlXaGjpmQsykCRIT+u 1KUqzhBXYdmczrjXJkGz74ILLJGWe16NXTBPqlp3XHFZZ3HjHuD9B2D5eUpj+5YB gg3cNweaLsq8HACXE28G6yszUhSkYIpFaTHb2X4ulyRZa1++Ac965gDbblSPphht /vw2+5oELq94J0soWjBvJeywS2YS/95lM10mCCUvKXHcvVTvdGmw4wmcz0V2QAi3 gR4BvQ/i1q1JAg0mJHzzI/Y6KLCpI9pSngRa3FjSwUNQ0YE0GFKgWu0rHfJugBUo db2IHrTbxkzxsQqYset9Yg9n4x5LfA0Y4JCwPEsOv9D/gDWI+1Mi0fuVl4ZNWiQP CXLjmo1Y+tnF+Smc4bw9EfbKHc8b9DBzf7cR64C6xceY7QQFz936YRr/Sdzej0oA rQKDvzmTyk2g2HFfR4rX =dAUO -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55324c37.6010...@riseup.net
Re: debian github organization ?
On Sat, 18 Apr 2015 06:03:12 +1000 Ben Finney ben+deb...@benfinney.id.au wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? I don't see the problem when it is used as just one remote amongst many. People like the github interface. That is unarguable. It does not matter one jot that some people don't like github for this reason or that. There are people (quite large numbers of people) who expect to find stuff on github and who prefer the UI. Having github as one of my remotes is extremely helpful. As Paul mentioned, I also prefer to *not* have my github remotes locked-away under a personal moniker as that makes it harder to add new admins etc. and it is project admins on github which make the whole point of github actually work. Upstream is using a decentralised VCS, it seems a little condescending to assume they are incapable of using it. That makes no sense at all. Upstream have their own git source but that is optimised to their needs (particular code review, access lists which need *everyone* to have yet another web account etc.) Nobody wants to have a hundred web accounts for every possible distributed VCS server. So having a few which act as mirrors for the plethora of local ones brings advantages that people are actually able to interact using a common UI. I have very little on github which is not simply a mirror of the primary git source used by upstream - but that is precisely the point. I'm using github (and now github.com/debian) precisely because the code is in a DVCS because github allows me to offer the one UI that most contributors seem to prefer at no cost to me, except maybe an extra git push command. Alioth cannot be another github, random other upstreams cannot be another github. Sourceforge well, just no really. Github is exactly that - a hub. Use it to push the code out from within the access constraints of a typical upstream project. It's easy for others to work with your code that way. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpZHUnBsDqgw.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Sat, 18 Apr 2015 00:01:29 +0100 Steve McIntyre st...@einval.com wrote: Ben Finney wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? We are not - however, there is good reason for everyone to not have to work with every git service on the net. Many to Many is worth doing, Every to Every is insane. There has to be somewhere where a number of small fry services push mirrors to make their code accessible to the many. We know this already from working with so many upstreams for Debian - some service needs to be a central mirror. Few projects can work with git entirely using patches on a mailing list. What works for one (admittedly large) user base does not work for all - even if it does work for the upstream team, it typically does *not* work for all potential contributors. Now with an extremely large project, that can be an advantage by actually acting as a barrier to entry. For smaller projects, there should be as low a barrier as possible. The simplest way to that goal is to push to github. I don't care what anyone thinks of github - that is the simple fact. If you want to make the barrier to entry of your upstream project as low as possible, you have to include github. It's actually a nice place to be and it's trivial to work with as a project admin too. That's why people use it - it's easy. By all means lock your own little projects into alioth or personal git servers but the reason to go to github is to make it easier for you and the contributors. It makes no sense to ignore that. git won the DVCS argument a long time ago. github won the DVCS UI argument a long time ago - it is clearly the one UI that the largest number of git contributors actually want to use. Agreed - it's really annoying to see everybody clamour for a centralised single point of of failure for git hosting. :-( Sorry, Steve, you've missed the point of github being just a hub of mirrored code. It actually does that extremely well, no other service even comes close. Github is just a centralised User Interface, nothing else. It is *the* UI that most people seem to want. It avoids users having to have hundreds of different web accounts and it is a simple hub. It's trivial to push another copy of the source to github and keep the primary source within the corporate access control server. That way, everyone gets a chance to work with you without registering for a corporate web account and upstream get to include github into their access-controlled review workflow. There's no reason for github to be the single remote for anyone with an alioth account - there is also absolutely no reason for anyone to *not* have a github remote for each of their upstream projects as one of a handful of remotes. Why use a DVCS if you are not going to have multiple remotes? github.com/debian is a very useful service and I intend to use it fully. I think a lot more Debian folk and a lot more upstream folk should too. It's a hub, use it as a hub, as one of your remotes. Why not use the biggest, easiest hub to reach the biggest number of potential contributors? What's not to like? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWHS151aLMJ.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Sat, 18 Apr 2015 11:44:34 +1000 Ben Finney ben+deb...@benfinney.id.au wrote: Russ Allbery r...@debian.org writes: Steve McIntyre st...@einval.com writes: Agreed - it's really annoying to see everybody clamour for a centralised single point of of failure for git hosting. :-( Funny, this is why I don't get why people are so upset that some use GitHub. Because of how Git works, the impact of lock-in is pretty much limited to the non-repository stuff (issues and so forth). Yet it is exactly those lock-in features that is the basis for arguments to put special effort into the centralised single point of failure. That just ignores the whole point of using github in the first place. github is *not* lock-in. It is the opposite of lock-in because it allows me to push free software from a locked-down corporate server to a mirror that makes it easier for me to accept contributions from people without those people needing to register with my particular corporate server. For example, the centralised proprietary GitHub “pull request” is presented as a reason to abandon a decentralised model: No - it is presented as a method of retrieving useful contributions which would not have been made via other methods. That contribution can then be reviewed, pushed to the internal corporate review frontend by one of the team whilst retaining the author details of the github user and that user then gets a listing in the corporate git master branch if the patch is accepted. The github pull request is just a nice UI over a patch. What on earth is wrong with that? Paul Tagliamonte paul...@debian.org writes: An entirely fair point, however, I also think it's quite rude to ignore the workflow they've chosen for contributions -- if they expect PRs, it might disrupt their workflow and result in a much harder time for them. So upstream have chosen a proprietary lock-in service for their workflow. That should not put any obligation on others to also submit to proprietary lock-in. That ignores the whole point of a DVCS - to have multiple remotes. This is about extending access, of removing lock-in. Pushing to github *increases* access, it does not invole lock-in on any level. I've chosen to offer github pull requests on all my free software because that allows me to access contributions which would otherwise be awkward to handle. The BTS, whilst excellent at so many things, is simply not designed to track git branches. One-off small patches, yes. Large changes which evolve over a period of time and keep track of changes elsewhere? umm, no - really, no and neither should it become so. Github provides that service and the people who are offering this code want to use it. Why would I refuse to use that service to open up my own locked-down server without the admin hassle of creating hundreds of new accounts? The people are already on github - if I want their contributions, what is the sense in *not* pushing to github as one of my remotes? -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp28uh41J1h7.pgp Description: OpenPGP digital signature
Re: debian github organization ?
On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: git won the DVCS argument a long time ago. github won the DVCS UI argument a long time ago - it is clearly the one UI that the largest number of git contributors actually want to use. Are there any good DFSG-free desktop UIs for git? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6g4whnsfobodah_hm40ons3zht57xggc-6zp1zplo3...@mail.gmail.com
Re: debian github organization ?
2015-04-18 12:04 GMT+02:00 Paul Wise p...@debian.org: On Sat, Apr 18, 2015 at 3:50 PM, Neil Williams wrote: git won the DVCS argument a long time ago. github won the DVCS UI argument a long time ago - it is clearly the one UI that the largest number of git contributors actually want to use. Are there any good DFSG-free desktop UIs for git? gitg is quite good for simple tasks.
Re: debian github organization ?
On Sat, 18 Apr 2015 12:07:22 Jérémy Lal wrote: Are there any good DFSG-free desktop UIs for git? gitg is quite good for simple tasks. 0.2.7 is still good but unfortunately upstream ruined newer versions... :( -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Re: debian github organization ?
First a Mel Cupa. I called the SourceForge system Apollo. It's actual name is Apache Allura. Brain fart. On Thu, 2015-04-16 at 23:13 -0700, Russ Allbery wrote: Er, they did, didn't they? I could have sworn that they only supported CVS initially, and then only added Subversion, and getting Git support took forever. Pretty much. Of course that may have something do with the respective VCS being born in that order. For comparison in the speed of addition, GutHub opened for business in April 2008. SourceForge added support for git in March 2009. However, I still stand by the decision to only support a single VCS, at least when you start, because you can move a lot faster and implement a lot more functionality that people care a great deal about. Woo, slow down there. Here I was thinking the discussion was about spinning up a server using exist software. Has the discussion moved to writing our own or even modifying something to suit Debian's needs? If so, is that justified by history? Was there a period when not only was Alioth's bug queue serviced, but we actually did some heavy lifting? If not than any discussion of adding functionality is probably fanciful. In any case using an existing project and contributing any changes upstream sounds like a much better plan to me - particularly if the project is packaged in Debian. They means we can just install auto upgrades to keep it secure. As for one DVCS to rule the world - that also sounds like a bit of a stretch. If we are going to do that, can we also settle on a preferred computer language and force everyone to use a single debian packaging method? It would make life sooo much easier. signature.asc Description: This is a digitally signed message part
Re: debian github organization ?
Marc Haber mh+debian-de...@zugschlus.de writes: Thankfully, git is by far the best VCS on the market and the vast majority of people seem to agree. But imagine the outcry if ten years ago Sourceforge had said our VCS is svn and we don't support anything else. Er, they did, didn't they? I could have sworn that they only supported CVS initially, and then only added Subversion, and getting Git support took forever. Launchpad, similarly, is probably suffering a lot from the decision to only support bzr. (It suffers from some other things as well, such as asset licensing and how difficult it is to stand up your own, but I think the VCS is a major problem right now.) So you're of course right -- there's a tradeoff. However, I still stand by the decision to only support a single VCS, at least when you start, because you can move a lot faster and implement a lot more functionality that people care a great deal about. If you can find the right VCS to use that 90% of people are content with (and I think Sourceforge started there), I think your resources are much better put into adding other features than adding more VCS support. I have no interest in ever using bzr again, but I strongly suspect Launchpad got a lot farther and does a lot more because the choice was made to only support bzr. Now, of course, they need to switch to Git, or at least support it, and that's going to be a ton of work, but I suspect the order in which they did that made for a better system in the long run than if they'd tried to support both bzar and Git (and Mercurial and the other ones that were looking viable) at the start. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tjj5lle@hope.eyrie.org
Re: debian github organization ?
On Thu, 16 Apr 2015 23:13:01 -0700, Russ Allbery r...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de writes: Thankfully, git is by far the best VCS on the market and the vast majority of people seem to agree. But imagine the outcry if ten years ago Sourceforge had said our VCS is svn and we don't support anything else. Er, they did, didn't they? I could have sworn that they only supported CVS initially, and then only added Subversion, and getting Git support took forever. Subversion came - in my memory - rather fast after becoming available. Only having CVS in the days when CVS was the only available VCS is excuseable. When git came, I was already away from Sourceforge. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yj0nb-0004il...@swivel.zugschlus.de
Re: debian github organization ?
Russell Stuart russell-deb...@stuart.id.au writes: On Thu, 2015-04-16 at 23:13 -0700, Russ Allbery wrote: However, I still stand by the decision to only support a single VCS, at least when you start, because you can move a lot faster and implement a lot more functionality that people care a great deal about. Woo, slow down there. Here I was thinking the discussion was about spinning up a server using exist software. Has the discussion moved to writing our own or even modifying something to suit Debian's needs? No. My comment was in the context of a comparison between Sourceforge and GitHub, and I was just making the point that I think this was a wise decision on GitHub's part. It was also in the context of a couple of other packages that are possible contenders for a revision control management framework, both of which have made the same choice, also (IMO) wisely. As for one DVCS to rule the world - that also sounds like a bit of a stretch. While we're pondering whether dropping support for older VCSes is a bit of a stretch, the broader software community is just shrugging and using GitHub. If the goal is to produce a viable free software alternative to GitHub, supporting Subversion or bzr or Mercurial would be nowhere on my list of requirements. Obviously, supporting a choice of DVCSes would be great, all other things being equal. But given the resources available for a free software project, all else is not going to be equal, and there are *lots* of other features that are a much higher priority for more developers than making the diminishing minority of people who don't use Git more comfortable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3rj4470@hope.eyrie.org
Re: debian github organization ?
On 16 Apr 2015 12:05 pm, Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: On Thu, 16 Apr 2015 09:04:07 -0600 Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) I don't a reason to have gitlab/github/someother git stuff for debian, since we already have alioth. Maybe someone can enlighten me. In no particular order: * merge proposals / code review. Mailing lists suck for this. And these webby tools usually support email based workflow as well (to some degree) * no approval required to create/fork projects, teams, source trees (there are namespaces) * syntax highlighted or rendered code browsing * familiar user interface / concepts for most developers * no arbitrary hooks, no direct file access to repositories, no repository maintainance for repository owner. (These are all good things) * restful API triggers to update things instead We are at the tipping point were more of active developers used git and e.g. github; than svn and source forge monsters. My first VCS was git repo.cz later quickly gitorious github. Regards, Dimitri.
Re: debian github organization ?
On Thu, Apr 16, 2015 at 6:37 PM, Sven Bartscher sven.bartsc...@weltraumschlangen.de wrote: I don't a reason to have gitlab/github/someother git stuff for debian, since we already have alioth. Maybe someone can enlighten me. I'd love to see the Debian infrastructure rely of Free software, firmware and hardware. However, we are not there yet. GitHub is widely popular and it has become the go-to place for many FOSS developers and *newcomers*. Many people seem to agree that Debian is not as visible and approachable as other projects. Unpleasant compromises are inevitable: we are running our infrastructure on some non-free hardware/firmware, we host the contrib and non-free archive areas, we fetch and package tarballs from GitHub. I would argue that the benefits of being on GitHub in terms of attracting new users and contributors outweighs the damage[1] When enabling the non-free archives, users are displayed a warning. Similarly, any Debian organization/repo on GH could be clearly marked as a non-official/mirror. [1] http://mako.cc/writing/hill-free_tools.html -- Federico -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cag4rqzyquvdaeoqgluufy9emft6rphwgk_zw-4_b93yt1gq...@mail.gmail.com
Re: debian github organization ?
On 04/16/2015 05:04 PM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net http://gitlab.debian.net :) or gitblit, which would be easier to integrate into ldap/sso/ssh imho. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5531146d.7050...@bzed.de
Re: debian github organization ?
Milan P. Stanic m...@arvanta.net writes: What about gitolite? It is in Debian, can be used with gitweb and have access control. N.B. I'm biased (maybe) because I use gitolite for my company repositories. gitolite is very nice insofar as it goes. I've used it a lot, and still use it in various places. But it and GitHub are fairly different things. It's just the repository management (with a very nice ACL system), and is the most useful if you're following a hub and spoke model for your repositories. If you want the whole pull request flow, code review, or the many nice API integrations with things like continuous build and test of proposed merges, gitolite doesn't really help. Another approach is Gerrit, which is very nice if you have an up-front code review requirement, but which is hard to package given its substantial Java dependencies. But the world seems to be moving more towards the GitHub pull and fork model than the Gerrit up-front code review model. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bnim3b8l@hope.eyrie.org
Re: debian github organization ?
On Fri, 2015-04-17 at 16:10, Bernd Zeimetz wrote: On 04/16/2015 05:04 PM, Dimitri John Ledkov wrote: I'd rather see gitlab.debian.net http://gitlab.debian.net :) or gitblit, which would be easier to integrate into ldap/sso/ssh imho. What about gitolite? It is in Debian, can be used with gitweb and have access control. N.B. I'm biased (maybe) because I use gitolite for my company repositories. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150417154449.ga12...@arvanta.net
Re: debian github organization ?
On a side note to this thread, GitLab packaging for Debian is happening silently (and of course slowly) in the Debian Ruby group. Anyone is welcome to help. :) On 17 April 2015 11:07:37 am IST, Marc Haber mh+debian-de...@zugschlus.de wrote: On Thu, 16 Apr 2015 19:40:21 -0700, Russ Allbery r...@debian.org wrote: Iustin Pop ius...@debian.org writes: I think the VCS agnosticism is actually detrimental in this context. It's much easier for the user when every repo is using the same VCS. And consistency makes it very easy, for example, to refer to commits across projects, to standardise pull/clone workflows, etc. +1. VCS agnosticism means you waste a bunch of time making each new feature work with every supported VCS, which can include trying to shoehorn pretty foreign workflows into the model of some other VCS. But it leaves a choice to the author. On a VCS-bound system, all choice you have is to go to a different place. Thankfully, git is by far the best VCS on the market and the vast majority of people seem to agree. But imagine the outcry if ten years ago Sourceforge had said our VCS is svn and we don't support anything else. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yiyy9-vg...@swivel.zugschlus.de -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: debian github organization ?
That's a very nice starting point! Maybe it's a good ideia, but I'm still asking myself why. And wanna ask you guys to answer the Jonathan Downland question bellow. On 17/04/15 13:06, Jonathan Dowland wrote: The real question is: what do we gain by hosting such things on github? The social stuff, pull requests, etc.? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/553152bd.4040...@me.com
Re: debian github organization ?
On Fri, Apr 17, 2015 at 03:36:45PM -0300, João Vanzuita wrote: And wanna ask you guys to answer the Jonathan Downland question bellow. On 17/04/15 13:06, Jonathan Dowland wrote: The real question is: what do we gain by hosting such things on github? The social stuff, pull requests, etc.? Uch, so I resubscribed to -devel -- it'd be nice to email the admins of the thing you're talking about to, well, ask them. I've been using it to create repos where I need to communicate with an upstream on GitHub (so that it's in the Project's namespace, so it's not locked up under github.com/paultag when I go missing), and I maintain mirrors of repos on git.debian.org (using a VCS sync script I wrote) to let new contributors send me patches. Lowing the barrier to entry, and helping them work with a different workflow (alioth, etc) once they feel comfortable contributing is much less intimidating. So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. I even wrote a GitHub Pull Request - format-patch series tool, but never deployed it. One day when I have all the time in the world :) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: debian github organization ?
Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? Upstream is using a decentralised VCS, it seems a little condescending to assume they are incapable of using it. -- \ “Friendship is born at that moment when one person says to | `\another, ‘What! You too? I thought I was the only one!’” —C.S. | _o__)Lewis | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/858udqsetb@benfinney.id.au
Re: debian github organization ?
On Sat, Apr 18, 2015 at 06:03:12AM +1000, Ben Finney wrote: Upstream is using a decentralised VCS, it seems a little condescending to assume they are incapable of using it. An entirely fair point, however, I also think it's quite rude to ignore the workflow they've chosen for contributions -- if they expect PRs, it might disrupt their workflow and result in a much harder time for them. Honestly, it might mean they pull it into one of their repos and make a PR to the canonical repo. Which is just making work for them. Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: debian github organization ?
On Fri, 2015-04-17 at 17:06 +0100, Jonathan Dowland wrote: On Thu, Apr 16, 2015 at 11:22:53PM +0800, mudongliang wrote: But I know that debian does not manager source code by git ! How can it?? Some people and teams in Debian do manage their package sources in git; others don't. I'm not sure what the stats are at the moment for the various approaches; there might be a UDD script already that generates some. I was interested in looking at this, once upon a time. The real question is: what do we gain by hosting such things on github? The social stuff, pull requests, etc.? I think hosting such things on github will encourage us to give a little contribution to Debian! Up to now , I don't know how to contribute to Debian,no matter what kind!Maybe I do not focus on it! mudongliang -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu436-smtp11004ad5e0a1a2f00d065f0bc...@phx.gbl
Re: debian github organization ?
Jonathan Dowland wrote: Some people and teams in Debian do manage their package sources in git; others don't. I'm not sure what the stats are at the moment for the various approaches; there might be a UDD script already that generates some. I was interested in looking at this, once upon a time. There is indeed a regular check of VCS usage: http://upsilon.cc/~zack/stuff/vcs-usage/ Which today lists: arch7 bzr 199 cvs 11 darcs 832 git 12439 hg 65 mtn 23 svn 3593 Source packages using some VCS: 17169 (75.37%) So that puts git as the declared VCS for 50% source packages (and leading the next most popular by almost a factor of 4). -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/mgso52$2rc$1...@ger.gmane.org
Re: debian github organization ?
On Thu, Apr 16, 2015 at 11:22:53PM +0800, mudongliang wrote: But I know that debian does not manager source code by git ! How can it?? Some people and teams in Debian do manage their package sources in git; others don't. I'm not sure what the stats are at the moment for the various approaches; there might be a UDD script already that generates some. I was interested in looking at this, once upon a time. The real question is: what do we gain by hosting such things on github? The social stuff, pull requests, etc.? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150417160611.ga13...@chew.redmars.org
Re: debian github organization ?
Ben Finney ben+deb...@benfinney.id.au writes: Russ Allbery r...@debian.org writes: Funny, this is why I don't get why people are so upset that some use GitHub. Because of how Git works, the impact of lock-in is pretty much limited to the non-repository stuff (issues and so forth). Yet it is exactly those lock-in features that is the basis for arguments to put special effort into the centralised single point of failure. For example, the centralised proprietary GitHub “pull request” is presented as a reason to abandon a decentralised model: Uh, a pull request isn't something proprietary. It was part of the design of Git from the beginning and is based on the workflow of the Linux kernel. What GitHub offers are some nice tools for managing those pull requests that reduces the friction considerably, just like they offer a nice web interface for viewing repositories. Those tools are useful, and I hope they'll be replicated in an open source framework for Git repository management, but they're not lock-in. You can do pull requests without GitHub (and in fact I've done a fair bit of that). So upstream have chosen a proprietary lock-in service for their workflow. That should not put any obligation on others to also submit to proprietary lock-in. Of course not. You don't have to use anything you don't want to use, and no one in this thread is advocating otherwise, at least that I've seen. All that I'd ask is that, if other people want to use GitHub, for you to not be an ass about it, the same way that we don't lecture people for using a proprietary editor to write free sofware. Some of us are willing to reach out to people who are using GitHub and give and take patches from them in their preferred way, particularly right now when there aren't a lot of compelling alternatives to point them to. If you aren't, that's perfectly fine; just please don't get in the way of us who are. There's a whole spectrum of difference within the project about how absolute people want to personally be about only using free tools. Some people are at the end of the spectrum with RMS and are investigating computers with fully free firmware, and more power to them. Other people are using non-free software for some things and free software for other things and are contributing the latter to Debian. And more power to them as well, since they're helping us build the free software community. Sometimes I wonder if people think free software is so fragile that if anyone who works on it ever touches non-free software, everything we built will crumble. I think our community and ecosystem is a lot more robust than that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874moe16n4@hope.eyrie.org
Re: debian github organization ?
Ben Finney wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? Agreed - it's really annoying to see everybody clamour for a centralised single point of of failure for git hosting. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com Every time you use Tcl, God kills a kitten. -- Malcolm Ray -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yjfgl-0003x0...@mail.einval.com
Re: debian github organization ?
Steve McIntyre st...@einval.com writes: Ben Finney wrote: Paul Tagliamonte paul...@debian.org writes: So, yes, it's nonfree. Yes, it's controlled by DDs. No, I don't think this should be the Vcs-Git: target. No, I don't think we should endorse GitHub. Yes, we need free tools. Yes, we should contribute to the F/OSS community where upstreams are. That last part seems to deny the D in DVCS. Why are we under such pressure to use one particular centralised service? Agreed - it's really annoying to see everybody clamour for a centralised single point of of failure for git hosting. :-( Funny, this is why I don't get why people are so upset that some use GitHub. Because of how Git works, the impact of lock-in is pretty much limited to the non-repository stuff (issues and so forth). I use GitHub for some things, largely because it makes it easy for people to contribute patches if they're used to that workflow, and it lets me take advantage of some services (like continuous integration builds) that I could but don't feel like building myself. I also push all my repositories to my own Git server with its own gitweb instance, so if GitHub disappears tomorrow, I don't lose anything of much note. Yes, it's a proprietary service and all, but not all proprietary cloud services are created equal in terms of their lock-in and other drawbacks. GitHub is pretty light-weight on that front. That said, something more akin to GitHub (including the nice integration API and fork/pull model) running on a service like Alioth would be very neat. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87iocu1fp5@hope.eyrie.org
Re: debian github organization ?
Russ Allbery r...@debian.org writes: Steve McIntyre st...@einval.com writes: Agreed - it's really annoying to see everybody clamour for a centralised single point of of failure for git hosting. :-( Funny, this is why I don't get why people are so upset that some use GitHub. Because of how Git works, the impact of lock-in is pretty much limited to the non-repository stuff (issues and so forth). Yet it is exactly those lock-in features that is the basis for arguments to put special effort into the centralised single point of failure. For example, the centralised proprietary GitHub “pull request” is presented as a reason to abandon a decentralised model: Paul Tagliamonte paul...@debian.org writes: An entirely fair point, however, I also think it's quite rude to ignore the workflow they've chosen for contributions -- if they expect PRs, it might disrupt their workflow and result in a much harder time for them. So upstream have chosen a proprietary lock-in service for their workflow. That should not put any obligation on others to also submit to proprietary lock-in. -- \ “I went to a restaurant that serves ‘breakfast at any time’. So | `\I ordered French Toast during the Renaissance.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85y4lqqkfx@benfinney.id.au
Re: debian github organization ?
I'd rather see gitlab.debian.net :) Which is similar in spirit to ask.debian.net. PS. Sorry for top reply from mobile phone. On 16 Apr 2015 7:46 am, Jérémy Lal kapo...@melix.org wrote: Hello, i was wondering if debian had a github account as an organization, where maintainers could be added. This is a scary pandora box, though :) Jérémy.
Re: debian github organization ?
On Thu, Apr 16, 2015 at 4:04 PM, Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) Good one Dimitri! I started to use Gitlab for serious work only recently, and well I love it. So +1 from me, I volunteer to help out with that. Cheers! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/camhuwoycd9s2gx78os04u0mh53fu3anev+3v2-uwctutsyx...@mail.gmail.com
Re: debian github organization ?
On 16 Apr 2015 7:46 am, Jérémy Lal kapo...@melix.org wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. there is: https://github.com/debian This is a scary pandora box, though :) indeed. it could be nice, but i'd rather avoid it. On Thu, Apr 16, 2015 at 5:04 PM, Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) yeah, me too. i love it. i'd help to run it (i don't have so much experience running gitlab (yes, i run an instance), but i definitely want to join a team setting it up + keeping it running. -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cahkymevzphp5oyoacjnek-jkyrmihbkajwbue-heijx14xx...@mail.gmail.com
Re: debian github organization ?
On Thu, 2015-04-16 at 17:11 +0200, Mattia Rizzolo wrote: On 16 Apr 2015 7:46 am, Jérémy Lal kapo...@melix.org wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. there is: https://github.com/debian This is a scary pandora box, though :) indeed. it could be nice, but i'd rather avoid it. On Thu, Apr 16, 2015 at 5:04 PM, Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) yeah, me too. i love it. i'd help to run it (i don't have so much experience running gitlab (yes, i run an instance), but i definitely want to join a team setting it up + keeping it running. I like github very much ,too! And linux kernel have a display on github! I really want to see Debian in the github! If this can be true , I will follow it quickly! But I know that debian does not manager source code by git ! How can it?? mudongliang -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/blu437-smtp9993ccc8a5004782f6a5f4bc...@phx.gbl
Re: debian github organization ?
On 04/16/2015 06:09 PM, Alessio Treglia wrote: On Thu, Apr 16, 2015 at 4:04 PM, Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) I'm not a DD, but I'd suggest to consider Gogs, too. It's pretty new and unfinished, but potentially is much better than GitLab, IMHO. Best regards, Dmitry. signature.asc Description: OpenPGP digital signature
Re: debian github organization ?
I'd rather see gitlab.debian.net :) Why Gitlab when there's Kallithea? :) -- Cheers, Andrew
Re: debian github organization ?
On Thu, Apr 16, 2015 at 9:45 PM, Jérémy Lal wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. It would probably better to use free tools instead? http://mako.cc/writing/hill-free_tools.html -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6huccnmublpw_pet_jpyykuxh3rohxqahg7dbu2jrg...@mail.gmail.com
Re: debian github organization ?
Quoting Jérémy Lal (2015-04-16 15:45:34) i was wondering if debian had a github account as an organization, where maintainers could be added. Wouldn't surprise me, but I don't know (not interested). This is a scary pandora box, though :) If you add that remark to appeace those disliking non-free services: It doesn't work on me, and I doubt it works on others either. If you mention because you dislike it yourself: Easier to ignore it! Enjou the ride... - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: debian github organization ?
On Thu, 16 Apr 2015 09:04:07 -0600 Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) I don't a reason to have gitlab/github/someother git stuff for debian, since we already have alioth. Maybe someone can enlighten me. Regards Sven pgphXmA_4Agbj.pgp Description: Digitale Signatur von OpenPGP
Re: debian github organization ?
On 04/16/2015 09:19 PM, Alexander Alemayhu wrote: On Thu, Apr 16, 2015 at 06:15:07PM +0300, Dmitry Yu Okunev wrote: I'm not a DD, but I'd suggest to consider Gogs, too. It's pretty new and unfinished, but potentially is much better than GitLab, IMHO. I'm not a DD either but +1 :) I tried it out awhile back from the try site[0]and it just has a much better feel to it IMHO. Have you tried installing it? Yes, We are trying it in our University (NRNU MEPhI). Example repository: https://devel.mephi.ru/dyokunev/tasks I can say, that Gogs is not production ready. A lot of tiny bugs (with avatars etc), no Pull request support and so on. But it developing very fast. Gogs is much more GitHub-like than GitLab as for me, so it's much more usual for GitHub users, IMHO. [0]: https://try.gogs.io/ Best regards, Dmirty. signature.asc Description: OpenPGP digital signature
Re: debian github organization ?
On Thu, 16 Apr 2015 19:40:21 -0700, Russ Allbery r...@debian.org wrote: Iustin Pop ius...@debian.org writes: I think the VCS agnosticism is actually detrimental in this context. It's much easier for the user when every repo is using the same VCS. And consistency makes it very easy, for example, to refer to commits across projects, to standardise pull/clone workflows, etc. +1. VCS agnosticism means you waste a bunch of time making each new feature work with every supported VCS, which can include trying to shoehorn pretty foreign workflows into the model of some other VCS. But it leaves a choice to the author. On a VCS-bound system, all choice you have is to go to a different place. Thankfully, git is by far the best VCS on the market and the vast majority of people seem to agree. But imagine the outcry if ten years ago Sourceforge had said our VCS is svn and we don't support anything else. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yiyy9-vg...@swivel.zugschlus.de
Re: debian github organization ?
Iustin Pop ius...@debian.org writes: I think the VCS agnosticism is actually detrimental in this context. It's much easier for the user when every repo is using the same VCS. And consistency makes it very easy, for example, to refer to commits across projects, to standardise pull/clone workflows, etc. +1. VCS agnosticism means you waste a bunch of time making each new feature work with every supported VCS, which can include trying to shoehorn pretty foreign workflows into the model of some other VCS. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oamn5vfu@hope.eyrie.org
Re: debian github organization ?
On 2015-04-17 10:54:43, Russell Stuart wrote: Github has all but annihilated SourceForge in the hosting market place, and the stand out change is it's UI. That is in spite of SourceForge's impressive mirror network and SourceForge being VCS agnostic. I think the VCS agnosticism is actually detrimental in this context. It's much easier for the user when every repo is using the same VCS. And consistency makes it very easy, for example, to refer to commits across projects, to standardise pull/clone workflows, etc. regards, iustin signature.asc Description: Digital signature
Re: debian github organization ?
On Thu, 2015-04-16 at 19:37 +0200, Sven Bartscher wrote: On Thu, 16 Apr 2015 09:04:07 -0600 Dimitri John Ledkov x...@debian.org wrote: I'd rather see gitlab.debian.net :) I don't a reason to have gitlab/github/someother git stuff for debian, since we already have alioth. Maybe someone can enlighten me. Probably not. UI's are a personal thing and if you've looked at the others and still the UI provided by FusionForge, that's unlikely to change. But do acknowledge that makes you unusual. Github has all but annihilated SourceForge in the hosting market place, and the stand out change is it's UI. That is in spite of SourceForge's impressive mirror network and SourceForge being VCS agnostic. So it's not surprising some DD's want to move away from the FusionForge UI. I'm on SourceForge now. [0] I'd prefer to be on Debian's infrastructure of course, but Alioth is so poorly maintained it was unusable for me [1]. Of the suggestions so far only Kallithea is VCS agnostic, but Kallithea only supports source code hosting - no Ticketing (eg bug tracking), no web project web page, no release hosting (binaries). Maybe that's an advantage for Debian projects because it forces you to use Debian's existing infrastructure for everything else, but for me it makes it a no-go. Gogs looks to be similar, but is unstable. Gitlab is git only and doesn't support releases. SourceForge's Apollo is an open source project supporting all those features plus a heap more, but the UI is not code centric like the others - it feels more like FusionForge. That said, unlike FusionForge modern work flows (forking, pull requests and the like) - it's just they aren't a prominent in the UI. [0] http://sourceforge.net/u/rstuart/ [1] https://lists.debian.org/debian-devel/2014/05/msg00463.html That triggered this response, but it read like someone in denial rather than acknowledging the problem: https://lists.debian.org/debian-devel/2014/06/msg00435.html Acknowledging the problem is always the first step in fixing it, and I think it's significant the number of open bugs has gone up by 20% since then. signature.asc Description: This is a digitally signed message part
Re: debian github organization ?
On Thu, Apr 16, 2015 at 06:15:07PM +0300, Dmitry Yu Okunev wrote: I'm not a DD, but I'd suggest to consider Gogs, too. It's pretty new and unfinished, but potentially is much better than GitLab, IMHO. I'm not a DD either but +1 :) I tried it out awhile back from the try site[0]and it just has a much better feel to it IMHO. Have you tried installing it? [0]: https://try.gogs.io/ -- Mit freundlichen Grüßen Alexander Alemayhu signature.asc Description: Digital signature
Re: debian github organization ?
On Thu, 16 Apr 2015 17:11:29 +0200 Mattia Rizzolo mat...@mapreri.org wrote: On 16 Apr 2015 7:46 am, Jérémy Lal kapo...@melix.org wrote: i was wondering if debian had a github account as an organization, where maintainers could be added. there is: https://github.com/debian I've already got a bunch of other stuff on github (some on Alioth too but github is more reliable, easier to find related stuff and easier for people outside Debian to fork and use to contribute) as well as mirrors of my work stuff for Linaro. How do people (DD's) go about getting invites to the Debian organisation on github? (Ping me off-list if the potential number of enquirers would be unmanageable.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJkh7_pJ_BQ.pgp Description: OpenPGP digital signature
