Re: Issues with oudated ports / GitHub

[Clemens Lang]

Hi,

On Fri, Oct 07, 2016 at 09:13:11AM -0500, Ryan Schmidt wrote:
> Regarding updating pandoc, see https://trac.macports.org/ticket/48324
> Regarding updating ghc, see https://trac.macports.org/ticket/48899
> Regarding old llvm on Sierra, see https://trac.macports.org/ticket/52424

As a follow-up on the whole GHC vs. LLVM (and thus Pandoc) topic: In the
past, we packaged a subset of GHC and Haskell ports that did not match
the versions in haskell-platform. Feedback back then was that we should
stay with the haskell platform, so we did.

For this reason, I cannot simply update GHC without updating
haskell-platform (unless we want to re-visit this decision). I have the
update of GHC and the platform ports to version 8.0.1 [1] done, expect
for stack [2]. Haskell Platform without Stack seems less useful, since
Stack is supposed to become a de-facto dev environment management tool,
if I understand things correctly. Unfortunately, stack has a gazillion
dependencies we haven't packaged yet, at which point it makes little
sense for me to attempt to write all those Portfiles by hand. So either:
 - a group of people splits the work
 - generation of haskell portfiles needs to be automated
I'd welcome help with both. Let me know if you know a Haskell or two and
want to help out with the latter.

[1] https://www.haskell.org/platform/contents.html
[2] http://hackage.haskell.org/package/stack

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

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

Please, everyone, stop. We are keeping our Trac issue tracker; this has been 
decided. We will not use GitHub issues at this time because it does not have 
the features we need. We will move our code to GitHub because it has been 
requested by many users over the years and will help attract new developers. We 
have already moved our web site news feed to GitHub Pages and may make use of 
other GitHub infrastructure over time. macOS forge was being shut down, so it 
was necessary for us to move anyway, and this gave us the incentive to make the 
jump to git and GitHub. We have not yet defined, any we are attempting in 
conversations on this mailing list to figure out, how we will work with GitHub. 
We will not deliberately introduce obstacles that make contributions difficult. 
We will automate cross-linking between GitHub pull requests and Trac tickets. 
Thank you.

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

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Sat, Oct 8, 2016 at 7:48 PM, Marcel Bischoff 
wrote:

> I understand that. Many long-running projects are using their own Git
> infrastructure with Trac, Redmine and others. What I don't understand is
> why moving to GitHub at all when the tooling is clearly insufficient for
> the project. The added exposure? The hope to attract new developers? If
> the needs of the "people who actually do the work" are paramount, GitHub
> is probably not adding much to improve ingrained workflows but rather
> slow them down.
>

I prefer to let someone more official address this, but suffice it to say
it wasn't entirely the MacPorts folks' idea.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Brandon Allbery wrote:

On Sat, Oct 8, 2016 at 4:12 PM, Marcel Bischoff 
wrote:


I for one don't understand why one would carry around all that baggage
anyhow. Why not leave the old Trac as is and start fresh with a simple,
reduced issue tracker



When the simple reduced tracker is, as already said, too simple. It is in
fact the very "Only if it was really, really awful. But then they would have
changed it a long time ago." you already mentioned: yes, it's simple for
you the end user, but it doesn't do what the people who actually do the
work need it to do (and this is true across many projects, some of which
have had to build their own additional tooling to interface with Github and
try to add all the functionality it doesn't provide).


I understand that. Many long-running projects are using their own Git
infrastructure with Trac, Redmine and others. What I don't understand is
why moving to GitHub at all when the tooling is clearly insufficient for
the project. The added exposure? The hope to attract new developers? If
the needs of the "people who actually do the work" are paramount, GitHub
is probably not adding much to improve ingrained workflows but rather
slow them down.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Sat, Oct 8, 2016 at 4:27 PM, Chris Jones 
wrote:

> What concerns me is the statement that in this migration to github, github
> and trac are kept completely separate, with no automatic linkage, but still
> contributors are expected to use both.


What I heard was that, due to time constraints, it will initially be kept
separate while people figured out what tooling was needed and the best way
to proceed. (Also note that they're already looking at Trac/Github
integration plugins, and something useful may turn out to be easy to add to
improve Trac integration. Possibly something like catching new GHI tickets,
copying them into Trac, and closing the GHI ticket with a link to the Trac
ticket.) But it will probably happen at some point, because GHI is pretty
much the minimum they can get away with and provides no sane way to work
with something more capable aside from a handful of hooks that don't even
provide the ability to remap ticket references. :/

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Sat, Oct 8, 2016 at 4:12 PM, Marcel Bischoff 
wrote:

> I for one don't understand why one would carry around all that baggage
> anyhow. Why not leave the old Trac as is and start fresh with a simple,
> reduced issue tracker
>

When the simple reduced tracker is, as already said, too simple. It is in
fact the very "Only if it was really, really awful. But then they would have
changed it a long time ago." you already mentioned: yes, it's simple for
you the end user, but it doesn't do what the people who actually do the
work need it to do (and this is true across many projects, some of which
have had to build their own additional tooling to interface with Github and
try to add all the functionality it doesn't provide).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Chris Jones wrote:




On 8 Oct 2016, at 11:29 am, Ryan Schmidt  wrote:



On Oct 7, 2016, at 2:18 PM, Christopher Jones  wrote:



On 7 Oct 2016, at 8:12 pm, Ryan Schmidt  wrote:



On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  wrote:

On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:

Currently, once they find out about svn, and trac


We will still use Trac for issue tracking, although I believe someone is
looking into integrating GitHub sign in.


Rainer and Clemens looked into this and got it up and running on our test 
installation.



So what exactly does this mean ?


It means you will log in to our Trac installation using your GitHub 
credentials, instead of via Mac OS Forge credentials as it is now.



Because, honestly, once the migration to GitHub is done unless comments sent to 
a github pull request are automatically sync’ed to trac, and vice versa, I do 
not see how trac can be maintained as a via system for discussing the pull 
requests (and frankly I din’t really see why you would want to).


There will be no syncing of anything between GitHub pull requests and Trac 
tickets because they are different entities. Trac tickets are where bug reports 
and other issues will be filed. Currently, if someone has a fix for an issue, 
they would attach a patch to the Trac ticket; in future, they will instead open 
a GitHub pull request and paste a link to the pull request into the ticket (or 
paste a link to the Trac ticket into the pull request; I'm not sure if we've 
decided that detail yet).


At my work we use gitlab and Jira in a similar way, but there is automatic 
links between the two, in that if i quote a jira id in a git lab merge request, 
links between the two is produced automatically. Having to do this by hand 
strikes me as potentially error prone and a little cumbersome.


And as Rainer said, there may be some simple changes for which it is sufficient 
to just submit a pull request, without opening a corresponding Trac ticket. We 
haven't defined what those situations would be yet.


I would hope that for a simple updates to a port, that isn't addressing
a bug report, then no trac ticket will required. The pull request
really should be enough in this case, and if any discussion on the
update is required it can occur in the pull request. If during the
course of that discussion it transpires the update needs more work,
then fine a trac ticket could be opened at that point. But  would hope
for most it would simply not be necessary, and if it where a
requirement to always do this i think that would be an unnecessary
overhead.


This is how I feel as well. Having Trac running in parrallel to GitHub
feels like overhead that's just there because it's there. I understand
the need to use advanced functionality and having worked with any one
piece of technology for a decade, people are not going to change away
it. Only if it was really, really awful. But then they would have
changed it a long time ago. It's force of habit. When looking for
alternatives you compare them to your ingrained habits — that is not
going to work. Any major deviation will always feel not quite right.

I for one don't understand why one would carry around all that baggage
anyhow. Why not leave the old Trac as is and start fresh with a simple,
reduced issue tracker? Splitting discussion and code on two platforms
will create overhead. Unnecessary overhead I may add. Code and
discussion should go hand in hand.

I see this happening in the future: a first-time contributor opens a
pull request with a new port (not an update to an existing one),
describing everthing of value in the pull request itself. The
contributor will not open a Trac ticket because he has just opened the
pull request which is self-explanatory and doesn't want to enter all
that information a second time. The pull request gets ignored or
rejected because the contributor did not open a proper Trac ticket. The
contributor has a bad experience, decides to devote his time to a less
bureocratic project and quietly leaves.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Joshua Root]

On 2016-10-9 06:10 , Marcel Bischoff wrote:

On 16/10/08, Ryan Schmidt wrote:



On Oct 8, 2016, at 8:30 AM, Marcel Bischoff 
wrote:

I see where you're coming from. However, your approach is contrary to
how the majority of issues are handled on services like GitHub. If the
ticket is too old, stale, not applicable any more or simply does not
receive any answer for weeks/months, it will usually be closed with a
note stating that. This helps keep the number of issues/tickets down to
a manageable level and avoids tickets being active for 11 years.


Well, we're not hosting issues on GitHub; we're hosting them on Trac.
And I don't want to close tickets that have not been dealt with.


It should be easy to just tag those issues as "abandoned" and close
them, so you can comfortably find them again at any point.


For something like a port submission that has never reached a working 
state, it might be reasonable to close the ticket with a resolution that 
indicates that work stalled and appears unlikely to resume. Or if 
there's a report of a bug that we can't reproduce, and we've asked the 
reporter for more info, and that info has not been provided, then that 
would be reasonable to close as well ("worksforme"). And certainly if a 
bug is no longer applicable, that's synonymous with "fixed".


But the idea that a valid, unfixed ticket can be "too old" makes no 
sense to me. Closing such a ticket without doing anything to resolve it 
doesn't mean you're actually more productive or responsive or whatever. 
(No doubt it makes certain stats look good.)


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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/08, Ryan Schmidt wrote:



On Oct 8, 2016, at 8:30 AM, Marcel Bischoff  wrote:

On 16/10/08, Ryan Schmidt wrote:




Requests for new ports could still be valid after years. This list could
be helpful for newcomers that want to create new ports.


Totally agree - but I'd close everything over six months old or something like that for 
optics. People can still search to "closed" tickets if they want.


It seems counterproductive to me to close a ticket if you're not addressing the 
issue. Just because nobody has done anything with a ticket for 6 months or 2 
years or whatever period of time doesn't necessarily mean that the issue is no 
longer valid, just that nobody has had time to deal with it yet.

When I go searching for tickets, I don't typically search for closed
tickets, because I assume that closed tickets are closed because
they've been dealt with. If we change that rule now, it will mean that
I either don't find tickets that might have been relevant to whatever
I'm searching for, or that I have to remember to search for closed
tickets and spend a lot of time sifting through tickets that have
already been dealt with.


I see where you're coming from. However, your approach is contrary to
how the majority of issues are handled on services like GitHub. If the
ticket is too old, stale, not applicable any more or simply does not
receive any answer for weeks/months, it will usually be closed with a
note stating that. This helps keep the number of issues/tickets down to
a manageable level and avoids tickets being active for 11 years.


Well, we're not hosting issues on GitHub; we're hosting them on Trac. And I 
don't want to close tickets that have not been dealt with.


It should be easy to just tag those issues as "abandoned" and close
them, so you can comfortably find them again at any point.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Chris Jones]

