Move part of macports infrastructure to GitHub

[Eric Gallager]

On Thu, Mar 20, 2014 at 7:19 PM, Ryan Schmidt <ryandesign at macports.org>wrote:

>
> 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=!closed&keywords=~haspatch&desc=1&order=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 at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140320/5e3a1fa8/attachment.html>