Re: Best practice for port contributors in github world

[Lawrence Velázquez]

> On Dec 13, 2016, at 7:56 AM, Luc Bourhis  wrote:
> 
> file://path/to/my/clone/of/macports-ports [default]

Note that you have to use three slashes at the beginning of this line because 
the "/" that begins the absolute path is distinct from the "://" that separates 
the protocol. So:

file:///path/to/ports [default]

vq
Sent from my iPhone

Re: [macports-ports] branch master updated: phonon-backend-gstreamer(-qt5): update to 4.9.0 and introduce new subport

[Lawrence Velázquez]

> On Dec 12, 2016, at 11:46 PM, Marko Käning  wrote:
> 
> Yet, the git metadata is - also to my surprise -  still valid, which can be 
> verified by clicking all the links on the commit’s page:
> 
>   
> https://github.com/macports/macports-ports/commit/47c0c4f682b22803ae250258187544187d50f898
> 
> That will produce the 4 separate commits just fine.
> 
> Interesting.

Yeah, they'll linger until the PR branch is deleted and GitHub runs garbage 
collection on the repository.

vq

Re: [macports-ports] branch master updated: phonon-backend-gstreamer(-qt5): update to 4.9.0 and introduce new subport

[Lawrence Velázquez]

Please clean up the commit message when you perform squash merges. Most of the 
text here is outdated Git metadata (old SHA-1 hashes, repeated author name, 
irrelevant authorship dates).

vq