> On 8 Oct 2016, at 11:29 am, Ryan Schmidt  wrote:
> 
> 
>> On Oct 7, 2016, at 2:18 PM, Christopher Jones  
>> wrote:
>> 
>> 
>>> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt  wrote:
>>> 
>>> 
> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  
> wrote:
> 
> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
> 
> Currently, once they find out about svn, and trac
 
 We will still use Trac for issue tracking, although I believe someone is
 looking into integrating GitHub sign in.
>>> 
>>> Rainer and Clemens looked into this and got it up and running on our test 
>>> installation.
>>> 
>> 
>> So what exactly does this mean ?
> 
> It means you will log in to our Trac installation using your GitHub 
> credentials, instead of via Mac OS Forge credentials as it is now.
> 
> 
>> Because, honestly, once the migration to GitHub is done unless comments sent 
>> to a github pull request are automatically sync’ed to trac, and vice versa, 
>> I do not see how trac can be maintained as a via system for discussing the 
>> pull requests (and frankly I din’t really see why you would want to).
> 
> There will be no syncing of anything between GitHub pull requests and Trac 
> tickets because they are different entities. Trac tickets are where bug 
> reports and other issues will be filed. Currently, if someone has a fix for 
> an issue, they would attach a patch to the Trac ticket; in future, they will 
> instead open a GitHub pull request and paste a link to the pull request into 
> the ticket (or paste a link to the Trac ticket into the pull request; I'm not 
> sure if we've decided that detail yet).

At my work we use gitlab and Jira in a similar way, but there is automatic 
links between the two, in that if i quote a jira id in a git lab merge request, 
links between the two is produced automatically. Having to do this by hand 
strikes me as potentially error prone and a little cumbersome.

> And as Rainer said, there may be some simple changes for which it is 
> sufficient to just submit a pull request, without opening a corresponding 
> Trac ticket. We haven't defined what those situations would be yet.

I would hope that for a simple updates to a port, that isn't addressing a bug 
report, then no trac ticket will required. The pull request really should be 
enough in this case, and if any discussion on the update is required it can 
occur in the pull request. If during the course of that discussion it 
transpires the update needs more work, then fine a trac ticket could be opened 
at that point. But  would hope for most it would simply not be necessary, and 
if it where a requirement to always do this i think that would be an 
unnecessary overhead.

Cheers Chris


> 
> 

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

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

On Oct 8, 2016, at 7:57 AM, Davide Liessi  wrote:
> 
> Il sabato 8 ottobre 2016, Ryan Schmidt  ha scritto:
>> in future, they will instead open a GitHub pull request and paste a link to 
>> the pull request into the ticket (or paste a link to the Trac ticket into 
>> the pull request; I'm not sure if we've decided that detail yet).
>  
> I think the ideal would be to do both things (i.e. cross-link in both 
> directions).

Yes, we certainly want things cross-linked, it's just a matter of whether that 
will be done automatically. I imagine it will be, I just don't know right this 
second whether it will matter which link the user creates, and which one will 
be automatically added.

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

On Oct 8, 2016, at 6:34 AM, Ryan Schmidt  wrote:

> It seems counterproductive to me to close a ticket if you're not addressing 
> the issue. Just because nobody has done anything with a ticket for 6 months 
> or 2 years or whatever period of time doesn't necessarily mean that the issue 
> is no longer valid, just that nobody has had time to deal with it yet.

It would be nice if there were a third state between "open" and "closed" for 
this.

(Then again, "it would be nice" if tickets just fixed themselves, so….)

> When I go searching for tickets, I don't typically search for closed tickets, 
> because I assume that closed tickets are closed because they've been dealt 
> with. If we change that rule now, it will mean that I either don't find 
> tickets that might have been relevant to whatever I'm searching for, or that 
> I have to remember to search for closed tickets and spend a lot of time 
> sifting through tickets that have already been dealt with.

This would be difficult even with a "lack-of-interest" keyword, now that you 
mention it. Today we can search for tickets that are (!closed AND [other 
conditions]). If we start closing stale tickets, one would have to search for 
tickets that are (!closed OR (closed AND keyword ~ lack-of-interest)) AND 
whatever other conditions you care about.

vq
Sent from my iPhone
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 7:07 PM, Bradley Giesbrecht  wrote:
> 
>> On Oct 7, 2016, at 4:02 PM, Rainer Müller  wrote:
>> 
>> On 2016-10-07 20:58, Christopher Jones wrote:
>>> 
 On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez 
 wrote:
 
> On Oct 7, 2016, at 2:09 PM, Chris Jones
>  wrote:
> 
> Currently, once they find out about svn, and trac
 
 We will still use Trac for issue tracking, although I believe
 someone is looking into integrating GitHub sign in.
>> 
>> Trac will stay. Clemens and I already wrote new modules for the
>> trac-github plugin [1] in order to allow both login with GitHub as main
>> authentication provider, migrating old tickets from mail addresses to
>> the GitHub accounts and all permissions in Trac will be based on team
>> memberships on GitHub.
>> 
>> The only downside is that references to tickets will have to become full
>> URLs to Trac, because GitHub claims the #12345 syntax for their own
>> issue tracker and pull requests. Commits which contain such an URL will
>> automatically be linked from the corresponding ticket.
> 
> See comment below, we use #12345 syntax in with our Redmine issue tracker.

The problem is that when you write "#12345" in a git commit message, the GitHub 
repository browser web interface will link that to GitHub issue or pull request 
#12345; you cannot prevent that. Therefore, we must not use that syntax, except 
when we really mean to refer to a GitHub pull request, and must instead use the 
full Trac URL to tickets when we are referring to Trac tickets.


>>> Personally I think we have to migrate away from trac as well. Pull
>>> requests in GitHub will largely replace what happens in trac for
>>> submission of patches and the discussion of them. If we stick with
>>> trac for issues then for me it will be an utter mess.
>> 
>> Pull requests can be used in addition to tickets. For simple port
>> updates, there will be no need to open a ticket.
>> 
>> We evaluated several options, including issue trackers provided by
>> GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the
>> conclusion that Trac is still the best option at hand.
>> 
>> Especially with hosting our own installation, we will finally be able to
>> make more modifications and use custom plugins, that we never got
>> deployed at Mac OS Forge (for example [2]).
> 
> 
> Redmine is outstanding in my opinion.
> 
> There is a Redmine github plugin [1] allowing Redmine installation to receive 
> Github post-receive notifications.

> [1] https://github.com/koppen/redmine_github_hook

Just as there is a trac-github plugin which we're going to use.


> Redmine parses commit messages for configurable strings and can change issue 
> status and add commit references to issue.

Rainer and Clemens are working on doing that for our new Trac install as well.


> Redmine can work with Subversion, Darcs, Mercurial, Bazaar, Git, and others.

Trac works with Git and Subversion; I don't know if it works with others but I 
don't care because we don't use others.


> Oh, and Redmine is a quick and easy rails install away.

I assume Trac wasn't hard to install, but in any case, we've got it installed 
already.


We are staying with Trac for now; evaluations of other systems and discussions 
of their respective merits have concluded. Staying with Trac is the easiest 
option, given all the other work we still have to do to convert to GitHub. We 
can always revisit it later, should the capabilities of other systems change 
for the better.



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

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 3:25 PM, Marcel Bischoff  wrote:
> 
> On 16/10/07, Brandon Allbery wrote:
>> On Fri, Oct 7, 2016 at 2:38 PM, Daniel J. Luke  wrote:
>> 
>>> the cool kids also aren't writing 'tcl' these days ...
>> 
>> 
>> ...but the way they write anything else, they might as well be writing
>> fortran...
> 
> Let me just chime in here and say that those kinds of attitudes are
> exactly what I mean when I write "exclusive". It's good and fine to have
> certain standards but dismissing the majority of possible contributors
> for not meeting your personal interpretation of How Things Should Be(tm)
> is surely not helping getting MacPorts more traction. A major effort
> should be to make it as easy and straight-forward for new developers to
> contribute in a way that is considered acceptable.

I have no intention of dismissing any contributors in advance. I'll judge each 
contribution on its merits.

I agree we need to make it easier to contribute. It's going to be a long 
process of redesigning web sites, rewriting documentation, etc.

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 3:24 PM, Ken Cunningham  
> wrote:
> 
>> On 2016-10-07, at 10:05 AM, Rainer Müller wrote:
>> 
>> I am not sure how we could change these to make triaging trickets
>> easier.
> 
> I can't easily just look at the list and see what are new requests for
> ports to be included in macports. It all mixed in with other things.

You can use a Trac query for this:

https://trac.macports.org/query?status=!closed=request=ports

The Tickets page [1] on Trac has links for several such queries, there is
a list of various Trac reports [2], and you can construct a custom query
if you need to [3]. 

It might be useful to add more query links to the Tickets page.

[1]: https://trac.macports.org/wiki/Tickets
[2]: https://trac.macports.org/report
[3]: https://trac.macports.org/query

> Like Ryan said, I'd have separate queues for each major
> category..

That's not really what Ryan said. He was just pointing out that our
current selection of ticket types is inconsistent, not that we should
add a bunch more.

> let's see -- 
> 
>   new incoming port requests that anyone could claim - port that
>   don't exist in macports at present

https://trac.macports.org/query?status=!closed=request=ports=macports-tickets%40lists.macosforge.org

>   new portfiles that have been finished and are awaiting committer
>   review

https://trac.macports.org/query?status=!closed=submission=ports

>   requests for updates to existing ports by people who have
>   noticed something out on the web of significance.

https://trac.macports.org/query?status=!closed=update=ports=!~haspatch

>   port updates with patches (approved by maintainer if there is
>   one) waiting for committer review

https://trac.macports.org/query?status=!closed=update=ports=~haspatch

>> Requests for new ports could still be valid after years. This list
>> could be helpful for newcomers that want to create new ports.
> 
> Totally agree - but I'd close everything over six months old or
> something like that for optics. People can still search to "closed"
> tickets if they want.

I think we have a collective hoading instinct w.r.t. tickets. (Don't
close that ticket! I might work on it one day. Really.) Perhaps we could
be more bold about closing tickets with Rainer's "lack-of-interest"
keyword, while making it easy to find all such tickets.

https://trac.macports.org/query?status=closed=~lack-of-interest

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

Re: Issues with oudated ports / GitHub

[Bradley Giesbrecht]

> On Oct 7, 2016, at 4:02 PM, Rainer Müller  wrote:
> 
> On 2016-10-07 20:58, Christopher Jones wrote:
>> 
>>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez 
>>> wrote:
>>> 
 On Oct 7, 2016, at 2:09 PM, Chris Jones
  wrote:
 
 Currently, once they find out about svn, and trac
>>> 
>>> We will still use Trac for issue tracking, although I believe
>>> someone is looking into integrating GitHub sign in.
> 
> Trac will stay. Clemens and I already wrote new modules for the
> trac-github plugin [1] in order to allow both login with GitHub as main
> authentication provider, migrating old tickets from mail addresses to
> the GitHub accounts and all permissions in Trac will be based on team
> memberships on GitHub.
> 
> The only downside is that references to tickets will have to become full
> URLs to Trac, because GitHub claims the #12345 syntax for their own
> issue tracker and pull requests. Commits which contain such an URL will
> automatically be linked from the corresponding ticket.

See comment below, we use #12345 syntax in with our Redmine issue tracker.

>> Personally I think we have to migrate away from trac as well. Pull
>> requests in GitHub will largely replace what happens in trac for
>> submission of patches and the discussion of them. If we stick with
>> trac for issues then for me it will be an utter mess.
> 
> Pull requests can be used in addition to tickets. For simple port
> updates, there will be no need to open a ticket.
> 
> We evaluated several options, including issue trackers provided by
> GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the
> conclusion that Trac is still the best option at hand.
> 
> Especially with hosting our own installation, we will finally be able to
> make more modifications and use custom plugins, that we never got
> deployed at Mac OS Forge (for example [2]).


Redmine is outstanding in my opinion.

There is a Redmine github plugin [1] allowing Redmine installation to receive 
Github post-receive notifications.

Redmine parses commit messages for configurable strings and can change issue 
status and add commit references to issue.

Redmine can work with Subversion, Darcs, Mercurial, Bazaar, Git, and others.

Oh, and Redmine is a quick and easy rails install away.


[1] https://github.com/koppen/redmine_github_hook


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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

On 2016-10-07 19:07, Marcel Bischoff wrote:
> On 16/10/07, Ryan Schmidt wrote:
>> The problem is: somebody needs to do the correct work to update each of
>> those ports to the latest version. In many cases, tickets are already
>> filed, and you can look them up to see what the current status is; if
>> you don't find a ticket, please file a new one. In some cases, such as
>> boost, pandoc, ghc, there are serious issues preventing the update. If
>> Homebrew has solved those problems, great, maybe we can crib from them.
> 
> Again, I was under the impression that to be a port maintainer you would
> actually need to maintain the port. In this case, checking out what
> Homebrew is doing and trying to implement it the MacPort way. As this
> does not appear to be the case, I guess when things are broken, they are
> just considered being broken.

Anybody can get listed as maintainer, making the promise to do that.
However, when they are not actually keeping it up-to-date, there is
little we can do about it. After following the port abandonment policy,
will will drop the port back to "nomaintainer", leaving you in the same
situation.

> I don't see any concrete discussion as to why certain ports would not
> build, nor any kind of coordination between different port maintainers.
> This may very well be my fault due to selective perception on my part.
> I'm just a bit confised as to why one project can figure it out while
> another lags months or years behind in certain areas.

As soon as I figure out why a port does not build, I might just commit a
fix instead of writing lengthy discussions on that. :-)

