Move part of macports infrastructure to GitHub

Mark Anderson emer at emer.net
Tue Mar 18 19:15:47 PDT 2014


Related side question:
Does our install of Trac have any public APIs (XMLRPC, REST, SOAP,
whatever)?

Mark



--Mark
_______________________
Mark E. Anderson <emer at emer.net>


On Tue, Mar 18, 2014 at 3:51 PM, Landon Fuller <landonf at macports.org> wrote:

>
> On Mar 16, 2014, at 11:40 PM, Joshua Root <jmr at 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 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/20140318/bbba1303/attachment.html>


More information about the macports-dev mailing list