Re: [macports-ports] branch master updated: msieve: upgrade to 1.53, add ecm variant, take maintainership

> On Nov 14, 2016, at 7:25 AM, NicosPavlov > wrote: > > NicosPavlov pushed a commit to branch master > in repository macports-ports. > > > https://github.com/macports/macports-ports/commit/7b571f2dcc80a4650dfd5f9be8f03a40bb53cad7 > > The following commit(s) were added to refs/heads/master by

Another workflow (pull requests) question.

If I see something like this -- https://github.com/macports/ macports-ports/pull/37 -- come through, and it LGTM, do I just push the big 'Rebase and merge' button on the GitHub GUI? (This particular one is an update to a nomaintainer port (fish) to the latest upstream version, removes no-longer-nee

Re: Another workflow (pull requests) question.

> On Nov 14, 2016, at 10:51 AM, Eric A. Borisch wrote: > > If I see something like this -- > https://github.com/macports/macports-ports/pull/37 -- come through, and it > LGTM, do I just push the big 'Rebase and merge' button on the GitHub GUI? > (This particular one is an update to a nomainta

Re: Another workflow (pull requests) question.

If squash-and-merge is what we're going to want for pull requests, can we re-enable the button? (Also known as, if we're using GitHub, can we use GitHub?) Ideally contributions from others (like this pull request) should be as painless (read as: fewest steps that still achieve the desired ends) as

Re: Another workflow (pull requests) question.

> On Nov 14, 2016, at 11:11 AM, Eric A. Borisch wrote: > > If squash-and-merge is what we're going to want for pull requests, can we > re-enable the button? (Also known as, if we're using GitHub, can we use > GitHub?) Ideally contributions from others (like this pull request) should be > as p

Re: Another workflow (pull requests) question.

On Mon, Nov 14, 2016 at 10:51 AM, Eric A. Borisch wrote: > If I see something like this -- https://github.com/ > macports/macports-ports/pull/37 -- come through, and it LGTM, do I just > push the big 'Rebase and merge' button on the GitHub GUI? (This particular > one is an update to a nomaintaine

Re: Another workflow (pull requests) question.

On 2016-11-14 18:11, Eric A. Borisch wrote: > If squash-and-merge is what we're going to want for pull requests, can > we re-enable the button? (Also known as, if we're using GitHub, can we > use GitHub?) Ideally contributions from others (like this pull request) > should be as painless (read as: f

Re: Another workflow (pull requests) question.

On 2016-11-14 18:24, Eric A. Borisch wrote: > Additionally, this PR also has changes requested by another committer, > and acted upon (source of the second commit) by the requestor in the > pull request. If I were to push the "Rebase and merge", should I first > "Dismiss review" with "Requested cha

Re: Another workflow (pull requests) question.

On Mon, Nov 14, 2016 at 11:36 AM, Rainer Müller wrote: > On 2016-11-14 18:11, Eric A. Borisch wrote: > > If squash-and-merge is what we're going to want for pull requests, can > > we re-enable the button? (Also known as, if we're using GitHub, can we > > use GitHub?) Ideally contributions from ot

Re: Another workflow (pull requests) question.

Hello all, Just jumping in as I'm the committer of this pull request. Is something else expected from the committer after the review has been done and then completed ? Would it be easier for the reviewer that the comitter rebase the pull request branch on top of master upon rework after the review

Re: Another workflow (pull requests) question.

On 2016-11-14 19:33, Eric A. Borisch wrote: > OK, so to be pedantic, instead of using the the GitHub "Squash and > merge" button (one click) committers are going to: > > 1) Go to their local (filesystem) copy of macports-ports > 2) git checkout -b dgsb-master master > 3) git pull git://github.com/

Re: Another workflow (pull requests) question.

On Mon, Nov 14, 2016 at 1:17 PM, Rainer Müller wrote: > I agree this is not the easiest workflow we could have. However, even > with "Squash and merge" button, you could only replace 4) and 5) of your > steps with the web interface. You still need to the other steps to test > the changes anyway.

Re: Another workflow (pull requests) question.

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

Re: [macports-ports] 02/03: git-cola: install bash-completion

> On Nov 14, 2016, at 5:05 PM, Rainer Müller > wrote: > > +notes [subst { > > +If you want to use bash-completion for git-cola, you have to source the\ > > +completion files from your ~/.bashrc as it extends the git command\ > > +completion and cannot be loaded automatically: >

Re: Another workflow (pull requests) question.

On Nov 14, 2016, at 1:44 PM, Eric A. Borisch wrote: > As a wish list item, It would be awesome to have an automated build that > would run at least through the checksum phase for PRs with just version # and > checksum changes. Yes, automated builds of pull requests would be awesome. But that w

Re: [macports-ports] 02/03: git-cola: install bash-completion

On 2016-11-15 00:50, Ryan Schmidt wrote: > Why is using the weird > > [subst {...}] > > here better than using > > "..." > > ? There is no way to split a line within "..." done here with the backslashes at the end of the lines within {...}. With quotes, it would either require to keep

Re: [macports-ports] 02/03: git-cola: install bash-completion

> On Nov 14, 2016, at 6:05 PM, Rainer Müller wrote: > > On 2016-11-15 00:50, Ryan Schmidt wrote: > >> Why is using the weird >> >>[subst {...}] >> >> here better than using >> >>"..." >> >> ? > > There is no way to split a line within "..." done here with the > backslashes at the e

Automatic checks on pull requests (was: Re: Another workflow (pull requests) question.)

On 2016-11-14 20:44, Eric A. Borisch wrote: > As a wish list item, It would be awesome to have an automated build that > would run at least through the checksum phase for PRs with just version > # and checksum changes. This would be nice indeed. However, as Portfiles are executable code, this requ

Re: [macports-ports] 02/03: git-cola: install bash-completion

On 2016-11-15 01:07, Ryan Schmidt wrote: > notes " > If you want to use bash-completion for git-cola, you have to source the\ > completion files from your ~/.bashrc as it extends the git command\ > completion and cannot be loaded automatically: > > source ${prefix}/share/bash-com

Re: [macports-ports] branch master updated: msieve: upgrade to 1.53, add ecm variant, take maintainership

>> @@ -32,6 +33,10 @@ post-patch { >> >> use_configure no >> >> +if {[variant_isset ecm]} { >> +build.args ECM=1 >> +} >> + > > Why did you put this code here in a block by itself? Why not set (or better > yet: append to) build.args inside the emc variant declaration, so that all >

Re: [macports-ports] branch master updated: grib_api: delete unused CMake flags

> On Nov 14, 2016, at 6:42 PM, tenomoto > wrote: > > tenomoto pushed a commit to branch master > in repository macports-ports. > > > https://github.com/macports/macports-ports/commit/8dd1f26e3c8218708a97ac7bd1d4b0aae1984046 > > The following commit(s) were added to refs/heads/master by this

[macports-ports] branch master updated: sqlite3: use readline rather than editline to permit non-ASCII characters

FYI, this reverses the decision made in and makes at least 79 ports non-distributable. - Josh