> I'll be sure to devote some time to help solve long-standing issues. The
> proper mailing list to discuss those issues is this one I presume?

Yes, definitely. Comments on commits will be discussed here as well as
discussions originally started at tickets that will require more help
from others.

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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

On 2016-10-07 20:58, Christopher Jones wrote:
> 
>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez 
>> wrote:
>> 
>>> On Oct 7, 2016, at 2:09 PM, Chris Jones
>>>  wrote:
>>> 
>>> Currently, once they find out about svn, and trac
>> 
>> We will still use Trac for issue tracking, although I believe
>> someone is looking into integrating GitHub sign in.

Trac will stay. Clemens and I already wrote new modules for the
trac-github plugin [1] in order to allow both login with GitHub as main
authentication provider, migrating old tickets from mail addresses to
the GitHub accounts and all permissions in Trac will be based on team
memberships on GitHub.

The only downside is that references to tickets will have to become full
URLs to Trac, because GitHub claims the #12345 syntax for their own
issue tracker and pull requests. Commits which contain such an URL will
automatically be linked from the corresponding ticket.

> Personally I think we have to migrate away from trac as well. Pull
> requests in GitHub will largely replace what happens in trac for
> submission of patches and the discussion of them. If we stick with
> trac for issues then for me it will be an utter mess.

Pull requests can be used in addition to tickets. For simple port
updates, there will be no need to open a ticket.

We evaluated several options, including issue trackers provided by
GitHub, GitLab, BitBucket, JIRA, and also others and finally came to the
conclusion that Trac is still the best option at hand.

Especially with hosting our own installation, we will finally be able to
make more modifications and use custom plugins, that we never got
deployed at Mac OS Forge (for example [2]).

Rainer

[1] https://github.com/trac-hacks/trac-github
[2] https://trac.macports.org/ticket/40987
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Brandon Allbery wrote:

On Fri, Oct 7, 2016 at 2:38 PM, Daniel J. Luke  wrote:


the cool kids also aren't writing 'tcl' these days ...



...but the way they write anything else, they might as well be writing
fortran...


Let me just chime in here and say that those kinds of attitudes are
exactly what I mean when I write "exclusive". It's good and fine to have
certain standards but dismissing the majority of possible contributors
for not meeting your personal interpretation of How Things Should Be(tm)
is surely not helping getting MacPorts more traction. A major effort
should be to make it as easy and straight-forward for new developers to
contribute in a way that is considered acceptable.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ken Cunningham Webuse]

On 2016-10-07, at 10:05 AM, Rainer Müller wrote:

> I am not sure how we could change these to make triaging trickets easier.

I can't easily just look at the list and see what are new requests for ports to 
be included in macports. It all mixed in with other things.

Also, the committer time needs to be more protected to keep things moving more 
quickly. The fairly small group of committers with the deep MacPorts knowledge 
and experience frankly doesn't have time to do the mass of grunt work. They 
should be mostly reviewing and commenting on other's work, sending things back 
for needed fixes, rather than writing much themselves. And there might need to 
be a distinction between style critique and actual function failures, as things 
do have to move along.

Like Ryan said, I'd have separate queues for each major category..let's see -- 

new incoming port requests that anyone could claim - port that don't 
exist in macports at present

new portfiles that have been finished and are awaiting committer review

requests for updates to existing ports by people who have noticed 
something out on the web of significance. 

port updates with patches (approved by maintainer if there is one) 
waiting for committer review


> Requests for new ports could still be valid after years. This list could
> be helpful for newcomers that want to create new ports. 

Totally agree - but I'd close everything over six months old or something like 
that for optics. People can still search to "closed" tickets if they want.

I'm still thinking of resurrecting the hylafax portfile from 8 or so years ago. 
And I did just use the webmin portfile from about the same vintage two weeks 
ago :>


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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 8:12 pm, Ryan Schmidt  wrote:
> 
> 
>> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  wrote:
>> 
>>> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>>> 
>>> Currently, once they find out about svn, and trac
>> 
>> We will still use Trac for issue tracking, although I believe someone is
>> looking into integrating GitHub sign in.
> 
> Rainer and Clemens looked into this and got it up and running on our test 
> installation.
> 

So what exactly does this mean ?

Because, honestly, once the migration to GitHub is done unless comments sent to 
a github pull request are automatically sync’ed to trac, and vice versa, I do 
not see how trac can be maintained as a via system for discussing the pull 
requests (and frankly I din’t really see why you would want to).

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

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 1:40 PM, Lawrence Velázquez  wrote:
> 
>> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>> 
>> Currently, once they find out about svn, and trac
> 
> We will still use Trac for issue tracking, although I believe someone is
> looking into integrating GitHub sign in.

Rainer and Clemens looked into this and got it up and running on our test 
installation.


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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 8:08 pm, Lawrence Velázquez  wrote:
> 
>> On Oct 7, 2016, at 2:58 PM, Christopher Jones  
>> wrote:
>> 
>>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez  wrote:
>>> 
 On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
 
 Currently, once they find out about svn, and trac
