Contributing to MacPorts (specifically to introduce am improved concurrent qt5-mac)

René J.V. Bertin rjvbertin at gmail.com
Thu Jun 11 02:44:45 PDT 2015


On Thursday June 11 2015, Marko wrote regarding "Contributing to MacPorts (specifically to introduce am improved concurrent qt5-mac)"

Hi Marko, Brad,

>OFF-LIST --- This goes in CC also to Brad, as I have discussed with him about the topic.

Forgive me that I reply (in part)  VIA the list (leaving in only relevant sections).

>René, I have had a discussion with Brad about these issues as well and he told me that
>you and him are at the works on one of his VMs w.r.t. qt5-mac-devel… I must say I fully
>agree with him that we somehow need to find a means of supplying patches in a way which
>are easily digestible for those who (have to) review them.
>So, if we fail to make it easy (for them), we’ll fail in getting the concurrent port
>into MacPorts’ repository! Keeping changes small and formatted in such a way that they
>can be applied by MacPorts' trac-patch bash function is something I always try to achieve
>before publishing anything. You may ignore that, but it does no good in discussions with
>the core developer team - we’ve discussed about that in the past already. It often isn’t
>enough to post diffs into a ticket to make sure that some committer will simply commit it
>into MacPorts’ SVN tree. They have workflows which every contributor should (try to) stick
>to.

I understand, appreciate etc. but I'm not sure to what extent it's going to be feasible to break down the changeset between current qtN-mac and my respective versions in little, digestible chunks that each make sense. And that is independent of the fact that I've grown weary of taking up big chunks of work only to realise down the road that the powers that be are not interested.
I've tried to work with Michael and mcalhoun. Michael replied with some (delayed) regularity but mostly to say he didn't have time; mcalhoun, well, as you said, he apparently doesn't read his (@macports.org) email.
I also have been keeping the trac ticket with the qt4-mac changes up to date, but yes, it's a big changeset that has become off-putting to those who didn't follow the evolution. There *has* been considerable discussion on it (and on the ML), though.

[...]
>[mcalhoun] is qt5-mac's maintainer (now), because Michael couldn’t do this monster
>job all alone.

It is at regrettable that Michael didn't at least co-operate (and be co-maintainer), because the 2 Portfiles could have been much more similar. In particular, it seems not unlikely that certain errors were corrected in qt4-mac but never in qt5-mac until this week.

Anyway, qt5-mac is openmaintainer; that should mean it can be updated without mcalhoun's intervention. I don't know about consent or veto rules.

>
>Your concurrent qt5-mac port has so many changes to the previous qt5-mac port, that it
>was very hard for me to even start to look at it in detail. I have written about that
>at length already.
>So, from my perspective, the only chance to proceed with this is to somehow come up with
>small patches for the _current_ qt5-mac port, which would - ideally - fix step by step
>all of its nowadays shortcomings.

When I say I've grown weary, I sadly mean that quite literally. Yes, the change is considerable, and adding support for 10.6 and (thus) moving around things don't help in making it easier to navigate.
Nor to break it down in a series of small, incremental changes, which would then have to be reviewed, *all of them* by people who already have a workflow (with the result no one can predict what changes will come out of the review process and in what order).
Additionally, it's going to be very hard to bring myself to understand the current qt5-mac port and guess what was taken verbatim from my work, what was "inspired" by it, etc. I'm certainly *not* going to install it.

BTW, the weariness doesn't come from the Qt ports alone. There are others I worked on, and proposed changes for that did start small and that were never picked up on.

The result is that I'm quite content running my own (expanding) little repo, cherry-picking updates from mainstream and for the rest not breakin' anything that ain't fixed already.

>I agree this is a big job, but there can only be progress if we evolve from the situation
>as is now, as we can’t expect that the MacPorts dev team would copy-over your version
>of qt5-mac and dump mcalhoun’s just like that.

I'm not really expecting that, which is one reason I've been pushing a -devel port. I do think it is ripe enough to be pushed as an alternative to the official port and AFAIK it would not replace any existing port. It *installs* instead of another port, through the mechanism designed for that purpose. I put myself first on the maintainer list, and would of course assume the role that implies.
I'd really like to see this be done, and then some volunteer(s) to install and test the port before I commit myself to spending (as hopefully opposed to wasting) a lot more time on it. I'd only ask to get rid of the install ambiguity in the Qt5 portgroup. I know my work on this was self-commissioned, but heck, someone had to do it and it's not that I didn't try at first simply to assist the official maintainers.

What I could try to do in counterpart is a write-up of the changes, detailing the changes that are visible to the user (I'm hoping that smaller changes corresponding to bug fixes don't require much explanation beyond the comments in the source).
I don't think I added many variants, btw. I did add a number of subports, aiming to add some functionality and to break Qt up just a little bit (Qt5 is no longer meant to be installed monolithically as Qt4 was). This approach was also motivated by the fact that subports can be distributed in binary form, which is a HUGE boon for something as huge as Qt.

>You have invested so much effort and time into qt5-mac and you had fallen into mcalhoun’s
>current traps yourselves - but since it wasn’t published at the time no one knew about it,

Indeed, my experience with the qt4-mac ticket didn't encourage me to start another evolving ticket for Qt5, and sadly Michael's request to publish my port repo over git came (well) after I started work on Qt5.

>especially not him (who isn’t reading his emails anyway as we all know now). So, please,
>let all this not have been in vain and keep going. I wish I had more time to support you
>more, but currently I DO HAVE to focus on yet many other (personal) stuff.

I'm not asking you for support, beyond the moral support you're so good at (and the occasional svn push). OTOH, if you or Brad see something in my work that you think would be worth highlighting, let me know.
Yes, I'm trying to keep going (despite recurrent urges to throw all computers out of the window), but mostly I'd like to move on rather than to keep going back to the same drawing board.

>job, IMHO. They’re doing more maintenance than many Linux distributions. MacPorts’ port
>versions are very often at the tip of development, which I admire the MacPorts team for.

A bit too often if you ask me but that's a different topic.

>I have added you to two more qt5-related tickets this morning. I am afraid that these
>are also caused by mcalhoun’s recent changes… So, perhaps one could start creating
>patches for qt5-mac which help avoiding these issues?!

One could, but I still think it would be helpful if one could ask ticket reporters if they'd be willing to try the -devel port and see if that solves their issues. That'd be a lot easier if users don't have to add a local repository but get binary packages instead.

>Current port qt5-mac doesn’t go away just like that - it has to be transformed bit by
>bit in small enough pieces. *I* don’t know how to achieve this, but you may.

You may be right, but I'm not sure I agree it's the best way. Though one could probably argue that the biggest hurdle, making it co-installable, has already been cleared. Which isn't entirely accurate: in essence that was just a question of editing a few variables in the portgroup ...

>I couldn’t change your mind if you thought this is a useless task and you’d not want

Heh, not you maybe, but this *is* something for which I'd be willing to take br^H^H money (and can, actually).

>	I am afraid I wrote too much now. :)

That's what I always fear too writing on this ML ;)

> And I hope I can respond to this thread on MacPorts developer ML soon.

Wish granted?

Regards,
R.


More information about the macports-dev mailing list