Move part of macports infrastructure to GitHub

[Eric Gallager]

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 <jmr at 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 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/20140317/0e63ab72/attachment-0001.html>