>>> 
>>> We will still use Trac for issue tracking, although I believe someone is
>>> looking into integrating GitHub sign in.
>> 
>> Personally I think we have to migrate away from trac as well. Pull
>> requests in GitHub will largely replace what happens in trac for
>> submission of patches and the discussion of them. If we stick with
>> trac for issues then for me it will be an utter mess.
> 
> We will not be migrating to GitHub Issues in its current form. Several
> of us (not me) have already evaluated it as a possible Trac replacement
> and concluded that it is insufficient for our needs.

OK… I predict a lot discussion will naturally start to happen associated with 
the pull requests, as that will be the most natural place to discuss them, so I 
think this decision will need to be re-assessed at some ...

Chris

> 
> vq

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

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 2:58 PM, Christopher Jones  
> wrote:
> 
>> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez  wrote:
>> 
>>> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>>> 
>>> Currently, once they find out about svn, and trac
>> 
>> We will still use Trac for issue tracking, although I believe someone is
>> looking into integrating GitHub sign in.
> 
> Personally I think we have to migrate away from trac as well. Pull
> requests in GitHub will largely replace what happens in trac for
> submission of patches and the discussion of them. If we stick with
> trac for issues then for me it will be an utter mess.

We will not be migrating to GitHub Issues in its current form. Several
of us (not me) have already evaluated it as a possible Trac replacement
and concluded that it is insufficient for our needs.

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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 7:40 pm, Lawrence Velázquez  wrote:
> 
>> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>> 
>> Currently, once they find out about svn, and trac
> 
> We will still use Trac for issue tracking, although I believe someone is
> looking into integrating GitHub sign in.

Personally I think we have to migrate away from trac as well. Pull requests in 
GitHub will largely replace what happens in trac for submission of patches and 
the discussion of them. If we stick with trac for issues then for me it will be 
an utter mess.

Chris


> 
> vq

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

Re: Issues with oudated ports / GitHub

[Christopher Jones]

> On 7 Oct 2016, at 7:38 pm, Daniel J. Luke  wrote:
> 
> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>>> moving to GitHub doesn't magically make more interested parties make 
>>> quality contributions.
>> 
>> I agree that moving to github is not going to suddenly make people where not 
>> not previously looking for a packaging system for OSX suddenly start using 
>> macports. However, I completely agree with Marcel that moving to github will 
>> mean if someone does find their way to macports they will be more likely to 
>> stay and contribute, as the chances are they will already be familiar with 
>> git, as thats what the cool kids do these days. Currently, once they find 
>> out about svn, and trac, and yes i agree the little tired looking web pages, 
>> i suspect they are more likely to drift away. So the move to git will help.
> 
> the cool kids also aren't writing 'tcl' these days …

Indeed, but changing that is well beyond the scope of the current discussion. 
It shouldn’t ave a bearing on the migration to git.

> 
> -- 
> Daniel J. Luke
> 
> 
> 

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

Re: Issues with oudated ports / GitHub

[Brandon Allbery]

On Fri, Oct 7, 2016 at 2:38 PM, Daniel J. Luke  wrote:

> the cool kids also aren't writing 'tcl' these days ...


...but the way they write anything else, they might as well be writing
fortran...

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
> 
> Currently, once they find out about svn, and trac

We will still use Trac for issue tracking, although I believe someone is
looking into integrating GitHub sign in.

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

Re: Issues with oudated ports / GitHub

[Daniel J. Luke]

On Oct 7, 2016, at 2:09 PM, Chris Jones  wrote:
>> moving to GitHub doesn't magically make more interested parties make quality 
>> contributions.
> 
> I agree that moving to github is not going to suddenly make people where not 
> not previously looking for a packaging system for OSX suddenly start using 
> macports. However, I completely agree with Marcel that moving to github will 
> mean if someone does find their way to macports they will be more likely to 
> stay and contribute, as the chances are they will already be familiar with 
> git, as thats what the cool kids do these days. Currently, once they find out 
> about svn, and trac, and yes i agree the little tired looking web pages, i 
> suspect they are more likely to drift away. So the move to git will help.

the cool kids also aren't writing 'tcl' these days ...

-- 
Daniel J. Luke



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

Re: Issues with oudated ports / GitHub

[Chris Jones]

> On 7 Oct 2016, at 6:08 pm, Daniel J. Luke  wrote:
> 
> On Oct 7, 2016, at 11:59 AM, Marcel Bischoff  wrote:
 It pains me to say that Homebrew is running circles around MacPorts in
 the department of current available packages.
>>> 
>>> [citation needed] ;-)
>> 
>> Gladly. I have written a small script to check that. Here are a few of
>> the results (of some tools I work with/run on a daily basis):
>> 
>> ghc
>> MacPorts version: 7.8.3_4
>> Homebrew version: 8.0.1
> 
> https://trac.macports.org/ticket/48899
> 
> I don't see a patch attached there, but I imagine one could look at the 
> homebrew recipe and pull out what is necessary?
> 
>> fontforge
>> MacPorts version: 20120731_3
>> Homebrew version: 20161001
>> pandoc
>> MacPorts version: 1.12.4.2_1
>> Homebrew version: 1.17.2
> 
> both of these are nomaintainer - we'd be happy to have you maintain the ports 
> if you're interested in keeping them updated
> 
>> mutt
>> MacPorts version: 1.6.0_1
>> Homebrew version: 1.7.0
> 
> % port info mutt
> mutt @1.6.0_1 (mail)
> Replaced by:  neomutt
> 
> Description:  This port has been replaced by neomutt.
> Homepage: https://www.macports.org/
> 
> Platforms:darwin
> License:  unknown
> Maintainers:  nomaintai...@macports.org
> 
> (neomutt is @20161002)
> 
>> boost
>> MacPorts version: 1.59.0_2
>> Homebrew version: 1.62.0
>> 
>> fdupes
>> MacPorts version: 1.51
>> Homebrew version: 1.6.1
>> 
>> imapsync
>> MacPorts version: 1.684
>> Homebrew version: 1.727
>> 
>> notmuch
>> MacPorts version: 0.22.2
>> Homebrew version: 0.23
>> 
>> sqlmap
>> MacPorts version: 0.9_1
>> Homebrew version: 1.0.10
> 
> (I'm too lazy to look up why all of these might not be up to the current 
> version - hopefully you've opened tickets [with patches wherever possible] on 
> any of these you care about).
> 
 If time and manpower is the problem, wouldn't it be better to move to a
 GitHub-based approach like Homebrew does?
>>> 
>>> That doesn't necessarily fix the problem. It's worth noting that there 
>>> already is a plan to transition to github.
>> 
>> Why is that?
> 
> moving to GitHub doesn't magically make more interested parties make quality 
> contributions.

I agree that moving to github is not going to suddenly make people where not 
not previously looking for a packaging system for OSX suddenly start using 
macports. However, I completely agree with Marcel that moving to github will 
mean if someone does find their way to macports they will be more likely to 
stay and contribute, as the chances are they will already be familiar with git, 
as thats what the cool kids do these days. Currently, once they find out about 
svn, and trac, and yes i agree the little tired looking web pages, i suspect 
they are more likely to drift away. So the move to git will help.

Chris

> 
>> Also: what do you think the problem actually is and how to
>> rectify it? I'd be very interested to hear that.
> 
> I'm not convinced there's a general problem (other than the continual need to 
> try to get more people involved in the project).
> 
 This way far more people would
 contribute.
>>> 
>>> hopefully that's true, but there's no evidence to support that assertion at 
>>> this time.
>> 
>> Comparing the contribution rate of Homebrew to that of MacPorts, it
>> certainly wouldn't hurt things.
> 
> I'm not aware of anyone who has actual numbers on this (keeping in mind that 
> the respective user communities are different sizes).
> 
>> On the contrary. Plus, you are just
>> stating the obvious: something has not been done in an exact way,
>> therefore there is no evidence that this exact way yields this exact
>> result. Duh.
> 
> I'll be very pleased if you're right and that moving to GitHub will bring in 
> a large volume of (new) high-quality submissions.
> -- 
> Daniel J. Luke
> 
> 
> 
> ___
> 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: Issues with oudated ports / GitHub

[Lawrence Velázquez]

> On Oct 7, 2016, at 1:23 PM, Marcel Bischoff  wrote:
> 
> On 16/10/07, Guido Soranzio wrote:
> [...]
>> I really hope that the migration of MacPorts to GitHub will trigger a
>> collaboration between the two communities at last.

How would our switching to GitHub facilitate this at all? We still will
not be able to share code in any meaningful way (other than patches,
which we already do sometimes). Just because I will be spending more
time on github.com doesn't mean that I'm going to start wandering over
to github.com/homebrew.

> That would be swell, indeed. Although I can't shake the feeling that it
> could be a clash of cultures. Kind of like old school coders vs.
> hipsters. ;)

My eyes bleed every time I look at a Homebrew formula. True story.

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

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 12:07 PM, Marcel Bischoff  wrote:
> 
> On 16/10/07, Ryan Schmidt wrote:
>>> While the latter examples are just minor differences, especially
>>> things
>>> like ghc, fontforge an pandoc are either completely broken and/or
>>> severely outdated. I'm not trying to badmouth anyone or anything, just
>>> pointing to the higher (successful) update rate in Homebrew.
>>> 
> If time and manpower is the problem, wouldn't it be better to move to a
> GitHub-based approach like Homebrew does?
 
 That doesn't necessarily fix the problem. It's worth noting that there 
 already is a plan to transition to github.
>>> 
>>> Why is that? Also: what do you think the problem actually is and how to
>>> rectify it? I'd be very interested to hear that.
>> 
>> The problem is: somebody needs to do the correct work to update each of
>> those ports to the latest version. In many cases, tickets are already
>> filed, and you can look them up to see what the current status is; if
>> you don't find a ticket, please file a new one. In some cases, such as
>> boost, pandoc, ghc, there are serious issues preventing the update. If
>> Homebrew has solved those problems, great, maybe we can crib from them.
> 
> Again, I was under the impression that to be a port maintainer you would
> actually need to maintain the port. In this case, checking out what
> Homebrew is doing and trying to implement it the MacPort way. As this
> does not appear to be the case, I guess when things are broken, they are
> just considered being broken.
> 
> I don't see any concrete discussion as to why certain ports would not
> build, nor any kind of coordination between different port maintainers.
> This may very well be my fault due to selective perception on my part.
> I'm just a bit confised as to why one project can figure it out while
> another lags months or years behind in certain areas.
> 
> I'll be sure to devote some time to help solve long-standing issues. The
> proper mailing list to discuss those issues is this one I presume?