> On Dec 12, 2016, at 10:54 PM, Marko Käning  wrote:
> 
> Marko Käning (mkae) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/47c0c4f682b22803ae250258187544187d50f898
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 47c0c4f  phonon-backend-gstreamer(-qt5): update to 4.9.0 and 
> introduce new subport
> 47c0c4f is described below
> 
> commit 47c0c4f682b22803ae250258187544187d50f898
> Author: Marko Käning 
> AuthorDate: Tue Dec 13 04:54:01 2016 +0100
> 
> phonon-backend-gstreamer(-qt5): update to 4.9.0 and introduce new subport
> 
> Squash commit:
> 
> commit 5084c0bb0f4edef8ad380910182fad25a5c203f8
> Author: Marko Käning 
> Date:   Tue Dec 13 04:51:38 2016 +0100
> 
> phonon-backend-gstreamer-qt5: michaelld drops maintainership
> 
> commit 848cd25de1d3fa80eab96d6b5aa4d7deb9cb513f
> Author: Marko Käning 
> Date:   Tue Dec 13 04:47:21 2016 +0100
> 
> phonon-backend-gstreamer(-qt5): master_sites's folder changed for 
> 4.9.0
> 
> commit 909946083acb91e66b8d88a489773ba066e6954e
> Author: Marko Käning 
> Date:   Tue Dec 13 04:31:20 2016 +0100
> 
> phonon-backend-gstreamer: update to 4.9.0
> 
> - avoiding building the X11 renderer has changed => new patch
> - remove unused patches
> 
> commit ccaa0e34a4aa2fafc8276a6fb8d86fa8af7398a2
> Author: Marko Käning 
> Date:   Tue Dec 13 03:09:55 2016 +0100
> 
> phonon-backend-gstreamer: introduce qt5 support
> 
> - add co-maintainership for RJVB
> 
> Closes: https://trac.macports.org/ticket/46558
> ---
>  audio/phonon-backend-gstreamer/Portfile| 77 
> +++---
>  .../files/patch-cmake-FindGStreamer.cmake.diff | 43 
>  .../files/patch-gstreamer_CMakeLists.txt.diff  | 11 
>  .../files/phononBGSTr-avoid-x11renderer.patch  | 11 
>  4 files changed, 63 insertions(+), 79 deletions(-)
> 
> diff --git a/audio/phonon-backend-gstreamer/Portfile 
> b/audio/phonon-backend-gstreamer/Portfile
> index fd000d1..e1babc7 100644
> --- a/audio/phonon-backend-gstreamer/Portfile
> +++ b/audio/phonon-backend-gstreamer/Portfile
> @@ -1,36 +1,63 @@
>  # -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; 
> c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4
>  
>  PortSystem  1.0
> -PortGroup   qt4 1.0
> -PortGroup   cmake 1.0
>  
>  namephonon-backend-gstreamer
> -version 4.8.2
> -revision2
> -categories  audio kde kde4
> +version 4.9.0
>  license {LGPL-2.1 LGPL-3}
> -maintainers michaelld openmaintainer
> +maintainers gmail.com:rjvbertin mk openmaintainer
>  description GStreamer backend for Phonon
> -long_descriptionA GStreamer backend for the Phonon multimedia library.
>  platforms   darwin
>  homepagehttp://phonon.kde.org
> -master_siteskde:stable/phonon/${name}/${version}/src
> +master_siteskde:stable/phonon/${name}/${version}
>  use_xz  yes
>  distnamephonon-backend-gstreamer-${version}
> -checksums   rmd160 9c0ec7ef27e925c207e769edc225b1d7202c7e37 \
> -sha256 
> 20e0f71f2beb4f859db8385079a13aef5473863ee6f27aad7b065aa7bfe931e0
> -
> -depends_lib-append  port:phonon port:gstreamer1-gst-plugins-base
> -
> -depends_build-append port:automoc
> -
> -patchfiles  patch-cmake-FindGStreamer.cmake.diff \
> -phononBGSTr-avoid-x11renderer.patch
> -
> -cmake.out_of_source yes
> -
> -configure.args-append -DPhonon_DIR=${cmake_share_module_dir}/phonon
> -
> -livecheck.type   regex
> -livecheck.url
> http://www.gtlib.gatech.edu/pub/kde/stable/phonon/${name}/
> -livecheck.regex  "\(\\d+(?:\\.\\d+)*)\/"
> +checksums   rmd160  43095bdb9fe8729fd795910188c46cdcb0eae12f \
> +sha256  
> cec3e5ece1261d344b68363ef0606ebf49772628ba94bb55b0c0d18773b885f1
> +
> +# ATTENTION: This renaming is suddenly needed, as the foldername skips 
> "-backend" from version 4.8.2 to 4.9.0:
> +worksrcdir  phonon-gstreamer-${version}
> +
> +# NOTE: There is now a variable called BUILD_X11RENDERER, which seems to 
> control the building of the X11 renderer.
> +#   Weird, but this variable's default value in gstreamer's 
> CMakeLists.txt is set to TRUE, although FALSE is 

Re: PR final steps (to squash or not to squash)

[Lawrence Velázquez]

> On Dec 5, 2016, at 7:37 AM, René J.V. Bertin  wrote:
> 
> I guess we all have better things to do than this kind of task.

Our commit history is essentially communication with future committers
about what we did and why. Like any other communication, it should be
clear and useful.

Much like writing documentation, polishing the commit history is not
pleasant in the moment but is nevertheless time well-spent.

> I can see some justification for it in (very) complex software where
> you may be patching multiple files at once, but Portfiles are by
> definition single-file programs that are rarely of true complexity
> (rather, much complexity is hidden in "base").

They are also correspondingly easier to revise.

> OTOH it *is* true that whitespace changes can have more side-effects
> in Tcl than they have in C, but that's also a possible source of error
> when a 3rd party starts splitting up more elaborate change sets.

If you are worried about someone else editing your changes and botching
them, I encourage you to make them presentable yourself. Failing that,
committers reserve the right to modify submissions as they see fit
before merging.

> Even if one can still describe the evolution in a chronological
> sequence of things one has changed it can be really untrivial to start
> over and recreate the corresponding patches (which one would have to
> test, which means introducing local regressions, etc).

It doesn't have to be chronological, and each step need not be "correct"
on its own. We expect users to always have the latest ports tree, so
it's only important that the final result be correct. For example, in
a sequence of commits that each changes a port's installed files, only
the final commit need actually perform a revbump.

