Re: Move part of macports infrastructure to GitHub

[Joshua Root]

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:


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

Re: Move part of macports infrastructure to GitHub

[Jeremy Lavergne]

Email is not the way to do voting >_<

On March 16, 2014 9:17:37 PM EDT, Blair Zajac  wrote:
>
>On Mar 16, 2014, at 11:52 AM, mk-macpo...@techno.ms wrote:
>
>> On 16 Mar 2014, at 19:42 , Sean Farley  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. :-)
>
>Since people are stating a preference between hg and git, I’ll throw in
>my hat and vote for git.
>
>Blair
>
>___
>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

[Blair Zajac]

On Mar 16, 2014, at 11:52 AM, mk-macpo...@techno.ms wrote:

> On 16 Mar 2014, at 19:42 , Sean Farley  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. :-)

Since people are stating a preference between hg and git, I’ll throw in my hat 
and vote for git.

Blair

___
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 ofmacportsinfrastructure to GitHub)b)

[Sean Farley]

Clemens Lang  writes:

> 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.

Sigh. The popularity of git has always surprised me since Mercurial
accomplishes the same thing and is much, much safer to use. 

I have been with many other teams that switched to git because of a few
(loud) proponents and never once was it worth the headache of git. As a
team, they have all suffered from someone tripping over one of
fast-forward merging, rebasing, or figuring out what 'git checkout'
really does.

Mercurial on the other hand guarantees safety of history rewriting
(through changeset evolution) and has the better scaling over git,
thanks to Facebook's contributions:

https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/

... but I digress. This has already turned into a git vs. hg flame war
and I did not want to go down that path.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with git-svn or hgsubversion

[Rainer Müller]

On 2014-03-16 23:57, Clemens Lang wrote:
>> 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.

That's why I started this thread to find out and discuss what we have to
change to make it work.

>> 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.

Of course I meant to store the .gitignore and .hgignore files in the
Subversion repository. In fact, we already have a .gitignore file in
trunk/. As I said, svn:ignore would still be authoritative and the other
files should only be generated.

.gitignore can be generated using 'git svn show-ignore > .gitignore'. As
an alternative, it would also be possible to use many small files in
each directory instead using 'git svn create-ignore'.

For .hgignore, Sean provided the command 'hg svn genignore' in another
reply.

The main starting point of this discussion was the ports tree, where
svn:ignore does not change often, so I don't see the additional
generation step as a problem.

Rainer
___
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 macportsinfrastructure to GitHub))

[Sean Farley]

Rainer Müller  writes:

> 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, ...

That's fine with me. Just a note that bazaar is pretty much dead, if I
understand correctly.

> 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.

I've worked a lot on integrating missing features into hgsubversion and
will respond below.

> 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.

This is generated with 'hg svn genignore'.

> 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?)

This is orthogonal to hgsubversion and is supported by keyword extension
(bundled with Mercurial for ages).

> 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.

Also bundled with Mercurial for ages.

> 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 "@macports.org@" as
>   committer. This correctly identifies the person, but is not very nice.

This has been supported in hgsubversion since the beginning. It just
needs an authormap which I provide in my Mercurial repo at
smf.io/macports.

Similarly, I've maintained mergeinfo, tags, branches, etc.

> 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.

Not a bad idea.
___
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)

[Clemens Lang]

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

Working with git-svn or hgsubversion (was: Move part of macports infrastructure to GitHub)

[Rainer Müller]

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 "@macports.org@" 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: Move part of macports infrastructure to GitHub

[MK-MacPorts]

On 16 Mar 2014, at 21:07 , Rainer Müller  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

Re: Root port update

[Lawrence Velázquez]

On Mar 16, 2014, at 12:53 PM, Chris Jones  wrote:

> Could i ask a commitor to take a look at
> 
> https://trac.macports.org/ticket/42867
> 
> It updates root to a new version, that fixes compilation with the latest 
> Xcode 5.1 on OSX 10.9, so it would be useful to get it out quickly.

https://trac.macports.org/changeset/117901