To take boost as an example, I've explained in the ticket why I haven't updated 
it: it's a lot of work:

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

You have to test that each port that depends on boost still builds, and we've 
already discovered some that don't. boost is notorious for not caring about 
backward compatibility. For each project that failed to build, we would have to 
figure out why and how to fix it.

I'm one of the maintainers of boost but I don't have the time to do all that 
testing and fixing right now, and haven't all year, because I have been busy 
trying to plan and coordinate moving MacPorts and other macOS forge projects 
over to GitHub. The other maintainer has evidently not had time either. The 
port is marked openmaintainer, so any other developer is welcome to do the 
work; nobody has yet done so.

So therefore, the port remains at an older version, which, to my knowledge, 
works fine. This is better than simply upgrading the port to a newer version 
and breaking other ports.


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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Guido Soranzio wrote:
[...]

I really hope that the migration of MacPorts to GitHub will trigger a
collaboration between the two communities at last.


That would be swell, indeed. Although I can't shake the feeling that it
could be a clash of cultures. Kind of like old school coders vs.
hipsters. ;)
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Daniel J. Luke]

On Oct 7, 2016, at 1:18 PM, Marcel Bischoff  wrote:
> Thank you, this is a good illustration of what I mean when I write
> MacPorts feels "stale", "dry" and "dated" when actually it is none of
> those things. Having tickets open for 11 years does not inspire
> confidence for prospective collaborators.

Look - something concrete we can act on!

I propose:

- A new wiki page where we collect requests for new ports
- closing all of the new port request tickets

Leave trac tickets for bugs/updates/things we expect to be acted on in a 
reasonable timeframe.

-- 
Daniel J. Luke



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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Ken Cunningham wrote:

And there are "requests for ports" ( I think this means new requests
for ports that don’t presently exist, mostly) that go back 11 years.
Port submissions that go back the same length of time. Possibly some
kind of massive clean-out of the old, dead, never-will-be-touched stuff
might need to happen.


Thank you, this is a good illustration of what I mean when I write
MacPorts feels "stale", "dry" and "dated" when actually it is none of
those things. Having tickets open for 11 years does not inspire
confidence for prospective collaborators.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 12:05 PM, Rainer Müller  wrote:
> 
> We are currently using the type field with "defect", "enhancement",
> "update", "submission", "request". A ticket should be filed with the
> appropriate type.
> 
> To indicate a patch is attached to the ticket, we add the "haspatch"
> keyword. Additionally the "maintainer" keyword can be added to express
> the update needs no thorough review as it comes directly from the
> maintainer.
> 
> https://trac.macports.org/wiki/Tickets#Keywords
> 
> I am not sure how we could change these to make triaging trickets easier.

I've been unhappy with the fact that the "update" ticket type represents both 
submissions of updates and requests for updates, whereas submissions of new 
ports and requests for new ports each get their own ticket type. There should 
either be 2 ticket types (one for new ports, one for existing ports), or 4 
ticket types (new port submission, new port request, existing port update 
submission, existing port update request). The names should also be more 
obvious. We constantly get "request" tickets filed which are not new port 
requests but something else.

I'm also not happy with our ticket resolutions. "invalid" sounds rude; "not a 
bug" might be nicer. We also should have "not our bug" for things which are 
bugs but not MacPorts bugs (things like Xcode bugs, macOS bugs).

We also need some way to classify tickets which are not supposed to be in the 
issue tracker, like user-specific problems, tech support, etc.

Maybe we need to take a fresh look at how some other projects classify their 
issues.


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

Re: Issues with oudated ports / GitHub

[Daniel J. Luke]

On Oct 7, 2016, at 11:59 AM, Marcel Bischoff  wrote:
>>> It pains me to say that Homebrew is running circles around MacPorts in
>>> the department of current available packages.
>> 
>> [citation needed] ;-)
> 
> Gladly. I have written a small script to check that. Here are a few of
> the results (of some tools I work with/run on a daily basis):
> 
> ghc
> MacPorts version: 7.8.3_4
> Homebrew version: 8.0.1

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

I don't see a patch attached there, but I imagine one could look at the 
homebrew recipe and pull out what is necessary?

> fontforge
> MacPorts version: 20120731_3
> Homebrew version: 20161001
> pandoc
> MacPorts version: 1.12.4.2_1
> Homebrew version: 1.17.2

both of these are nomaintainer - we'd be happy to have you maintain the ports 
if you're interested in keeping them updated

> mutt
> MacPorts version: 1.6.0_1
> Homebrew version: 1.7.0

% port info mutt
mutt @1.6.0_1 (mail)
Replaced by:  neomutt

Description:  This port has been replaced by neomutt.
Homepage: https://www.macports.org/

Platforms:darwin
License:  unknown
Maintainers:  nomaintai...@macports.org

(neomutt is @20161002)

> boost
> MacPorts version: 1.59.0_2
> Homebrew version: 1.62.0
> 
> fdupes
> MacPorts version: 1.51
> Homebrew version: 1.6.1
> 
> imapsync
> MacPorts version: 1.684
> Homebrew version: 1.727
> 
> notmuch
> MacPorts version: 0.22.2
> Homebrew version: 0.23
> 
> sqlmap
> MacPorts version: 0.9_1
> Homebrew version: 1.0.10

(I'm too lazy to look up why all of these might not be up to the current 
version - hopefully you've opened tickets [with patches wherever possible] on 
any of these you care about).

>>> If time and manpower is the problem, wouldn't it be better to move to a
>>> GitHub-based approach like Homebrew does?
>> 
>> That doesn't necessarily fix the problem. It's worth noting that there 
>> already is a plan to transition to github.
> 
> Why is that?

moving to GitHub doesn't magically make more interested parties make quality 
contributions.

> Also: what do you think the problem actually is and how to
> rectify it? I'd be very interested to hear that.

I'm not convinced there's a general problem (other than the continual need to 
try to get more people involved in the project).

>>> This way far more people would
>>> contribute.
>> 
>> hopefully that's true, but there's no evidence to support that assertion at 
>> this time.
> 
> Comparing the contribution rate of Homebrew to that of MacPorts, it
> certainly wouldn't hurt things.

I'm not aware of anyone who has actual numbers on this (keeping in mind that 
the respective user communities are different sizes).

> On the contrary. Plus, you are just
> stating the obvious: something has not been done in an exact way,
> therefore there is no evidence that this exact way yields this exact
> result. Duh.

I'll be very pleased if you're right and that moving to GitHub will bring in a 
large volume of (new) high-quality submissions.
-- 
Daniel J. Luke



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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Ryan Schmidt wrote:

While the latter examples are just minor differences, especially
things
like ghc, fontforge an pandoc are either completely broken and/or
severely outdated. I'm not trying to badmouth anyone or anything, just
pointing to the higher (successful) update rate in Homebrew.


If time and manpower is the problem, wouldn't it be better to move to a
GitHub-based approach like Homebrew does?


That doesn't necessarily fix the problem. It's worth noting that there already 
is a plan to transition to github.


Why is that? Also: what do you think the problem actually is and how to
rectify it? I'd be very interested to hear that.


The problem is: somebody needs to do the correct work to update each of
those ports to the latest version. In many cases, tickets are already
filed, and you can look them up to see what the current status is; if
you don't find a ticket, please file a new one. In some cases, such as
boost, pandoc, ghc, there are serious issues preventing the update. If
Homebrew has solved those problems, great, maybe we can crib from them.


Again, I was under the impression that to be a port maintainer you would
actually need to maintain the port. In this case, checking out what
Homebrew is doing and trying to implement it the MacPort way. As this
does not appear to be the case, I guess when things are broken, they are
just considered being broken.

I don't see any concrete discussion as to why certain ports would not
build, nor any kind of coordination between different port maintainers.
This may very well be my fault due to selective perception on my part.
I'm just a bit confised as to why one project can figure it out while
another lags months or years behind in certain areas.

I'll be sure to devote some time to help solve long-standing issues. The
proper mailing list to discuss those issues is this one I presume?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Guido Soranzio]

>> On Oct 7, 2016, at 10:59 AM, Marcel Bischoff  wrote:
>> 
 It pains me to say that Homebrew is running circles around MacPorts in
 the department of current available packages.
>>> 
>>> [citation needed] ;-)
>> 
>> Gladly. I have written a small script to check that. Here are a few of
>> the results (of some tools I work with/run on a daily basis)


I have written a whole GUI which uses AppleScript to automate the Terminal
in order to hide automatically the /usr/local and /opt/local
prefixes when un/installing/upgrading multiple packages, so you
can compare at once the different versions that MacPorts and Homebrew
provide: .

I have converted Guigna to Swift 3 and it should compile flawlessly with
the latest versions of Xcode 8 and Sierra.

I really hope that the migration of MacPorts to GitHub will trigger a
collaboration between the two communities at last. 


Guido

-- 
https://github.com/gui-dos/

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

Re: Issues with oudated ports / GitHub

[Rainer Müller]

On 2016-10-07 18:25, Ken Cunningham wrote:
> The current "port update" ticket queue I find to be a rather
> unpredictable mixture of requests of port updates, requests for new
> ports, announcements that somebody has noticed a version update has
> come available, and finished port updates awaiting approval by
> committers. I don’t mind picking off a few of these and updating
> them, or building some new ones, but it’s a bit of a tangle
> sometimes.
> 
> Like this ticket: https://trac.macports.org/ticket/52538
> 
> I think this ticket represents someone noticing there’s a new version
> available, and requesting the existing port be updated. But that
> should be in a different lineup, IMHO.