vq

Re: PR final steps (to squash or not to squash)

[Lawrence Velázquez]

> On Dec 5, 2016, at 10:38 AM, René J.V. Bertin  wrote:
> 
>> On Monday December 05 2016 14:58:08 Rainer Müller wrote:
>> 
>> What would be easier than just checking out the updated Portfile? You
>> can also just download the patch and apply it. Open for suggestions.
> 
> In this case that would probably rather be downloading the patch since
> checking out the portfile means fetching the whole fork with its full
> history.

Fetching from a fork does not download the full history. Only the
objects that are not in your repository are fetched.

>> Well, it gets easier if the pull request author takes care of this.
> 
> It certainly does, though not always by much, and only as long as the
> author has the exact same approach in splitting things up.

I daresay I'm the fussiest committer here. Most of us would probably not
nitpick a submitters' well-edited set of commits.

> And it's probably not trivial if possible at all to rewrite the
> history to correspond to a series of well-defined steps if those steps
> were never made as such at all, correct?

It's generally not trivial, no. Editing and revising prose to be clear
and concise isn't trivial, either.

> Side-ways related: maybe the Git/PR wiki topic could say a word or two
> about when a rebase request might be made before a PR can be merged.

Huh?

vq

Re: PR final steps (to squash or not to squash)

[Lawrence Velázquez]

> On Dec 5, 2016, at 8:57 PM, Zero King  wrote:
> 
>> From what I understand, what we'd really like for that case is
>> a "squash, rebase and merge" option. Unless we've misunderstood what
>> "squash and merge" does and it doesn't actually create a merge
>> commit?
> 
> No, it doesn't. See https://github.com/blog/2141-squash-your-commits.

Squash merging is also described in git-merge(1):

--squash, --no-squash
Produce the working tree and index state as if a real merge
happened (except for the merge information), but do not
actually make a commit, move the HEAD, or record
$GIT_DIR/MERGE_HEAD (to cause the next git commit command to
create a merge commit). This allows you to create a single
commit on top of the current branch whose effect is the same
as merging another branch (or more in case of an octopus).

With --no-squash perform the merge and commit the result.
This option can be used to override --squash.

The reason we are leery of "squash and merge" is not nonlinearity but
that it would be the default action on the GitHub website and could make
it too easy to mash a whole PR into one ungainly commit.

vq

Re: PR final steps (to squash or not to squash)

[Lawrence Velázquez]

> On Dec 5, 2016, at 5:14 AM, Mojca Miklavec  wrote:
> 
> Usually "larryv" is the one who takes most care to split commits

Hey now, why the scare quotes? :)

vq

Re: How should ports refer to the 2-clause BSD license?

[Lawrence Velázquez]

> On Dec 4, 2016, at 12:11 PM, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
>> On Dec 4, 2016, at 10:49, Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>> The checking script only mentions BSD (3-clause) and BSD-old
>> (4-clause).
> 
> As far as I was aware, we were referring to all three versions of the
> BSD licensee as "BSD". Is there a reason to do otherwise?

At a minimum, the 4-clause license must be distinguished as "BSD-old"
because it is not compatible with the GPL.

If we've already been referring to the 2-clause license as "BSD", it's
probably fine (from a practical standpoint) to continue doing so,
although the ambiguity doesn't sit well with me.

vq

Re: Tcl list-related 2.3.4 -> 2.3.5 changes?

[Lawrence Velázquez]

> On Dec 2, 2016, at 8:47 PM, Joshua Root  wrote:
> 
>> On 2016-12-3 02:45, René J.V. Bertin wrote:
>> 
>> Hi,
>> 
>> I'm trying to understand a regression that seems coupled to the
>> 2.3.4 -> 2.3.5 upgrade (or more exactly, "master just after 2.3.4"
>> -> "master 25 commits after 2.3.5").
>> 
>> I had
>> 
>> {{{
>> proc macports::normalize { filename } {
>>set nprefix [file dirname [file normalize "${macports::prefix}/foo"]]
>>return [string map {${nprefix} ${macports::prefix}} [file normalize 
>> $filename]]
>> }
>> }}}
> 
> This was wrong all along. The enclosing braces on {${nprefix}
> ${macports::prefix}} mean that no substitution will happen, so you're
> mapping between those literal strings.

