Re: Move part of macports infrastructure to GitHub
A related item that bubbled on the mailing list for a while would be to get the http://trac.edgewall.org/wiki/CommitTicketUpdater configured for MP. This would let us refer to and take actions on (ref #1234 or closes #5432) tickets in commit messages, which ties a nice bow around commits tied to a ticket. It's not at github pull request / comments / sugar-ness level, but it's a nice feature if we could enable it. Any chance of getting that done? - Eric ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Apr 8, 2014, at 21:38, Eric A. Borisch wrote: A related item that bubbled on the mailing list for a while would be to get the http://trac.edgewall.org/wiki/CommitTicketUpdater configured for MP. This would let us refer to and take actions on (ref #1234 or closes #5432) tickets in commit messages, which ties a nice bow around commits tied to a ticket. It's not at github pull request / comments / sugar-ness level, but it's a nice feature if we could enable it. Any chance of getting that done? https://trac.macports.org/ticket/41919 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 21, 2014, at 4:17 PM, Landon Fuller land...@macports.org wrote: On Mar 20, 2014, at 8:39 PM, Ryan Schmidt ryandes...@macports.org wrote: On Mar 20, 2014, at 19:21, Eric Gallager wrote: That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread…) Why is a github mirror of the git repository desirable? Why can’t users who want a git version of our repository use the one Mac OS Forge provides? Is it just to help users discover the existence of the repository or what? In my experience, the alternative is that people republish your code on GitHub anyway, in which case you have a bunch of disconnected mirrors of your code under the same name as your project, none of which is obviously canonical. If your code is going to wind up republished to GitHub anyway, having a mirror at least allows you to control the branding, point back to the original project, and ensure that it's clear which repositories are user-uploaded mirrors (forks), and which is the canonical mirror. As a follow-up — it looks like Apache is doing some really neat stuff in terms of integrating with GitHub, while maintaining local canonical control of project hosting and resources: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ -landonf ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, Apr 3, 2014 at 4:41 PM, Landon Fuller wrote: As a follow-up — it looks like Apache is doing some really neat stuff in terms of integrating with GitHub, while maintaining local canonical control of project hosting and resources: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ I don't quite understand how github - jira integration and integration of Apache's own mailing lists would help MacPorts. Doesn't that only apply to projects hosted at Apache? I see some work being done for better integration between svn and git, but don't yet quite understand how it works. But anyway, this one was amazing: https://issues.apache.org/jira/browse/INFRA-7524 http://www.infoq.com/news/2014/04/svn-migrates-to-git Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, 03 Apr 2014 20:51:23 +0200, Mojca Miklavec wrote: On Thu, Apr 3, 2014 at 4:41 PM, Landon Fuller wrote: As a follow-up — it looks like Apache is doing some really neat stuff in terms of integrating with GitHub, while maintaining local canonical control of project hosting and resources: https://blogs.apache.org/infra/entry/improved_integration_between_apache_and https://svn.apache.org/repos/infra/infrastructure/trunk/projects/ I don't quite understand how github - jira integration and integration of Apache's own mailing lists would help MacPorts. Doesn't that only apply to projects hosted at Apache? It is an example how another project provides a presence on GitHub, but still uses their own infrastructure for main development. They have set it up such that any new pull requests on GitHub triggers a mail report to the project mailing list. Replies to that mailing list thread will even be synced back to appear as comments on GitHub. The second link contains the repository with several scripts that seem to make that work. It's an interesting concept, but sounds like it requires a fair amount of administration work for this infrastructure. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn * pull requests are awesome! No need to poke around with patch files attached to tickets * nice UI, tools and infra around FWIW, the D programming language reports a 10-fold increase in contributions after moving their source to Github: http://forum.dlang.org/thread/iv4pp8$2td5$1...@digitalmars.com#post-iv524m:2498r:241:40digitalmars.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
I started my primary devel life using CVS back in 2005 -- before then, I never really (thought I) needed a repo manager for my code, since it was pretty much just for me. CVS was fine for what we needed at the time (3-4 developers, 10 users, 1 leader with commit rights to the trunk / master), but as the project grew CVS didn't keep up with our needs. So, we moved to SVN / Trac -- roughly the same as what MacPorts provides, and I became a MacPorts port developer sometime about the same time as this move. For how MacPorts works, SVN is fine. For my primary project, SVN became limiting -- difficult to track branches, do merges, etc... After some discussion, we set up a copy on github -- and, as the David pointed out about D, we saw an enormous growth of patch submissions (primarily via pull requests) and an major uptick in -useful- discussion on our listserve; users flocked to our project and it certainly seems like using GIT helped out in that regard (among other things). Shortly thereafter, we moved entirely to GIT. GIT works much better for this project than SVN (or CVS) did; we now have ~10 active developers, and ~50 2nd tier developers (not that this is impossible with CVS or SVN, but it's just easier overall with GIT). Your repo manager goodness depends on the type of project: for MacPorts, GIT would work fine but it's a bit overkill. SVN is plenty enough for MacPorts, and, since it works nicely already, if I had a vote I'd vote to keep using SVN [note: I've never used hg / Mercurial, but I'm sure it's similar yet different from/to CVS / SVN / GIT, just with its own language and twists therein]. That said, I don't really care either; I am reasonably fluent in SVN and GIT, and I'm sure I could / will learn HG sooner or later for some project or another. Each package manager has its pros and cons; just pick your poison and go with it. - MLD ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 20, 2014, at 8:39 PM, Ryan Schmidt ryandes...@macports.org wrote: On Mar 20, 2014, at 19:21, Eric Gallager wrote: That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread…) Why is a github mirror of the git repository desirable? Why can’t users who want a git version of our repository use the one Mac OS Forge provides? Is it just to help users discover the existence of the repository or what? In my experience, the alternative is that people republish your code on GitHub anyway, in which case you have a bunch of disconnected mirrors of your code under the same name as your project, none of which is obviously canonical. If your code is going to wind up republished to GitHub anyway, having a mirror at least allows you to control the branding, point back to the original project, and ensure that it's clear which repositories are user-uploaded mirrors (forks), and which is the canonical mirror. -landonf ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 21, 2014, at 15:17, Landon Fuller wrote: Why is a github mirror of the git repository desirable? Why can’t users who want a git version of our repository use the one Mac OS Forge provides? Is it just to help users discover the existence of the repository or what? In my experience, the alternative is that people republish your code on GitHub anyway, in which case you have a bunch of disconnected mirrors of your code under the same name as your project, none of which is obviously canonical. If your code is going to wind up republished to GitHub anyway, having a mirror at least allows you to control the branding, point back to the original project, and ensure that it's clear which repositories are user-uploaded mirrors (forks), and which is the canonical mirror. Yes, I can see the wisdom of that. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Hi, Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas – feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Migrating to a completely new system for version control and tickets would probably be either very difficult or lossy (or both). And the workflow would need to be redefined completely. I'm not saying that I oppose the idea if someone is actually willing to spend time to do it right, just saying that current system works nice and that git or hg probably wouldn't add that much. (For me, Tcl is the one that's often limiting my contributions a lot more than anything else because I don't have much experience writing code in it.) That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). Btw, we now have: - Fink: CVS + Perl - MacPorts: SVN + Tcl - HomeBrew: GIT + Ruby We desperately need the fourth package manager using HG + Python ;) Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that’s something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas – feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the “haspatch” keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don’t remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
sync certainly works with git as well. --Mark ___ Mark E. Anderson e...@emer.net On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that's something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas - feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the haspatch keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don't remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt ryandes...@macports.orgwrote: On Mar 20, 2014, at 02:46, Mojca Miklavec wrote: Despite the fact that I kept pushing a couple of other projects to switch to a different version control system (mostly from CVS to git), MacPorts is one of those projects where the current system (trac with nice linking between tickets and commits, subversion, buildbots, email accounts, ...) works pretty well and also looks nice. I do miss some functionality (like a website with a nice overview of packages with their build success, latest few commits etc.), but that isn't something that a migration can solve. Right, that's something improving the MacPorts web site should solve. Subversion actually has a bunch of benefits over git in this particular environment. Git is strong in merging, cherry-picking, having a large number of branches etc., but I don't see much need for that for maintaining Portfiles. The biggest problem with Portfiles is that a number of people without commit rights might need to wait for a long time before someone picks up their patch and commits it, but switching to a different system would still mean that someone would need to look at commit and test it before accepting it. The only thing that could be different is probably a clearly visible pull request. In MacPorts' trac it's not too easy to spot the difference between please commit this, it's fully functional vs. I've been just playing around and tossing ideas - feel free to look and this patch and improve it vs. plain requests to fix things. And if a random developer just happens to have time and is willing to test and commit something, it's not clear in which of the thousands of open tickets to start looking. (Trac searches and browsing through tickets based on specific criteria could be improved, but I'm not sure how.) Such a person should search for tickets with the haspatch keyword; that keyword should probably only be used for patches that are ready to go. https://trac.macports.org/query?status=!closedkeywords=~haspatchdesc=1order=id That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread...) MacPorts could potentially offer a selfupdate from an arbitrary git/hg repository clone if necessary (but one can already have a clone on the filesystem and use that one). selfupdate uses rsync only. sync can use rsync or svn, possibly other version control systems already, I don't remember. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 20, 2014, at 19:21, Eric Gallager wrote: That said, a git/hg mirror on GitHub/ButBucket would definitely be nice. Why would that be nicer than the read-only git mirror that Mac OS Forge already provides here: http://www.macosforge.org/post/git-mirrors/ Try to avoid thinking of it as nicer than, but instead think of it as a nice addition to. The nice thing about distributed systems like git is that it makes it easier to mirror a single mirror to multiple places. A git mirror on GitHub could even be the exact same mirror as the one on MacOSForge is. That is similar to how most of the mirrors on the GitHub-Mirrors account work: https://github.com/mirrors (I think I mentioned that earlier in this thread…) Why is a github mirror of the git repository desirable? Why can’t users who want a git version of our repository use the one Mac OS Forge provides? Is it just to help users discover the existence of the repository or what? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 16, 2014, at 11:40 PM, Joshua Root j...@macports.org wrote: However I would also agree with what Landon said here: https://lists.macosforge.org/pipermail/macports-dev/2013-September/024252.html I’m glad I read the full thread, as otherwise I might have reiterated this point without realizing I’d already made it :-) That said — The better I understand git, the less I like it, but the fact is that the industry has shifted and git is the leader for now. I’d certainly support a move to git, especially if we had the time and server-side control necessary to disable dangerous, data-destroying features such as permanent deletion of branches+tags and forced pushes, and thus could be assured that repository history would remain correct and internally consistent until the next SCM emerges. However, I still think it’s a backwards step to abandon self-hosted control of critical project infrastructure, and I don’t think there’s a compelling technical or administrative argument for Github that outweighs this. I’ve not seen *better* or more *correct* contributions by using Github on projects; rather, it seems to lower the bar (and even that is arguable) on the least important part of the process — submitting the patch. I also have some ethical qualms about contributing to the furtherance of what amounts to Github’s social network lock-in through network effects. They’re a commercial organization, and I don’t think an open source monoculture defined and driven by GitHub's business goals and ideals of how people should manage projects is to open source's benefit. Lastly, I question the wisdom of tying a project that has already lived for 12 years to a commercial “SaaS” offering. Recently, I had to move some small projects off of Google Code — because Google had deprecated and removed their data APIs, I had to actually use a screen scraper to (lossily) export my Google Code issues. If you’d told me 8 years ago that Google would pull the data APIs and make it difficult to leave, I wouldn’t have believed it. -landonf___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Related side question: Does our install of Trac have any public APIs (XMLRPC, REST, SOAP, whatever)? Mark --Mark ___ Mark E. Anderson e...@emer.net On Tue, Mar 18, 2014 at 3:51 PM, Landon Fuller land...@macports.org wrote: On Mar 16, 2014, at 11:40 PM, Joshua Root j...@macports.org wrote: However I would also agree with what Landon said here: https://lists.macosforge.org/pipermail/macports-dev/2013-September/024252.html I'm glad I read the full thread, as otherwise I might have reiterated this point without realizing I'd already made it :-) That said -- The better I understand git, the less I like it, but the fact is that the industry has shifted and git is the leader *for now*. I'd certainly support a move to git, especially if we had the time and server-side control necessary to disable dangerous, data-destroying features such as permanent deletion of branches+tags and forced pushes, and thus could be assured that repository history would remain correct and internally consistent until the *next* SCM emerges. However, I still think it's a backwards step to abandon self-hosted control of critical project infrastructure, and I don't think there's a compelling technical or administrative argument for Github that outweighs this. I've not seen *better* or more *correct* contributions by using Github on projects; rather, it seems to lower the bar (and even that is arguable) on the least important part of the process -- submitting the patch. I also have some ethical qualms about contributing to the furtherance of what amounts to Github's social network lock-in through network effects. They're a commercial organization, and I don't think an open source monoculture defined and driven by GitHub's business goals and ideals of how people should manage projects is to open source's benefit. Lastly, I question the wisdom of tying a project that has already lived for 12 years to a commercial SaaS offering. Recently, I had to move some small projects off of Google Code -- because Google had deprecated and removed their data APIs, I had to actually use a screen scraper to (lossily) export my Google Code issues. If you'd told me 8 years ago that Google would pull the data APIs and make it difficult to leave, I wouldn't have believed it. -landonf ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Google shows there are plugins available. Is there somethign specific you’re interested in seeing? On Mar 18, 2014, at 22:15, Mark Anderson e...@emer.net wrote: Does our install of Trac have any public APIs (XMLRPC, REST, SOAP, whatever)? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 18, 2014, at 2:51 PM, Landon Fuller land...@macports.org wrote: However, I still think it’s a backwards step to abandon self-hosted control of critical project infrastructure, and I don’t think there’s a compelling technical or administrative argument for Github that outweighs this. I’ve not seen *better* or more *correct* contributions by using Github on projects; rather, it seems to lower the bar (and even that is arguable) on the least important part of the process — submitting the patch. I also have some ethical qualms about contributing to the furtherance of what amounts to Github’s social network lock-in through network effects. They’re a commercial organization, and I don’t think an open source monoculture defined and driven by GitHub's business goals and ideals of how people should manage projects is to open source's benefit. Lastly, I question the wisdom of tying a project that has already lived for 12 years to a commercial “SaaS” offering. Recently, I had to move some small projects off of Google Code — because Google had deprecated and removed their data APIs, I had to actually use a screen scraper to (lossily) export my Google Code issues. I agree with all these points. If a switch to git or mercurial is made, then the transition from svn can be fairly painless if server-side control is maintained. If I am not mistaken, Trac can be configured to use different version control systems on the backend, including git and mercurial (the latter via a plugin, see http://trac.edgewall.org/wiki/TracMercurial). It’s easy enough to automatically push changes to repo clones at github, bitbucket, google code, or all of the above. Personally, I’d prefer mercurial over git. It’s fairly easy to transition from svn to mercurial, but for git I am often still stuck using the SourceTree GUI from the Bitbucket folks to figure out what I am doing. I am sure I could get used to git, though. -- Mark Moll signature.asc Description: Message signed with OpenPGP using GPGMail ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
I'm mostly interested in being able to authenticate, add, and read tickets. I'm looking to see if I can create a draft ticket from within my git workflow. --Mark ___ Mark E. Anderson e...@emer.net On Tue, Mar 18, 2014 at 10:55 PM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Google shows there are plugins available. Is there somethign specific you're interested in seeing? On Mar 18, 2014, at 22:15, Mark Anderson e...@emer.net wrote: Does our install of Trac have any public APIs (XMLRPC, REST, SOAP, whatever)? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)
On Mar 16, 2014, at 17:18, Rainer Müller wrote: a) No support for svn:ignore property Easy to accomplish, we would just keep the equivalent in .gitignore and .hgignore files in the repository root. The svn:ignore property would still be the authoritative value. As these are barely set at all in the ports tree, that should not be a problem. Agreed. To Clemens’ point that these could get out of sync, a pre-commit hook on the Subversion server could ensure that they are not out of sync (or else block the commit, with a message telling the user how to make them sync). b) No support for svn:keywords property Most notably we are using svn:keywords to replace the $Id$ string in every Portfile. I think this string is of limited use and we could do without it. See also this ticket for a detailed discussion of the problem: http://trac.macports.org/ticket/38902 (Following the comments in the ticket, it's not even an issue with newer versions of git-svn any more. What about hgsubversion?) Agreed, we could get rid of the $Id$ line and stop using svn:keywords. c) No support for svn:eol-style property Do we need that at all, anyway? I don't think anybody is editing this on Windows, so I doubt we would ever see a file with CRLF line endings. We want our text files to have only LF line endings—not CRLF line endings, and certainly not a mix of LF and CRLF line endings. I don’t know if anyone uses an editor that defaults to other than LF line ending styles, but I don’t want to find out about it after a lot of bad commits have already been made. svn:eol-style is enforced on the client side. To prevent problems caused by clients that don’t do this, we could write a pre-commit hook to enforce this in the repository. A hook to enforce that the required properties are set was already planned for a long time: https://trac.macports.org/ticket/12594 The idea to write a hook to prevent non-respected properties is here: https://trac.macports.org/ticket/38902 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Besides all the things mentioned in this thread so far, I would like to note that there are some options to have it both ways and have a bigger presence on GitHub, even if we still keep our Trac infrastructure as well. For one, there is the mirrors account that has a bunch of read-only mirrors set up for other popular open-source projects that are hosted elsewhere: https://github.com/mirrors We could try to get that account to put up a mirror of the MacPorts read-only git mirror as well, or just put up a read-only mirror similarly ourselves. Second, GitHub has a Trac service hook that can be enabled under a repo's settings under Webhooks Services, although the notes there say that that hook is deprecated in favor of the trac-github plugin: https://github.com/aaugustin/trac-github We could try using that plugin to be able to still do everything in Trac and yet also have a presence on GitHub at the same time. Third, even if we do not want to move the MacPorts infrastructure itself to GitHub, we could at least make a MacPorts Organization on GitHub that MacPorts developers could be added to if they wanted: https://github.com/organizations/new Having a GitHub organization could at least show the GitHub community that we do at least have a human presence there, even if we do not necessarily also have a code presence there as well. Anyways, I bring up these ways to have it both ways because while I do use GitHub a lot, it is becoming harder and harder to do so, as they dropped support for the Snow Leopard version of the GitHub desktop a while ago, and more recently they made some change to the website that broke it in the Snow Leopard version of Safari, so now whenever I am using Safari, I have to remember to open all links to GitHub in Firefox or Chrome instead, which is annoying. While I can still use it, it is part of a trend of dropping compatibility that has me worried that if we move entirely to GitHub, users on older OSes might eventually get left behind, without Trac still being there as a backup. Hence why I prefer having both instead of just one. On 3/16/14, Joshua Root j...@macports.org wrote: On 2014-3-17 05:42 , Sean Farley wrote: If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I would certainly agree with that. However I would also agree with what Landon said here: https://lists.macosforge.org/pipermail/macports-dev/2013-September/024252.html Rainer also did a great job of explaining why moving to github is a bad idea earlier in the thread. Much the same applies to bitbucket. I should note that I've used both git and hg for real work, and a modern DVCS certainly has its advantages. But that said, I really haven't felt like I was being restricted by svn while working on MacPorts. In fact, sometimes being able to check out a single file or directory deep in the tree comes in handy. If the majority of contributors really find that they are being held back by svn, I guess I would support moving our repos to hg. We could at least add an official hg mirror. But the OP said that the thread was about github and the convenience of pull requests, not git as such. If the problem is that people find it's too much trouble to svn diff and attach the output to a ticket, maybe client side automation is the solution. We have a script to apply a patch straight from a Trac URL, so why not one to create a ticket and attach a patch. It would be more complicated certainly, but if saving that handful of clicks gets more people involved, I guess it's worth it. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Move part of macports infrastructure to GitHub
I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn * pull requests are awesome! No need to poke around with patch files attached to tickets * nice UI, tools and infra around which will result in more pros: * people will look at macports more positively * and will contribute more! Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macportstype=Repositoriesref=searchresults What do you think? -- With best regards, Ivan Larionov. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Ivan Larionov xeron.os...@gmail.com writes: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn * pull requests are awesome! No need to poke around with patch files attached to tickets * nice UI, tools and infra around which will result in more pros: * people will look at macports more positively * and will contribute more! Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macportstype=Repositoriesref=searchresults What do you think? I know this is a hot topic but I will try to avoid any flame wars. If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I've actually maintained a repo with merges, tags, and branches correctly merged in here: https://smf.io/macports ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On 16 Mar 2014, at 19:42 , Sean Farley s...@macports.org wrote: I would suggest Mercurial. +1 But, in order to avoid any flamewars: I’d be going for git as well, if it would win in an election. :-) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On Mar 16, 2014, at 13:27, Ivan Larionov wrote: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn For you, moving from svn to git may be a pro; for me, it would initially be a con. I have a decade of experience with Subversion and a very good understanding of how it works and behaves, and only an extremely spotty understanding of git. It makes me uncomfortable every time I use it. That could be cured by spending some hours with a fine manual, but it would be something new to need to learn. Although I understand github does offer svn access to its git repositories, so it’s possible those like me who would prefer not to be forced to switch to git wouldn’t have to. Note that Mac OS Forge already provides a read-only git mirror of the MacPorts Subversion repository: http://www.macosforge.org/post/git-mirrors/ Perhaps that is already helpful to you. * pull requests are awesome! No need to poke around with patch files attached to tickets I agree that in principle pull requests would seem like a better method than our current patches attached to tickets. In practice, I am still very unfamiliar and uncomfortable with the process. * nice UI, tools and infra around I do like the github web interface. I like the github issue tracker better than Trac; it doesn’t distract with lots of fields. I like markdown better than Trac’s WikiFormatting. However, how would we convert the tens of thousands of existing issues, maintaining the formatting and Subversion revision number references? What about converting the Trac wiki to github wiki, and maintaining the wiki page references in the tickets? What about links to tickets, changesets, wiki pages that are found in years of our mailing list archives—can we successfully redirect those to their new home at github? The options I see, none of which are happy, are: * Move the code to github, but don’t move the issue tracker or wiki; keep those in Trac at Mac OS Forge. Keeping the old Subversion repository running read-only sowould let old Trac changeset links still work, but I’m not sure how we would link to github changesets. This would make the move to github much less useful I think. * Move the code and also convert all the Trac content to github, and ultimately take down the Mac OS Forge Trac and svn servers. This would be a lot of work, I imagine. * Move the code to github, keep Trac and svn running with the current content, and use github for new content (new issues, new wiki pages). This seems like a really bad idea as we would have to juggle two systems for years to come. which will result in more pros: * people will look at macports more positively That’s possible, but I think people should not view a project positively or negatively depending on its chosen hosting infrastructure (assuming that infrastructure works to the satisfaction of the project’s developers, which Mac OS Forge hosting infrastructure currently does for us). Instead they should judge a project on its usefulness. * and will contribute more! We do already have lots of contributions. In fact we have more contributions than we can handle, as evidenced by all our open tickets. But it’s possible that by using git and therefore pull requests it might become easier to handle contributions and make us able to handle them quicker. Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macportstype=Repositoriesref=searchresults I suppose I have no objection to people doing that. What do you think? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Yeah, I actually like the idea of GitHub for the idea of pull requests. So much so, I mirror the Macports on github, make my changes in branches and make patches for SVN there. I'm certain we could save all the history we needed. I've made this shift several times on a few projects. I even have base in there, where I am working on my Perl CPAN runner (another hot topic, I know), so we maybe won't need 87 Perls. --Mark ___ Mark E. Anderson e...@emer.net On Sun, Mar 16, 2014 at 2:52 PM, mk-macpo...@techno.ms wrote: On 16 Mar 2014, at 19:42 , Sean Farley s...@macports.org wrote: I would suggest Mercurial. +1 But, in order to avoid any flamewars: I'd be going for git as well, if it would win in an election. :-) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Actually main thing here isn’t git, but github. It’s interface and features take contribution process to the next level. It’s so easy — just fork, commit and send pull request. I understand that someone could like mercurial more and we have bitbucket, but actually, I see people use github more and like it. -- With best regards, Ivan Larionov. On 16 марта 2014 г., at 22:42, Sean Farley s...@macports.org wrote: Ivan Larionov xeron.os...@gmail.com writes: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn * pull requests are awesome! No need to poke around with patch files attached to tickets * nice UI, tools and infra around which will result in more pros: * people will look at macports more positively * and will contribute more! Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macportstype=Repositoriesref=searchresults What do you think? I know this is a hot topic but I will try to avoid any flame wars. If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I've actually maintained a repo with merges, tags, and branches correctly merged in here: https://smf.io/macports ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Yeah, I agree with Ivan, the big deal is Github. Git is great, but hg offers a lot of the same stuff. As to Ryan's objections, I too had those same objections after working with SVN and CVS for almost 2 decades. But once I switched, I wondered why I hadn't switched earlier. I'm sure those of us in the community would be more than happy to help move things over, I know I would. I've been wanting to get more and more involved for a while. And I know Github pretty well. I also use Github Enterprise at work. Not for nothing, but that search turned up roughly 22 pages of personal Macports repos. (alhtough a few referenced Macports sucks which I don't like, but eh. It was more positive than negative. Mark —Mark ___ Mark E. Anderson e...@emer.net On Sun, Mar 16, 2014 at 3:13 PM, Ivan Larionov xeron.os...@gmail.comwrote: Actually main thing here isn’t git, but github. It’s interface and features take contribution process to the next level. It’s so easy — just fork, commit and send pull request. I understand that someone could like mercurial more and we have bitbucket, but actually, I see people use github more and like it. -- With best regards, Ivan Larionov. On 16 марта 2014 г., at 22:42, Sean Farley s...@macports.org wrote: Ivan Larionov xeron.os...@gmail.com writes: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn * pull requests are awesome! No need to poke around with patch files attached to tickets * nice UI, tools and infra around which will result in more pros: * people will look at macports more positively * and will contribute more! Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macportstype=Repositoriesref=searchresults What do you think? I know this is a hot topic but I will try to avoid any flame wars. If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I've actually maintained a repo with merges, tags, and branches correctly merged in here: https://smf.io/macports ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Ivan Larionov xeron.os...@gmail.com writes: Actually main thing here isn’t git, but github. It’s interface and features take contribution process to the next level. It’s so easy — just fork, commit and send pull request. I understand that someone could like mercurial more and we have bitbucket, but actually, I see people use github more and like it. I prefer the bitbucket interface to pull requests since the two are feature equivalent. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Ryan Schmidt ryandes...@macports.org writes: On Mar 16, 2014, at 13:27, Ivan Larionov wrote: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn For you, moving from svn to git may be a pro; for me, it would initially be a con. I have a decade of experience with Subversion and a very good understanding of how it works and behaves, and only an extremely spotty understanding of git. It makes me uncomfortable every time I use it. That could be cured by spending some hours with a fine manual, but it would be something new to need to learn. Although I understand github does offer svn access to its git repositories, so it’s possible those like me who would prefer not to be forced to switch to git wouldn’t have to. Coming from years of supporting projects moving from Subversion to git / Mercurial, it has been my experience that Mercurial has a much more sane user interface and doesn't force the user to grok the internals as I've found git does. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Ok. I'm willing to play ball on that. Also since Atlassian products are pretty cool. I just like the idea of a more modern workflow. If I got a vote, which I suppose I don't, It would be git/github, but hg/bitbucket is ok. Git/bitbucket is what I use on the side as well. --Mark ___ Mark E. Anderson e...@emer.net On Sun, Mar 16, 2014 at 3:31 PM, Sean Farley s...@macports.org wrote: Ryan Schmidt ryandes...@macports.org writes: On Mar 16, 2014, at 13:27, Ivan Larionov wrote: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: * git svn For you, moving from svn to git may be a pro; for me, it would initially be a con. I have a decade of experience with Subversion and a very good understanding of how it works and behaves, and only an extremely spotty understanding of git. It makes me uncomfortable every time I use it. That could be cured by spending some hours with a fine manual, but it would be something new to need to learn. Although I understand github does offer svn access to its git repositories, so it's possible those like me who would prefer not to be forced to switch to git wouldn't have to. Coming from years of supporting projects moving from Subversion to git / Mercurial, it has been my experience that Mercurial has a much more sane user interface and doesn't force the user to grok the internals as I've found git does. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
Mark Anderson e...@emer.net writes: Ok. I'm willing to play ball on that. Also since Atlassian products are pretty cool. I just like the idea of a more modern workflow. If I got a vote, which I suppose I don't, It would be git/github, but hg/bitbucket is ok. Git/bitbucket is what I use on the side as well. Jira is pretty solid as well, for what it's worth. Also, there is the git-remote-hg plugin for git enthusiasts that are allergic to hg. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On 2014-03-16 19:27, Ivan Larionov wrote: I want to start this discussion mainly about ports tree, but actually base and some other stuff could use github and infra around it as well. I understand this is not so easy and may be you already discussed it and may be already decided not to do, but there are huge pros: It is important to note that using git and GitHub are totally separate, although many people fail to see that. Moving to git and moving to GitHub are two separate issues for me, but they may have some overlaps. Also note we had discussions on moving to a DVCS before. Some should turn up with a search in the mail archive, although it may already have been years ago we discussed this the last time. * git svn I agree with that, as I am already using git for work and other projects. However, I can only work with git now that I am proficient, I had hated it for a long time before reaching that point. I am afraid of the increased complexity of git and the changing workflow for other developers. We cannot simply swap out Subversion and bless a git mirror as the new main ports tree, a new way of working with git has to be worked out first. Coming from the Linux kernel, pure git expects a pull-based workflow. One central instance pulls up changes from many other repositories into the main repository. I would rule out such a person-based pull model for MacPorts, as who would take the responsibility for all the merges? At the moment, the MacPorts project gives out commit access to a central repository. Transferring that to git, that would mean giving everyone push access. With the right infrastructure (such as gitolite [1]) that could work, as it is required to limit the ability to overwrite work from others (technically, pushing fast-forward changes only). For the developers, this workflow requires a lot of rebase/merges locally and therefore a high-level understanding of git. Another option would be a machine-based pull model with reviews by developers, such as the GitHub pull requests [2] or hosting an instance of Gerrit [3] or Kiln [4]. These three review-based systems basically work in a way that a developer pushes their changes and then (another) developer has to acknowledge the changes in a web interface to be merged into the main repository. It has the advantage that every commit gets a review by someone else and also it removes the risk of someone pushing the wrong change – such as accidentally rebasing a lot of commits or rewriting the entire history, as that can happen with git, especially by unexperienced users. * pull requests are awesome! No need to poke around with patch files attached to tickets * nice UI, tools and infra around With this point you make the assumption we would use GitHub. How do you imagine we would manage that as a separate infrastructure? How would we hand out commit access and match mail forwards to GitHub usernames? I don't even want to talk about the migration issues that would come up when converting the Trac database to GitHub... Also, as an ethical question, would it be right for MacPorts as a non-profit project to promote GitHub as a profit-oriented company by choosing it as the main hosting provider? which will result in more pros: * people will look at macports more positively * and will contribute more! And for some others it will be more work to learn git only to get an update to MacPorts... Actually I see lot of people keeping their local ports at github: https://github.com/search?q=macportstype=Repositoriesref=searchresults Just in case you did not know that, you can already add any git ports tree to your sources.conf and start using it. The official tree is the only way to use ports and if someone wants to experiment with it you can already create overlays that only contain new or updates to existing ports. Rainer [1] http://gitolite.com/gitolite/ [2] https://help.github.com/articles/using-pull-requests [3] http://code.google.com/p/gerrit/ [4] http://www.fogcreek.com/kiln/ ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On 16 Mar 2014, at 21:07 , Rainer Müller rai...@macports.org wrote: I am afraid of the increased complexity of git and the changing workflow for other developers. We cannot simply swap out Subversion and bless a git mirror as the new main ports tree, a new way of working with git has to be worked out first. Yes, absolutely! Coming from the Linux kernel, pure git expects a pull-based workflow. One central instance pulls up changes from many other repositories into the main repository. I would rule out such a person-based pull model for MacPorts, as who would take the responsibility for all the merges? Well, that would also be my reservation against git... At the moment, the MacPorts project gives out commit access to a central repository. Transferring that to git, that would mean giving everyone push access. I’d prefer Mercurial, but I am afraid it could be just as dangerous. But it’s not so much whether one uses git or mercurial, it’s rather the infrastructure around it which defines how the port tree is maintained. Your refs [1-4] are good ways to find new workflows!!! I do like the review-based workflow. That’s actually what Ryan does for probably half of all port commits already now! ;-) With this point you make the assumption we would use GitHub. How do you That was also my thought. Why to get dependent on GitHub? There are Open Source alternatives, but they need hosting, maintenance, development, administration, etc… And for some others it will be more work to learn git only to get an update to MacPorts… Yep, even Mercurial would be equally complicated for a newbee. Just in case you did not know that, you can already add any git ports tree to your sources.conf and start using it. The official tree is the only way to use ports and if someone wants to experiment with it you can already create overlays that only contain new or updates to existing ports. I do this - using Mercurial - since years. So, I would really like a DVCS for MacPorts, and I am hoping for what Sean will come up with soon using Mercurial+evolve+hgsubversion. I think that could offer the chance of a smoother transition, because one could work in parallel with SVN and Mercurial for quite a while. Devs and port maintainers could slowly migrate while learning how to work Mercurial bit by bit without being forced to toss SVN from a certain date on. Would be cool to get news from your very ambitious project, Sean!!! Greets, Marko ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)
On 2014-03-16 19:42, Sean Farley wrote: If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I definitely don't want to start a discussion whether git or Mercurial is the better tool, but they both other integration to Subversion with git-svn [1] and hgsubversion [2]. I propose we change to our policies to make it possible to work with any tool locally, giving developers the choice to work with the tool they like the most, be it svn, git-svn, hgsubversion, bzr-svn, ... For example, both LLVM [3] and WebKit [4] keep Subversion as their main repository, but also encourage contributors to use git to prepare patches. In a perfect world, that would already be possible out of the box, for example working against our existing Git mirror of the MacPorts repository [5]. Unfortunately, these tools have some shortcomings that make working with our current ports tree impossible. The problems are the missing support for Subversion properties. a) No support for svn:ignore property Easy to accomplish, we would just keep the equivalent in .gitignore and .hgignore files in the repository root. The svn:ignore property would still be the authoritative value. As these are barely set at all in the ports tree, that should not be a problem. b) No support for svn:keywords property Most notably we are using svn:keywords to replace the $Id$ string in every Portfile. I think this string is of limited use and we could do without it. See also this ticket for a detailed discussion of the problem: http://trac.macports.org/ticket/38902 (Following the comments in the ticket, it's not even an issue with newer versions of git-svn any more. What about hgsubversion?) c) No support for svn:eol-style property Do we need that at all, anyway? I don't think anybody is editing this on Windows, so I doubt we would ever see a file with CRLF line endings. d) Optional, nice to have: mapping usernames to real names Both git and Mercurial usually display real names with email addresses instead of plain usernames. A file with that mapping can be used, but has to be kept in sync (or can be generated from the wiki). At the moment our git mirror uses handle@macports.org@UUID as committer. This correctly identifies the person, but is not very nice. e) Optional, nice to have: split base, doc, www, and ports tree With the current git mirror everyone interested in the ports tree is also required to fetch the trees for base/, doc/ and doc-new/, and www/. This is not about disk space as a git clone with full history actually takes less space than a Subversion working copy, but a separate repository might be easier to handle, especially when you can just add that to sources.conf. Note we already have contrib/ and users/ as separate repositories. Any other issues that you might have experienced that I forgot? Who is already using git-svn, hgsubversion, or similar tools for working with the ports tree? Rainer [1] https://www.kernel.org/pub/software/scm/git/docs/git-svn.html#_basic_examples [2] http://mercurial.selenic.com/wiki/HgSubversion [3] http://llvm.org/docs/GettingStarted.html#git-mirror [4] http://trac.webkit.org/wiki/UsingGitWithWebKit ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)
Hi, I'd like to chime in and offer my $.02. I'll try to keep it brief though, because nobody wants to read thousands of large opinionated posts in this thread if it's supposed to go somewhere. I think the popularity gives git the clear advantage over mercurial or any of the other systems. Also, recent versions of OS X ship with git in the command line tools, but it doesn't seem hg is in that package. Since one possible advantage of git would be to efficiently sync the ports tree using git, I think that gives git a clear advantage. I propose we change to our policies to make it possible to work with any tool locally, giving developers the choice to work with the tool they like the most, be it svn, git-svn, hgsubversion, bzr-svn, ... While I like the idea of that, I'm not sure it's really going to work well in the long run. We already have a number of people committing changes from mercurial or git-svn and especially the keywords keep getting mixed up on those. a) No support for svn:ignore property Easy to accomplish, we would just keep the equivalent in .gitignore and .hgignore files in the repository root. The svn:ignore property would still be the authoritative value. As these are barely set at all in the ports tree, that should not be a problem. I'd like to make a point against doing that. Keeping ignores in multiple files will only cause them to get out-of-sync. Some of the ignores in svn:ignore will sooner or later be committed as .gitignore files (to the SVN repository!), by oversight or on purpose. That's going to become a mess I'd like to avoid. b) No support for svn:keywords property c) No support for svn:eol-style property I agree we should drop those completely. d) Optional, nice to have: mapping usernames to real names If we'd move to a different VCS completely, we'd only have to get this right once. I don't think getting all the integration right in every detail is a task we have the manpower to do continuously. e) Optional, nice to have: split base, doc, www, and ports tree Definitely a good idea IMO. In the end I think the easiest way to get this done – if at all – is to choose a single blessed system and have everybody bite the bullet and learn it. In my opinion, that system should be git, just because it's becoming the de-facto standard tool for the job. I know others might be better in some aspects, and some of the internals of git are a little bit weird, but this was about making contribution easier for more people – and git gets that done. In regard to using Github: I don't think Github's issue tracker scales well to our needs. The port field is a must for a MacPorts issue tracker, IMO. I also think it's formatting capabilities are sub-par: try reproducing http://trac.macports.org/ticket/41466 in a Github issue. We could certainly move the wiki, but if we're keeping trac anyway I don't see the point. I've worked with Gerrit and Github and pull requests are definitely the easiest I've seen. However, they lack just in the same way as their tickets do. Please show me where Github has the same features now provided by http://trac.macports.org/report and http://trac.macports.org/query. I don't want MacPorts to be flooded with pull requests to a point where maintainers can no longer find those specific to their ports. Maybe we can instead improve documentation to a point where contributing is really easy – instead of going to Github and clicking pull request after git push, we should give people clear and precise steps to get their patch into $issuetracker. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Move part of macports infrastructure to GitHub
On 2014-3-17 05:42 , Sean Farley wrote: If MacPorts really wants to switch to distributed version control, then I would suggest Mercurial. I have experimented with using Mercurial for the MacPorts repo and found that the mercurial UI is much, much more consistent than git coming from Subversion. I would certainly agree with that. However I would also agree with what Landon said here: https://lists.macosforge.org/pipermail/macports-dev/2013-September/024252.html Rainer also did a great job of explaining why moving to github is a bad idea earlier in the thread. Much the same applies to bitbucket. I should note that I've used both git and hg for real work, and a modern DVCS certainly has its advantages. But that said, I really haven't felt like I was being restricted by svn while working on MacPorts. In fact, sometimes being able to check out a single file or directory deep in the tree comes in handy. If the majority of contributors really find that they are being held back by svn, I guess I would support moving our repos to hg. We could at least add an official hg mirror. But the OP said that the thread was about github and the convenience of pull requests, not git as such. If the problem is that people find it's too much trouble to svn diff and attach the output to a ticket, maybe client side automation is the solution. We have a script to apply a patch straight from a Trac URL, so why not one to create a ticket and attach a patch. It would be more complicated certainly, but if saving that handful of clicks gets more people involved, I guess it's worth it. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