We are currently using the type field with "defect", "enhancement",
"update", "submission", "request". A ticket should be filed with the
appropriate type.

To indicate a patch is attached to the ticket, we add the "haspatch"
keyword. Additionally the "maintainer" keyword can be added to express
the update needs no thorough review as it comes directly from the
maintainer.

https://trac.macports.org/wiki/Tickets#Keywords

I am not sure how we could change these to make triaging trickets easier.

> And there are "requests for ports" ( I think this means new requests
> for ports that don’t presently exist, mostly) that go back 11 years.
> Port submissions that go back the same length of time. Possibly some
> kind of massive clean-out of the old, dead, never-will-be-touched
> stuff might need to happen.

Requests for new ports could still be valid after years. This list could
be helpful for newcomers that want to create new ports. The number of
people in CC in such a ticket could also be an indicator of its importance.

A few years back, I began adding a keyword "lack-of-interest" to tickets
that where open for a long time without response on questions. When the
reporter does no longer seem to want it or there is nobody else who
steps up to do it, just closed these tickets.

Maybe there would be a better approach that can become a real policy to
avoid so much old cruft in the tickets.

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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Ryan Schmidt wrote:

After all, MacPorts maintainers are just some people devoting their
free
time to writing Portfiles. Sometimes other stuff in life stops them from
responding to tickets or addressing certain issues.


This is a given. Open source projects are mostly staffed by unpaid
volunteers. I don't feel entitled to recieve updates, as it's all free.
However, a well-run project does inspire constant commitment to keep it
running smoothly. MacPorts does not *feel* like being very active, quite
inaccessible to new users and there does not appear to be current
information easily accessible. A good example for this would be the move
to GitHub. Some status messages outside of the mailing list or even a
dedicated FAQ would go a long way. Without this mailing list, an
outsider easily gets the impression MacPorts is outdated and running on
fumes.


What gives the impression that we aren't active?

There are tons of posts on the mailing lists every week.

There are tons of commits to the repository each day.

There are tons of tickets filed each week.


Before I was subscribed to this mailing list (something I haven't used
for ages), there was no easy way to see anything going on. Before I
installed MacPorts a couple of months ago, I was seriously surprised to
see an installer for El Capitan at all. I could have sworn MacPorts was
outdated and development had stalled. It took days of patient perusing
the documentation until it clicked and I got why MacPort is the way it
is.

I believe the impression of staleness mainly comes down to:

- The very old school website structure (not at all intuitive, lots of
 clicking around and text searching necessary). I don't mean flashy
 design, I mean readable, easy to understand instructions that are
 grouped and interlinked smoothly.
- The current Trac being kind of unwieldy
- Me being used to working with Git and GitHub/BitBucket/GitLab
- The manual diffing process

In essence, practically everything about MacPorts feels "old" and
utilitarian, leaving a taste of staleness.

I believe it may be difficult for a project "insider" to view things
from the perspective of an "outsider". Younger developers (which does
not include me), especially not those working on kernel code or
industrial automation systems, are used to issue tickets like GitHub,
not older Trac versions. To web-based discussion or Slack channels, not
mailing lists. To Git, not SVN. They use GUI editors, not Vim. They code
in Node.js, not C.

The point being: MacPorts feels dated, a bit exclusive and very "dry"
when in reality it is none of those things. Attracting new contributors
has a lot to do with how a project comes across.


I can understand your frustration about broken ports and missing
updates. I have that as well.

If your work depends on these ports, you benefit from the donation of
time from the people keeping the port up-to-date. The best you can do if
you encounter a problem is to check if it is a known issue in our Trac.
Sometimes others already proposed a solution but did not have the time
to get through with updating the Portfile in multiple iterations testing
the change. Yes, this is a time-consuming process, but others would
benefit from your work as well as you benefit form theirs.


Absolutely. The process itself of posting a diff just feels archaic and
like an uphill battle.


And we will switch to GitHub, and use pull requests. But sending a pull 
request, or attaching a diff to a ticket, is not the hard part.


True, but it will make the "business part" of submitting the patch more
straight-forward.


Even as a non-committer you can easily work from a Subversion
checkout
with local modifications and create the patch from there. Or you keep a
separate local ports tree that you diff against.


I actually keep a local ports tree with modifications for a couple of
ports that are not updated in a timely manner. Given a smoother
workflow, I'm very interested in updating those for the benefit of all
users. My experience so far is that things move very slow if at all.


If a ticket does not move in 72 hours, write a note to this mailing list 
requesting someone look at it.


I'll be sure to remember that.


But in either case, the hard part is "make the edits, test them"; that
doesn't change when we move to GitHub. We current receive many
low-quality submissions that require further editing. I don't
anticipate the quality of submissions will magically improve just by
moving to GitHub.


By itself it will probably not. But the submission process will be
easier for contributors and the pointing out of problems will be
clearer.


Something we could do to improve the quality of submissions would be to improve 
the quality of our portfile-writing documentation. Someday I would like to 
rewrite all of our documentation in a new cohesive format, but that is a big 
effort.


If you need help with that, let me know.


If changes are needed, they can be coordinated on a line-by-line

Re: Issues with oudated ports / GitHub

[Ken Cunningham]

> 
> The problem is: somebody needs to do the correct work to update each of those 
> ports to the latest version. In many cases, tickets are already filed, and 
> you can look them up to see what the current status is; if you don't find a 
> ticket, please file a new one.

Couple of points here.

The current "port update" ticket queue I find to be a rather unpredictable 
mixture of requests of port updates, requests for new ports, announcements that 
somebody has noticed a version update has come available, and finished port 
updates awaiting approval by committers. I don’t mind picking off a few of 
these and updating them, or building some new ones, but it’s a bit of a tangle 
sometimes.

Like this ticket:
https://trac.macports.org/ticket/52538

I think this ticket represents someone noticing there’s a new version 
available, and requesting the existing port be updated. But that should be in a 
different lineup, IMHO.

And there are "requests for ports" ( I think this means new requests for ports 
that don’t presently exist, mostly) that go back 11 years. Port submissions 
that go back the same length of time. Possibly some kind of massive clean-out 
of the old, dead, never-will-be-touched stuff might need to happen.

Might be more streamlined and efficient if that all could be aligned better.

$0.02.

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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/07, Ryan Schmidt wrote:

It looks like others have already responded to most of your points, but I would 
just add:

On Oct 6, 2016, at 12:12 PM, Marcel Bischoff wrote:


But if I still
cannot install (for example) pandoc because ghc still requires llwm-3.5
which does not compile on Sierra: what choice do I have? I need to get
stuff done, not tinker with the infrastructure of my working environment
for hours on end, just to get it to work.


If you just "need to get stuff done, not tinker", then you should not upgrade 
to a new OS immediately after it is released; wait a month or two. It is inevitable that 
a new OS release will break some ports, and it will take time for the maintainers of 
those ports to notice those problems and figure out the solutions, possibly needing to 
work with the developers of the software to release a new version.


This is stating the obvious. One of my main points was that Homebrew
*does* work and oftentimes has more current packages while MacPorts
*does not*, trying to understand why that is.


Regarding updating pandoc, see https://trac.macports.org/ticket/48324

Regarding updating ghc, see https://trac.macports.org/ticket/48899

Regarding old llvm on Sierra, see https://trac.macports.org/ticket/52424


I have seen all those tickets before. It's basically telling me that
those ports are broken.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 10:59 AM, Marcel Bischoff  wrote:
> 
>>> It pains me to say that Homebrew is running circles around MacPorts in
>>> the department of current available packages.
>> 
>> [citation needed] ;-)
> 
> Gladly. I have written a small script to check that. Here are a few of
> the results (of some tools I work with/run on a daily basis):
> 
> ghc
> MacPorts version: 7.8.3_4
> Homebrew version: 8.0.1
> 
> fontforge
> MacPorts version: 20120731_3
> Homebrew version: 20161001
> 
> pandoc
> MacPorts version: 1.12.4.2_1
> Homebrew version: 1.17.2
> 
> boost
> MacPorts version: 1.59.0_2
> Homebrew version: 1.62.0
> 
> fdupes
> MacPorts version: 1.51
> Homebrew version: 1.6.1
> 
> imapsync
> MacPorts version: 1.684
> Homebrew version: 1.727
> 
> mutt
> MacPorts version: 1.6.0_1
> Homebrew version: 1.7.0
> 
> notmuch
> MacPorts version: 0.22.2
> Homebrew version: 0.23
> 
> sqlmap
> MacPorts version: 0.9_1
> Homebrew version: 1.0.10
> 
> While the latter examples are just minor differences, especially things
> like ghc, fontforge an pandoc are either completely broken and/or
> severely outdated. I'm not trying to badmouth anyone or anything, just
> pointing to the higher (successful) update rate in Homebrew.
> 
>>> If time and manpower is the problem, wouldn't it be better to move to a
>>> GitHub-based approach like Homebrew does?
>> 
>> That doesn't necessarily fix the problem. It's worth noting that there 
>> already is a plan to transition to github.
> 
> Why is that? Also: what do you think the problem actually is and how to
> rectify it? I'd be very interested to hear that.

The problem is: somebody needs to do the correct work to update each of those 
ports to the latest version. In many cases, tickets are already filed, and you 
can look them up to see what the current status is; if you don't find a ticket, 
please file a new one. In some cases, such as boost, pandoc, ghc, there are 
serious issues preventing the update. If Homebrew has solved those problems, 
great, maybe we can crib from them.


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

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

> On Oct 7, 2016, at 10:23 AM, Marcel Bischoff  wrote:
> 