Additionally, "string map" does not evaluate any of its arguments, as
certain other commands do (e.g., "if", "expr", "uplevel").

vq

Re: [macports-ports] branch master updated: databases/percona: Fixed percona download URL to use version_branch again. Removed $Id$ tag. Closes; #62 Closes: https://trac.macports.org/ticket/52664 Clos

[Lawrence Velázquez]

> On Nov 28, 2016, at 7:42 PM, Bradley Giesbrecht  wrote:
> 
> In IRC I wasn’t sure how to read Clemens comment: "Yes, Closes:
> $ticketlink, due to the length on their own lines, preferably”
> 
> I thought maybe a single long line commit message was not preferable.

That's right, otherwise you'd have something unwieldy like this:

Closes: https://trac.macports.org/ticket/52664 and 
https://trac.macports.org/ticket/52946

> Do you literally mean the second line blank, like this:
> “
> databases/percona:
> 
>Fixed percona download URL to use version_branch again.
>Removed $Id$ tag.
>Closes: #62
>Closes: https://trac.macports.org/ticket/52664
>Closes: https://trac.macports.org/ticket/52946
> “

Yes; the wiki page Marko linked to has more information.

For some idea of why this is important, skim the output of "git log
--oneline", which is intended to list commit subjects only. It's pretty
easy to find the commits that didn't leave the second line black.

> Is it a good idea to start the comment with a reference the port dir or 
> effected ports?

