Friendly talk

[Landon J Fuller]

On Sep 3, 2013, at 10:22 AM, Blair Zajac <blair at orcaware.com> wrote:

> On 09/03/2013 02:53 AM, Rainer Müller wrote:
>> On 2013-09-03 11:23, Guido Soranzio wrote:
>>> On Aug 29,David Strubbe-2 wrote:
>>> 
>>>> What the advantages and disadvantages does Homebrew have with respect to MacPorts?
>>> 
>>> 
>>> If you are very passionate about Cocoa and dynamic languages, I think you
>>> can’t ignore Ruby and GitHub.
>> 
>> GitHub is just quite popular right now. About 10 years ago everybody
>> used sourceforge.net, now it is GitHub. I don't see the connection
>> between an interest in dynamic languages and a repository hosting provider.
>> 
>>> There’s a very vibrant community growing around the CocoaPods, a new
>>> package manager written in Ruby which allows to integrate hundreds of
>>> open source libraries and components in you Xcode projects.
>> 
>> Hm, a manager for source code of libraries seems different to what
>> MacPorts does.
>> 
>>> Forking and sharing you personal work is very easy in Homebrew and
>>> CocoaPods. You can also “tap” directly other personal repositories
>>> before their inclusion in the official trees.
>> 
>> You can do the same with MacPorts ever since. Although we only support
>> git for that now as of 2.2.0, but you could already use rsync, tarball
>> over HTTP/FTP, Subversion as well before. [1]
>> 
>> Although setup and documentation of this last step could be improved.
>> It's highly similar to these HOWTOs, just use a different URL:
>> 
>> https://trac.macports.org/wiki/howto/SyncingWithSVN
>> https://trac.macports.org/wiki/howto/PortTreeTarball
> 
> This is missing the point of github.  Yes, we can support git, but using github in particular makes it incredibly easy for somebody to contribute to the project.
> 
> As somebody who uses on a bunch of different projects, e.g. Cassandra's Java Driver recently, it was very easy to fork the repo, do a commit, push it back to github and do the pull request.  The maintainers of the project can comment on the request and with one click, accept the work into 'trunk'.

I don't particularly like GitHub and wouldn't want to maintain software there if I can avoid it. We already host our own code, issues, etc; when the next thing supplants GitHub in X years time, I don't really want to worry about trying to migrate the entire project.

There are already git mirrors of MacPorts; also mirroring to GitHub would not be a problem. The cost involved in merging people's work *isn't* that it's too hard to apply their patches, it's that doing so requires local validation, careful review, and consideration. As a developer, I don't find "git format-patch"  and "git apply" (or "svn diff" and "svn apply") to be any more onerous than using Github's web UI to submit a pull request (which invariably also seems to result in people submitting useless bug reports, because they think the code plus a single line summary speaks entirely for itself).

If anything, providing more documentation on how to host  your own ports tree might be a great addition to MacPorts, as well as a simple command that could be used to add/remove external repositories. That said, in my experience, people use tools like Github forking to hack out poorly considered changes and support their use of development models that are based in constant churn and regressions, and I wouldn't expect to see a substantial improvement in submission quality or overall stability; quite the opposite. The cost in producing good software was never in the SCM.

-landonf