>>> Just today I commented on a ticket that is six weeks old, about an
>>> update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
>>> 4.6.0 on 27-Sep-2016. Version 4 is considered the stable LTS variant,
>>> only fixing security issues without introducing new features. This makes
>>> timely updates all the more important. If installing software by hand
>>> results in more current and more secure software for my development
>>> machine, I don't get the point of using MacPorts in the first place.
>> 
>> Our ports do have maintainers, which are people who expressed interest
>> in a port and are interested in keeping them up-to-date. This is meant
>> to assign issues with ports to certain people that care about this port
>> and would have the most knowledge how to fix it.
>> 
>> However, we also have a maintainer timeout policy [1] by which updates
>> to ports can be committed by any project member after 72 hours of
>> submission if the maintainer does not show any reaction. In case a port
>> is in a broken state (does not compile at all, typo, etc.) or
>> vulnerabilities require a security patch, any project member can
>> immediately commit an update.
>> 
>> In this particular case [2], a ticket was filed with an update request,
>> but no patch was attached. With a patch, it would be much easier to
>> verify that the build still works and then commit the update.
>> 
>> The backlog of patches already approved by the maintainer is not that
>> long [3] right now. Those still in the queue often already went through
>> review, but issues with the update were found that need to be addressed.
>> 
>> If you think a contribution has stalled, ping the macports-dev list
>> about it and request a review. This has proved to work quite well in
>> recent time.
> 
> I see. My understanding was that a port maintainer would also be
> responsible for updating the port in a timely manner, regardless of an
> already available patch. So this is not required to be a maintainer?

That would be nice. However, we can't force volunteers to do anything. If a 
volunteer appears over time to be unresponsive to requests, we can remove that 
volunteer.


>>> It pains me to say that Homebrew is running circles around MacPorts in
>>> the department of current available packages.
>>> 
>>> If time and manpower is the problem, wouldn't it be better to move to a
>>> GitHub-based approach like Homebrew does? This way far more people would
>>> contribute. It would lower the bar to contributing significantly. I like
>>> MacPorts' clean implementation far more than Homebrews'. But if I still
>>> cannot install (for example) pandoc because ghc still requires llwm-3.5
>>> which does not compile on Sierra: what choice do I have? I need to get
>>> stuff done, not tinker with the infrastructure of my working environment
>>> for hours on end, just to get it to work. A package manager's sole
>>> reason for being is to make the routine task of installing software and
>>> updates easier, more reliable and trustworthy.
>> 
>> After all, MacPorts maintainers are just some people devoting their free
>> time to writing Portfiles. Sometimes other stuff in life stops them from
>> responding to tickets or addressing certain issues.
> 
> This is a given. Open source projects are mostly staffed by unpaid
> volunteers. I don't feel entitled to recieve updates, as it's all free.
> However, a well-run project does inspire constant commitment to keep it
> running smoothly. MacPorts does not *feel* like being very active, quite
> inaccessible to new users and there does not appear to be current
> information easily accessible. A good example for this would be the move
> to GitHub. Some status messages outside of the mailing list or even a
> dedicated FAQ would go a long way. Without this mailing list, an
> outsider easily gets the impression MacPorts is outdated and running on
> fumes.

What gives the impression that we aren't active?

There are tons of posts on the mailing lists every week.

There are tons of commits to the repository each day.

There are tons of tickets filed each week.


>> I can understand your frustration about broken ports and missing
>> updates. I have that as well.
>> 
>> If your work depends on these ports, you benefit from the donation of
>> time from the people keeping the port up-to-date. The best you can do if
>> you encounter a problem is to check if it is a known issue in our Trac.
>> Sometimes others already proposed a solution but did not have the time
>> to get through with updating the Portfile in multiple iterations testing
>> the change. Yes, this is a time-consuming process, but others would
>> benefit from your work as well as you benefit form theirs.
> 
> Absolutely. The process itself of posting a diff just feels archaic and
> like an uphill battle.

And we will switch to GitHub, and use pull requests. But sending a pull 
request, 

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/06, Daniel J. Luke wrote:
[...]

If installing software by hand
results in more current and more secure software for my development
machine, I don't get the point of using MacPorts in the first place.


MacPorts provides a way to save the 'recipe' for installing software (and a 
handy way to uninstall/upgrade software). If it doesn't provide value for you, 
you probably shouldn't use it (and/or if you have ideas for making it more 
useful, we're always happy to have more contributors).


Exactly my point. I'd like to help out but at the same time voice my
dissatisfaction with certain conditions instead of quietly dropping it
and moving on. I love MacPorts and I care about it, that's why I bothered
to sign up for the mailing list and post this message in the first place.
Rainer did get it perfectly right in his response. [1]


It pains me to say that Homebrew is running circles around MacPorts in
the department of current available packages.


[citation needed] ;-)


Gladly. I have written a small script to check that. Here are a few of
the results (of some tools I work with/run on a daily basis):

ghc
MacPorts version: 7.8.3_4
Homebrew version: 8.0.1

fontforge
MacPorts version: 20120731_3
Homebrew version: 20161001

pandoc
MacPorts version: 1.12.4.2_1
Homebrew version: 1.17.2

boost
MacPorts version: 1.59.0_2
Homebrew version: 1.62.0

fdupes
MacPorts version: 1.51
Homebrew version: 1.6.1

imapsync
MacPorts version: 1.684
Homebrew version: 1.727

mutt
MacPorts version: 1.6.0_1
Homebrew version: 1.7.0

notmuch
MacPorts version: 0.22.2
Homebrew version: 0.23

sqlmap
MacPorts version: 0.9_1
Homebrew version: 1.0.10

While the latter examples are just minor differences, especially things
like ghc, fontforge an pandoc are either completely broken and/or
severely outdated. I'm not trying to badmouth anyone or anything, just
pointing to the higher (successful) update rate in Homebrew.


If time and manpower is the problem, wouldn't it be better to move to a
GitHub-based approach like Homebrew does?


That doesn't necessarily fix the problem. It's worth noting that there already 
is a plan to transition to github.


Why is that? Also: what do you think the problem actually is and how to
rectify it? I'd be very interested to hear that.


This way far more people would
contribute.


hopefully that's true, but there's no evidence to support that assertion at 
this time.


Comparing the contribution rate of Homebrew to that of MacPorts, it
certainly wouldn't hurt things. On the contrary. Plus, you are just
stating the obvious: something has not been done in an exact way,
therefore there is no evidence that this exact way yields this exact
result. Duh.

[...]

[1]:
https://lists.macosforge.org/pipermail/macports-dev/2016-October/033941.html
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

On 16/10/06, Rainer Müller wrote:

Hello Marcel,

On 2016-10-06 19:12, Marcel Bischoff wrote:

I was advised that I should ask my questions and raise my issues here.

I'm currently considering dropping the use of MacPorts altogether as
this projects' track record regarding critical updates of major software
tools is rather underwhelming. Furthermore, I'm asking myself what use
it is to have appointed port maintainers when numerous updates are not
included in a timely manner.


Thank you for coming here to discuss your issues instead of merely
turning your back on the project and leaving silently.


Thank you for taking the time to respond. I would really like to help
with the project if I can do something worthwhile and useful.


Just today I commented on a ticket that is six weeks old, about an
update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
4.6.0 on 27-Sep-2016. Version 4 is considered the stable LTS variant,
only fixing security issues without introducing new features. This makes
timely updates all the more important. If installing software by hand
results in more current and more secure software for my development
machine, I don't get the point of using MacPorts in the first place.


Our ports do have maintainers, which are people who expressed interest
in a port and are interested in keeping them up-to-date. This is meant
to assign issues with ports to certain people that care about this port
and would have the most knowledge how to fix it.

However, we also have a maintainer timeout policy [1] by which updates
to ports can be committed by any project member after 72 hours of
submission if the maintainer does not show any reaction. In case a port
is in a broken state (does not compile at all, typo, etc.) or
vulnerabilities require a security patch, any project member can
immediately commit an update.

In this particular case [2], a ticket was filed with an update request,
but no patch was attached. With a patch, it would be much easier to
verify that the build still works and then commit the update.

The backlog of patches already approved by the maintainer is not that
long [3] right now. Those still in the queue often already went through
review, but issues with the update were found that need to be addressed.

If you think a contribution has stalled, ping the macports-dev list
about it and request a review. This has proved to work quite well in
recent time.


I see. My understanding was that a port maintainer would also be
responsible for updating the port in a timely manner, regardless of an
already available patch. So this is not required to be a maintainer?


It pains me to say that Homebrew is running circles around MacPorts in
the department of current available packages.

If time and manpower is the problem, wouldn't it be better to move to a
GitHub-based approach like Homebrew does? This way far more people would
contribute. It would lower the bar to contributing significantly. I like
MacPorts' clean implementation far more than Homebrews'. But if I still
cannot install (for example) pandoc because ghc still requires llwm-3.5
which does not compile on Sierra: what choice do I have? I need to get
stuff done, not tinker with the infrastructure of my working environment
for hours on end, just to get it to work. A package manager's sole
reason for being is to make the routine task of installing software and
updates easier, more reliable and trustworthy.


After all, MacPorts maintainers are just some people devoting their free
time to writing Portfiles. Sometimes other stuff in life stops them from
responding to tickets or addressing certain issues.


This is a given. Open source projects are mostly staffed by unpaid
volunteers. I don't feel entitled to recieve updates, as it's all free.
However, a well-run project does inspire constant commitment to keep it
running smoothly. MacPorts does not *feel* like being very active, quite
inaccessible to new users and there does not appear to be current
information easily accessible. A good example for this would be the move
to GitHub. Some status messages outside of the mailing list or even a
dedicated FAQ would go a long way. Without this mailing list, an
outsider easily gets the impression MacPorts is outdated and running on
fumes.


I can understand your frustration about broken ports and missing
updates. I have that as well.

If your work depends on these ports, you benefit from the donation of
time from the people keeping the port up-to-date. The best you can do if
you encounter a problem is to check if it is a known issue in our Trac.
Sometimes others already proposed a solution but did not have the time
to get through with updating the Portfile in multiple iterations testing
the change. Yes, this is a time-consuming process, but others would
benefit from your work as well as you benefit form theirs.


Absolutely. The process itself of posting a diff just feels archaic and
like an uphill battle.


Just switching to GitHub 

Re: Issues with oudated ports / GitHub