In general, yes; this makes commit lists more useful at a glance (e.g.,
https://github.com/macports/macports-ports/commits/master). This has not
changed from the Subversion days.

vq

Re: [macports-ports] branch master updated: databases/percona: Fixed percona download URL to use version_branch again. Removed $Id$ tag. Closes; #62 Closes: https://trac.macports.org/ticket/52664 Clos

[Lawrence Velázquez]

Hi,

> On Nov 28, 2016, at 7:13 PM, Roger Ward  wrote:
> 
> Bradley Giesbrecht (pixilla) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/2f43f23a572b62018bd0e4c0182df99f1a9bcd34
>  
> 
> The following commit(s) were added to refs/heads/master by this push:
>  new 2f43f23  databases/percona: Fixed percona download URL to use 
> version_branch again. Removed $Id$ tag. Closes; #62 Closes: 
> https://trac.macports.org/ticket/52664 Closes: 
> https://trac.macports.org/ticket/52946
> 2f43f23 is described below
> 
> commit 2f43f23a572b62018bd0e4c0182df99f1a9bcd34
> Author: Roger Ward 
> AuthorDate: Thu Nov 24 06:40:55 2016 -0700
> 
> databases/percona:
> Fixed percona download URL to use version_branch again.
> Removed $Id$ tag.
> Closes; #62
> Closes: https://trac.macports.org/ticket/52664
> Closes: https://trac.macports.org/ticket/52946
In future commit messages, please leave the second line blank.

vq

Re: `git describe`

[Lawrence Velázquez]

> On Nov 28, 2016, at 7:41 AM, René J.V. Bertin  wrote:
> 
> This is moot if master is exclusively a testing area for experiments
> that may never make it to a release. If it has a more usual role and
> is used by those who live on the bleeding edge, then my point stands

All development is done on master. Sufficiently stable features are
manually cherry-picked to branches, which are used to make releases. We
do not make releases directly from master. Master is generally stable
enough to use day-to-day, which many devs do.

vq

Re: How best to submit new port to maintainer, in a world of Github?

[Lawrence Velázquez]

> On Nov 26, 2016, at 6:25 PM, A. Karl Kornel  wrote:
> 
> I have a question about how best to deal with submitting a port update
> to an existing maintainer, in the new Git setup.
> 
> The port in question is "libvirt", which has Ryan as maintainer, but
> also has openmaintainer listed.

The "openmaintainer" policy concerns other committers and is not
something you have to worry about.

> I would like to know the best way of submitting an updated Portfile,
> while also notifying the maintainer.
> 
> I thought of four different options.  I say "the maintainer" instead
> of "Ryan" because I'm trying to think of an option would work for as
> many cases as possible.
> 
> 1. I could email the maintainer directly, but that seems too "closed"
>to me.

Yes, public methods are preferred so that feedback and discussion are
available for others to reference in the future.

> 2. I could put in a Trac ticket, but is that the best way for the
>future?

Trac remains fully supported. In fact, as far as notifications go, Trac
is the best option because Cc-ing maintainers guarantees that they will
be emailed. Plus, you can Cc maintainers without GitHub accounts
(although they will have to create a GitHub account to log into Trac).

Depending on one's feelings about email, this could also be considered
the worst option.

> 3. I could open the Pull request on Github, but I don't know if I have
>access to notify the maintainer directly.  It's probably possible,
>but would that work for every other maintainer?

GitHub users can receive notifications if you @-mention them in PR
conversation text or if a PR is assigned to them. But note that email
notifications are easily disabled in GitHub settings; the responsiveness
of users who do this will depend on how frequently they check GitHub.
And, naturally, you cannot @-mention a maintainer who does not have
a GitHub account.

> 4. I could open a Pull request on Github, and then email the
>maintainer separately, but the maintainer might get mad that
>I didn't use Trac.

I would not worry about this. Some contributors will insist on making
submissions through PRs, and we all just have to get used to it. (But:
If there is already a Trac ticket DO NOT OPEN A DUPLICATE PULL REQUEST.
PLEASE.)

There's no need to email if you open a PR and @-mention the maintainer.
If they don't respond within three days, you can follow-up via email as
usual (Cc'd to this mailing list).

vq

Stop "replacing" existing Trac tickets with GitHub pull requests

[Lawrence Velázquez]

I know you all think GitHub pull requests are the bee's knees, but
please DO NOT open pull requests to "replace" existing Trac tickets. It
doesn't actually help committers evaluate submissions, and it splits the
discussion across Trac and GitHub.

vq

Re: [macports-ports] 02/02: py-geopy: delete py26 and py33 subports. See also https://trac.macports.org/ticket/52881

[Lawrence Velázquez]

> On Nov 16, 2016, at 4:40 PM, Mark Moll  wrote:
> 
> Mark Moll (mamoll) pushed a commit to branch master
> in repository macports-ports.
> 
> https://github.com/macports/macports-ports/commit/feb1081ffcbf1d0b06250a9f20c1095f8c4cbb67
>  
> 
> commit feb1081ffcbf1d0b06250a9f20c1095f8c4cbb67
> Author: Mark Moll 
> AuthorDate: Wed Nov 16 15:40:41 2016 -0600
> 
> py-geopy: delete py26 and py33 subports. See also 
> https://trac.macports.org/ticket/52881
> ---
>  python/py-geopy/Portfile | 3 +--
>  python/py-graveyard/Portfile | 1 +
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/python/py-graveyard/Portfile b/python/py-graveyard/Portfile
> index 8e32c6c..90c5c24 100644
> --- a/python/py-graveyard/Portfile
> +++ b/python/py-graveyard/Portfile
> @@ -72,6 +72,7 @@ py-gdal 2.0.0_1 26
>  py-gdata2.0.18_126
>  py-gdl  2.25.3_226
>  py-geopandas0.1.1_1 33
> +py-geopy1.11.0  26 33
>  py-gitpython2.0.2_1 26
>  py-gmpy 1.17_1  25 26 31 32 33
>  py-gmpy22.0.7_1 26 31 32 33
> 

For the subports to be replaced properly, you need to "revbump" them as you 
move them to the graveyard. So this entry should be changed to "1.11.0_1".

vq

Re: Another workflow (pull requests) question.

[Lawrence Velázquez]

> On Nov 14, 2016, at 2:44 PM, Eric A. Borisch  wrote:
> 
>> On Mon, Nov 14, 2016 at 1:17 PM, Rainer Müller  wrote:
>> 
>> I am not opposed to enabling "Squash and merge", but we have no
>> guide for maintainers explaining the pull request workflow. If we
>> had this, it could explain the differences between the "Rebase and
>> merge" and "Squash and merge" button and when to use what.
> 
> Well, I vote for some education (guide section) plus enabling the
> squash and merge button.

We have a chicken-and-egg problem insofar as we don't really understand
how PRs work, so we cannot document how they work. I "botched"* the PR
under discussion because force-pushing to the PR branch did not do what
I had observed in previous PRs.

I am not particularly keen on enabling squash-and-merge because it might
encourage developers to (a) not bother testing and (b) write poor commit
messages on the GitHub web page.

* I say "botched" because I don't really care that that PR has been
  resolved as non-"Merged".

vq

Re: GitHub migration complete

[Lawrence Velázquez]

> On Nov 7, 2016, at 12:39 PM, Lawrence Velázquez <lar...@macports.org> wrote:
> 
>> On Nov 7, 2016, at 12:29 PM, René J.V. Bertin <rjvber...@gmail.com> wrote:
>> 
>> As long as it doesn't cause problems elsewhere I think there
>> shouldn't be any hard rules making this kind of thing impossible.
>> That wouldn't fit in a model where people contribute freely.
> 
> As ever, you can do whatever you like locally. There's no way anyone can
> stop you from writing your own smudge and clean filters.

But portfiles still will not contain "$Id" or anything like it. You'll
have to make do without.

vq

Re: GitHub migration complete

[Lawrence Velázquez]

> On Nov 7, 2016, at 12:29 PM, René J.V. Bertin <rjvber...@gmail.com> wrote:
> 
>> On Monday November 07 2016 11:52:17 Lawrence Velázquez wrote:
>> 
>> Any sort of Git keyword expansion must happen client-side, which means
>> such keywords/markers would only be useful to developers who choose to
>> configure their local repositories appropriately, which means that they
>> can never be useful to more than a (very) small minority of us.
> 
> That's exactly what I said, developers who find this useful can
> implement something themselves even when there's no support/use for it
> upstream. As long as it doesn't cause problems elsewhere I think there
> shouldn't be any hard rules making this kind of thing impossible. That
> wouldn't fit in a model where people contribute freely.

As ever, you can do whatever you like locally. There's no way anyone can
stop you from writing your own smudge and clean filters.

vq

Re: PR usage by people with commit access

[Lawrence Velázquez]

> On Nov 5, 2016, at 1:03 PM, Marko Käning <mk-macpo...@posteo.net> wrote:
> 
>> On 04 Nov 2016, at 19:00 , Lawrence Velázquez <lar...@macports.org> wrote:
>> 
>> Sure. I would encourage committers who want feedback to open as many PRs
>> as they want.
>> 
>> (You get a PR! You get a PR! Everybody gets a PR!!!)
> 
> good to know.
> 
> That’s quite a different response than what I faced with PR #7 at first…

I think the objection to #7 is that it was intentionally posted in an
incomplete state with the expectation that development would continue in
the pull request. I am not sure that that is the best approach for us.

When I said that committers should feel free to open PRs, I meant PRs
for contributions that are essentially complete and might just need
a bit of tweaking.

vq

Re: [macports-ports] branch master updated: misc: follow up on base changes and mass-unbreak ports in trace mode.

[Lawrence Velázquez]

> On Nov 7, 2016, at 10:37 AM, Rainer Müller  wrote:
> 
> Multiple of the affected ports just change the '.cmd' to 'autogen.sh'.
> Would it make sense to have an additional use_autogensh that defaults to
> this and adds dependencies on autoconf, automake, libtool?

This is a good idea. Over 200 ports reference "autogen.sh".

vq