vq
___
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

[Rainer Müller]

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=macports&type=Repositories&ref=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

[Sean Farley]

Mark Anderson  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

[Mark Anderson]

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 


On Sun, Mar 16, 2014 at 3:31 PM, Sean Farley  wrote:

>
> Ryan Schmidt  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

[Sean Farley]

Ryan Schmidt  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

[Sean Farley]

Ivan Larionov  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

[Mark Anderson]

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 


On Sun, Mar 16, 2014 at 3:13 PM, Ivan Larionov wrote:

> 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  wrote:
>
>
> Ivan Larionov  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=macports&type=Repositories&ref=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]

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  wrote:

> 
> Ivan Larionov  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=macports&type=Repositories&ref=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

[Mark Anderson]

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 


On Sun, Mar 16, 2014 at 2:52 PM,  wrote:

> On 16 Mar 2014, at 19:42 , Sean Farley  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

[Ryan Schmidt]

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=macports&type=Repositories&ref=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

[MK-MacPorts]

On 16 Mar 2014, at 19:42 , Sean Farley  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

[Sean Farley]

Ivan Larionov  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=macports&type=Repositories&ref=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

Move part of macports infrastructure to GitHub

[Ivan Larionov]

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=macports&type=Repositories&ref=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

Root port update

[Chris Jones]

Hi,

Could i ask a commitor to take a look at

https://trac.macports.org/ticket/42867

It updates root to a new version, that fixes compilation with the latest Xcode 
5.1 on OSX 10.9, so it would be useful to get it out quickly.

Cheers Chris


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

[MK-MacPorts]

Hi Clemens,

thanks for the quick response.

I have done as requested, but that seems to lead to another problem:
—
$ ./testgraphical
file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
 File not found 
Killed: 9
—

But I guess that could be due to the application itself?!

I am new to this, so I don’t understand for a start why a URL is being 
displayed with this app.
I figure I need to consult KDE’s developer mailing list regarding this one, 
right?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

[MK-MacPorts]

Hi Clemens,

thanks for the quick response.

I have done as requested, but that seems to lead to another problem:
—
$ ./testgraphical
file:///Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/:
 File not found 
Killed: 9
—

But I guess that could be due to the application itself?!

I am new to this, so I don’t understand for a start why a URL is being 
displayed with this app.
I figure I need to consult KDE’s developer mailing list regarding this one, 
right?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

[Clemens Lang]

Hi,

> ./testgraphical.shell: line 4: 59742 Trace/BPT trap: 5
> DYLD_LIBRARY_PATH=/Users/marko/projects/TestGraphical/build/lib/./:/opt/local/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
> "/Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/testgraphical"
> "$@"

That's your problem right there: You're setting DYLD_LIBRARY_PATH. This is a 
common habit people coming from Linux have, expecting DYLD_LIBRARY_PATH to 
behave like LD_LIBRARY_PATH. It doesn't. Please don't set it unless you 
understand the implications it has (and yes, what you're seeing is actually 
expected behavior when setting it). Use DYLD_FALLBACK_LIBRARY_PATH instead, or 
better, none of those variables at all, because they are often not necessary. 
Libraries on OS X a typically referenced using absolute paths and if your 
binary correctly contains those absolute paths, DYLD_* variables are 
unnecessary. Please see the manpage for dyld(1) for more information.

> So, does this mean, that a system framework tries to use a library supplied
> by MacPorts?

Yes, because that's what DYLD_LIBRARY_PATH does – it forces the loader to 
ignore the path but the basename in a binary. That's really the only way a 
system framework can "use" a macports library.