[Ryan Schmidt]

It looks like others have already responded to most of your points, but I would 
just add:

On Oct 6, 2016, at 12:12 PM, Marcel Bischoff wrote:

> But if I still
> cannot install (for example) pandoc because ghc still requires llwm-3.5
> which does not compile on Sierra: what choice do I have? I need to get
> stuff done, not tinker with the infrastructure of my working environment
> for hours on end, just to get it to work.

If you just "need to get stuff done, not tinker", then you should not upgrade 
to a new OS immediately after it is released; wait a month or two. It is 
inevitable that a new OS release will break some ports, and it will take time 
for the maintainers of those ports to notice those problems and figure out the 
solutions, possibly needing to work with the developers of the software to 
release a new version. 

Regarding updating pandoc, see https://trac.macports.org/ticket/48324

Regarding updating ghc, see https://trac.macports.org/ticket/48899

Regarding old llvm on Sierra, see https://trac.macports.org/ticket/52424

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

Re: Issues with oudated ports / GitHub

[Marcel Bischoff]

Hi Eric,

thanks for the pointer. Good to hear that things are already in motion
to make the switch. I'm looking over the messages exchanged in the last
couple of weeks.

Best,
Marcel

On 16/10/06, Eric A. Borisch wrote:

Marcel,

At least some of your concerns should be getting addressed with this:

https://lists.macosforge.org/pipermail/macports-dev/2016-August/033405.html
("Goodbye Mac OS Forge, hello GitHub")

Also, much of the discussion over the past two months on this list has been
on this transition; take a look at the archives and chime in!

Thanks,
 - Eric


On Thu, Oct 6, 2016 at 12:12 PM, Marcel Bischoff 
wrote:


Hi all,

I was advised that I should ask my questions and raise my issues here.

I'm currently considering dropping the use of MacPorts altogether as
this projects' track record regarding critical updates of major software
tools is rather underwhelming. Furthermore, I'm asking myself what use
it is to have appointed port maintainers when numerous updates are not
included in a timely manner.

Just today I commented on a ticket that is six weeks old, about an
update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
4.6.0 on 27-Sep-2016. Version 4 is considered the stable LTS variant,
only fixing security issues without introducing new features. This makes
timely updates all the more important. If installing software by hand
results in more current and more secure software for my development
machine, I don't get the point of using MacPorts in the first place.

It pains me to say that Homebrew is running circles around MacPorts in
the department of current available packages.

If time and manpower is the problem, wouldn't it be better to move to a
GitHub-based approach like Homebrew does? This way far more people would
contribute. It would lower the bar to contributing significantly. I like
MacPorts' clean implementation far more than Homebrews'. But if I still
cannot install (for example) pandoc because ghc still requires llwm-3.5
which does not compile on Sierra: what choice do I have? I need to get
stuff done, not tinker with the infrastructure of my working environment
for hours on end, just to get it to work. A package manager's sole
reason for being is to make the routine task of installing software and
updates easier, more reliable and trustworthy.

The way it is now, I repeatedly find myself in need to modify the
Portfiles manually, test, check, test again and so on. Or I simply run
`brew install pandoc` and — be done. Plus, doing all that manual diffing
where just a minor mistake will frustrate me and requires me to attach a
completely new diff file quite honestly keeps me from contributing
regularly. In 2016 this feels like pulling teeth, not satisfaction or a
sense of accomplishment that should accompany working together on free
software.

I'd really like to hear from several sides about the why's and how's
regarding MacPorts' current state and what the plan is for the
forseeable future. I was told that there is a current discussion
underway about a possible move to GitHub. I would throw whatever weight
I have behind that move. If you need another helping hand for clearly
defined work, let me know. I'll be more than happy to involve myself.

My best,
Marcel
___
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: Issues with oudated ports / GitHub

[Rainer Müller]

Hello Marcel,

On 2016-10-06 19:12, Marcel Bischoff wrote:
> I was advised that I should ask my questions and raise my issues here.
> 
> I'm currently considering dropping the use of MacPorts altogether as
> this projects' track record regarding critical updates of major software
> tools is rather underwhelming. Furthermore, I'm asking myself what use
> it is to have appointed port maintainers when numerous updates are not
> included in a timely manner.

Thank you for coming here to discuss your issues instead of merely
turning your back on the project and leaving silently.

> Just today I commented on a ticket that is six weeks old, about an
> update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
> 4.6.0 on 27-Sep-2016. Version 4 is considered the stable LTS variant,
> only fixing security issues without introducing new features. This makes
> timely updates all the more important. If installing software by hand
> results in more current and more secure software for my development
> machine, I don't get the point of using MacPorts in the first place.

Our ports do have maintainers, which are people who expressed interest
in a port and are interested in keeping them up-to-date. This is meant
to assign issues with ports to certain people that care about this port
and would have the most knowledge how to fix it.

However, we also have a maintainer timeout policy [1] by which updates
to ports can be committed by any project member after 72 hours of
submission if the maintainer does not show any reaction. In case a port
is in a broken state (does not compile at all, typo, etc.) or
vulnerabilities require a security patch, any project member can
immediately commit an update.

In this particular case [2], a ticket was filed with an update request,
but no patch was attached. With a patch, it would be much easier to
verify that the build still works and then commit the update.

The backlog of patches already approved by the maintainer is not that
long [3] right now. Those still in the queue often already went through
review, but issues with the update were found that need to be addressed.

If you think a contribution has stalled, ping the macports-dev list
about it and request a review. This has proved to work quite well in
recent time.

> It pains me to say that Homebrew is running circles around MacPorts in
> the department of current available packages.
> 
> If time and manpower is the problem, wouldn't it be better to move to a
> GitHub-based approach like Homebrew does? This way far more people would
> contribute. It would lower the bar to contributing significantly. I like
> MacPorts' clean implementation far more than Homebrews'. But if I still
> cannot install (for example) pandoc because ghc still requires llwm-3.5
> which does not compile on Sierra: what choice do I have? I need to get
> stuff done, not tinker with the infrastructure of my working environment
> for hours on end, just to get it to work. A package manager's sole
> reason for being is to make the routine task of installing software and
> updates easier, more reliable and trustworthy.

After all, MacPorts maintainers are just some people devoting their free
time to writing Portfiles. Sometimes other stuff in life stops them from
responding to tickets or addressing certain issues.

I can understand your frustration about broken ports and missing
updates. I have that as well.

If your work depends on these ports, you benefit from the donation of
time from the people keeping the port up-to-date. The best you can do if
you encounter a problem is to check if it is a known issue in our Trac.
Sometimes others already proposed a solution but did not have the time
to get through with updating the Portfile in multiple iterations testing
the change. Yes, this is a time-consuming process, but others would
benefit from your work as well as you benefit form theirs.

Just switching to GitHub would not change the way port updates are put
together. In my experience, preparing the patch and attaching it to a
ticket is only a small fraction of what needs to be done for a port
update. You will still need to update the Portfile, test the build, etc.

> The way it is now, I repeatedly find myself in need to modify the
> Portfiles manually, test, check, test again and so on. Or I simply run
> `brew install pandoc` and — be done. Plus, doing all that manual diffing
> where just a minor mistake will frustrate me and requires me to attach a
> completely new diff file quite honestly keeps me from contributing
> regularly. In 2016 this feels like pulling teeth, not satisfaction or a
> sense of accomplishment that should accompany working together on free
> software.

Even as a non-committer you can easily work from a Subversion checkout
with local modifications and create the patch from there. Or you keep a
separate local ports tree that you diff against.

Where exactly do you see the benefit of Git/GitHub for this? I am
honestly interested in this for 

Re: Issues with oudated ports / GitHub

[Daniel J. Luke]

On Oct 6, 2016, at 1:12 PM, Marcel Bischoff  wrote:
> I'm currently considering dropping the use of MacPorts altogether

ok.

> as
> this projects' track record regarding critical updates of major software
> tools is rather underwhelming. Furthermore, I'm asking myself what use
> it is to have appointed port maintainers when numerous updates are not
> included in a timely manner.

As updates depend on a port maintainer (and potentially also someone with 
commit access), you'll likely find that the speed of updates is different for 
different ports. What you consider 'major software tools' may also not be what 
anyone else considers 'major software tools'.

> Just today I commented on a ticket that is six weeks old, about an
> update to nodejs4. Version 4.5.0 was released on 16-Aug-2016, version
> 4.6.0 on 27-Sep-2016.

no link to ticket?

Looks like you mean 'https://trac.macports.org/ticket/52110'

It also looks like you believe nodejs4 qualifies for the 'Port Abandonment' 
procedure (which you linked to ~5 hours ago), but I did not see where you 
actually followed the procedure.

> If installing software by hand
> results in more current and more secure software for my development
> machine, I don't get the point of using MacPorts in the first place.

MacPorts provides a way to save the 'recipe' for installing software (and a 
handy way to uninstall/upgrade software). If it doesn't provide value for you, 
you probably shouldn't use it (and/or if you have ideas for making it more 
useful, we're always happy to have more contributors).

> It pains me to say that Homebrew is running circles around MacPorts in
> the department of current available packages.

[citation needed] ;-)

> If time and manpower is the problem, wouldn't it be better to move to a
> GitHub-based approach like Homebrew does?

That doesn't necessarily fix the problem. It's worth noting that there already 
is a plan to transition to github.

> This way far more people would
> contribute.

hopefully that's true, but there's no evidence to support that assertion at 
this time.

> It would lower the bar to contributing significantly. I like
> MacPorts' clean implementation far more than Homebrews'. But if I still
> cannot install (for example) pandoc because ghc still requires llwm-3.5
> which does not compile on Sierra: what choice do I have? I need to get
> stuff done, not tinker with the infrastructure of my working environment
> for hours on end, just to get it to work. A package manager's sole
> reason for being is to make the routine task of installing software and
> updates easier, more reliable and trustworthy.

if you have to tinker, and you contribute your tinkering, then other people 
won't have to tinker.

-- 
Daniel J. Luke



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