On 16 November 2016 at 11:30, Rainer Müller wrote:
> On 2016-11-16 04:09, Ryan Schmidt wrote:
>>
>>> On Nov 15, 2016, at 6:06 AM, rod wrote:
>>>
>>> (Apologies if this has been brought up before but I couldn't find a
>>> way to search the mailing list archives...)
>>>
>>> Travis CI has tight integ
On 2016-11-16 04:09, Ryan Schmidt wrote:
>
>> On Nov 15, 2016, at 6:06 AM, rod wrote:
>>
>> (Apologies if this has been brought up before but I couldn't find a
>> way to search the mailing list archives...)
>>
>> Travis CI has tight integration with Github for testing PRs, and
>> may offer what
> On Nov 15, 2016, at 6:06 AM, rod wrote:
>
> (Apologies if this has been brought up before but I couldn't find a way to
> search the mailing list archives...)
>
> Travis CI has tight integration with Github for testing PRs, and may offer
> what you need...
>
> https://docs.travis-ci.com/use
(Apologies if this has been brought up before but I couldn't find a way to
search the mailing list archives...)
Travis CI has tight integration with Github for testing PRs, and may offer
what you need...
https://docs.travis-ci.com/user/osx-ci-environment/
https://docs.travis-ci.com/user/customizi
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
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
> 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
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.
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/
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
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
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
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
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
> 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
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
> 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
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
18 matches
Mail list logo