> This is what otool tells me:
> —
> $ otool -L testgraphical
> testgraphical:
>   /opt/local/lib/libkdeui.5.dylib (compatibility version 5.0.0, current
>   version 5.12.2)
>   
> /opt/local/Library/Frameworks/QtDeclarative.framework/Versions/4/QtDeclarative
>   (compatibility version 4.8.0, current version 4.8.5)
>   /opt/local/lib/libkdecore.5.dylib (compatibility version 5.0.0, current
>   version 5.12.2)
>   /opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus
>   (compatibility version 4.8.0, current version 4.8.5)
>   /opt/local/Library/Frameworks/QtCore.framework/Versions/4/QtCore
>   (compatibility version 4.8.0, current version 4.8.5)
>   /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
> (compatibility
>   version 2.0.0, current version 157.0.0)
>   /opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui
>   (compatibility version 4.8.0, current version 4.8.5)
>   /opt/local/Library/Frameworks/QtSvg.framework/Versions/4/QtSvg
>   (compatibility version 4.8.0, current version 4.8.5)
>   /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
>   120.0.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>   1197.1.1)

That doesn't contain any non-absolute paths, you won't need DYLD_LIBRARY_PATH. 
Just don't set it and you'll be fine.

-- 
Clemens Lang
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

KDevelop-generated application crashes due to libJPEG.dylib on MacOSX 10.9.2

[MK-MacPorts]

Hi,

I am testing KDevelop a little.

After a short hiccup I was able to get a scaffold for a “graphical app” 
automagically built fine! :)

But the real problem starts when trying to run the app:
—
$ ./testgraphical.shell
dyld: Symbol not found: __cg_jpeg_resync_to_restart
  Referenced from: 
/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
  Expected in: /opt/local/lib/libJPEG.dylib
 in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
./testgraphical.shell: line 4: 59742 Trace/BPT trap: 5   
DYLD_LIBRARY_PATH=/Users/marko/projects/TestGraphical/build/lib/./:/opt/local/lib${DYLD_LIBRARY_PATH:+:$DYLD_LIBRARY_PATH}
 
"/Users/marko/projects/TestGraphical/build/src/testgraphical.app/Contents/MacOS/testgraphical"
 "$@"
—

So, does this mean, that a system framework tries to use a library supplied by 
MacPorts?

This is what otool tells me:
—
$ otool -L testgraphical
testgraphical:
/opt/local/lib/libkdeui.5.dylib (compatibility version 5.0.0, current 
version 5.12.2)

/opt/local/Library/Frameworks/QtDeclarative.framework/Versions/4/QtDeclarative 
(compatibility version 4.8.0, current version 4.8.5)
/opt/local/lib/libkdecore.5.dylib (compatibility version 5.0.0, current 
version 5.12.2)
/opt/local/Library/Frameworks/QtDBus.framework/Versions/4/QtDBus 
(compatibility version 4.8.0, current version 4.8.5)
/opt/local/Library/Frameworks/QtCore.framework/Versions/4/QtCore 
(compatibility version 4.8.0, current version 4.8.5)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 157.0.0)
/opt/local/Library/Frameworks/QtGui.framework/Versions/4/QtGui 
(compatibility version 4.8.0, current version 4.8.5)
/opt/local/Library/Frameworks/QtSvg.framework/Versions/4/QtSvg 
(compatibility version 4.8.0, current version 4.8.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1197.1.1)
—

Any hint on how to locate the culprit for the crash?

Greets,
Marko
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [117881] trunk/dports/science/netcdf

[Ryan Schmidt]

On Mar 16, 2014, at 00:02, take...@macports.org wrote:

> Revision
> 117881
> Author
> take...@macports.org
> Date
> 2014-03-15 22:02:06 -0700 (Sat, 15 Mar 2014)
> Log Message
> 
> netcdf: updated for 4.3.1.1. Obtain distfiles from github using PortGroup 
> github. Commented out mpi.enforce_variant hdf5-18

> Modified: trunk/dports/science/netcdf/Portfile (117880 => 117881)

> +github.setupUnidata netcdf-c 4.3.1.1 v
> 
>  namenetcdf
> 
> -epoch   2
> -version 4.3.0
> -revision3

The epoch line has to be put back. Once an epoch line has been added to a port, 
the epoch can never be decreased, nor removed (which has the effect of setting 
it to 0). Decreasing or removing the epoch means that nobody will be informed 
of this update via “port outdated”.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev