Re: rsync not being kept up to date?

[Ryan Schmidt]

> On Nov 3, 2016, at 11:03 PM, Ryan Schmidt  wrote:
> 
>> 
>> On Nov 3, 2016, at 11:02 PM, Joshua Root  wrote:
>> 
>> On 2016-11-4 14:53 , Blair Zajac wrote:
>>> 
 On Nov 3, 2016, at 8:51 PM, Joshua Root  wrote:
 
 On 2016-11-4 14:41 , Blair Zajac wrote:
> Seeing some odd things with rsync with this config:
> 
> root@poppy-mbp:~#  grep -v ^# /opt/local/etc/macports/sources.conf | uniq
> 
> rsync://rsync.macports.org/release/ports/ [default]
> 
> 
> 
> root@poppy-mbp:~# port -v outdated
> The following installed ports are outdated:
> curl-ca-bundle 7.50.3_0 < 7.50.3_1
> mercurial  3.9.2_0 < 4.0_0
> root@poppy-mbp:~# port -v upgrade --enforce-variants outdated
> --->  Scanning binaries for linking errors
> --->  No broken files found.
> root@poppy-mbp:~#
> 
> 
> It doesn’t look like the files on rsync.macports.org are being kept up to 
> date. Did I miss a command to run on my MacPort installs?
 
 Ryan mentioned earlier that his internet connection was being saturated by 
 package uploads, which delays the update of the ports tree and index.
 
 But in this case you do see the new version, so that can't be what 
 happened. Did you activate the older version of these ports after 
 upgrading previously? If not, does 'port info mercurial' agree with 'port 
 info --index mercurial’?
>>> 
>>> No, I didn’t activate the old versions of the ports. The two commands don’t 
>>> match:
>>> 
>>> $ port info mercurial | head -2
>>> mercurial @3.9.2 (devel, python)
>>> Sub-ports:mercurial-devel
>>> 
>>> 
>>> $ port info --index mercurial | head -2
>>> mercurial @4.0 (devel, python)
>>> Sub-ports:mercurial-devel
>> 
>> OK, so the Portfiles are up to date but not the PortIndex. Not sure why that 
>> would be happening; I guess Ryan needs to take a look.
> 
> The other way around. Looking at the FAU rsync server, the PortIndex was 
> updated today, but the mercurial Portfile has not been updated since all 
> Portfiles were updated on October 30 when we switched to Git. I don't yet 
> know why.

It's currently busy uploading binaries for lalsuite-extra @1.2.0 -- they're 2GB 
apiece. This might take another day to finish.


https://packages.macports.org/lalsuite-extra/


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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-4 15:02 , Joshua Root wrote:

On 2016-11-4 14:53 , Blair Zajac wrote:


$ port info mercurial | head -2
mercurial @3.9.2 (devel, python)
Sub-ports:mercurial-devel


$ port info --index mercurial | head -2
mercurial @4.0 (devel, python)
Sub-ports:mercurial-devel


OK, so the Portfiles are up to date but not the PortIndex. Not sure why
that would be happening; I guess Ryan needs to take a look.


No, wait, other way round. That's even stranger. :-|

Could be the non-tarball ports tree is not updating properly. Try 
changing to the tarball? That's a good idea anyway as it's signed.


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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-4 14:53 , Blair Zajac wrote:



On Nov 3, 2016, at 8:51 PM, Joshua Root  wrote:

On 2016-11-4 14:41 , Blair Zajac wrote:

Seeing some odd things with rsync with this config:

root@poppy-mbp:~#  grep -v ^# /opt/local/etc/macports/sources.conf | uniq

rsync://rsync.macports.org/release/ports/ [default]



root@poppy-mbp:~# port -v outdated
The following installed ports are outdated:
curl-ca-bundle 7.50.3_0 < 7.50.3_1
mercurial  3.9.2_0 < 4.0_0
root@poppy-mbp:~# port -v upgrade --enforce-variants outdated
--->  Scanning binaries for linking errors
--->  No broken files found.
root@poppy-mbp:~#


It doesn’t look like the files on rsync.macports.org are being kept up to date. 
Did I miss a command to run on my MacPort installs?


Ryan mentioned earlier that his internet connection was being saturated by 
package uploads, which delays the update of the ports tree and index.

But in this case you do see the new version, so that can't be what happened. 
Did you activate the older version of these ports after upgrading previously? 
If not, does 'port info mercurial' agree with 'port info --index mercurial’?


No, I didn’t activate the old versions of the ports. The two commands don’t 
match:

$ port info mercurial | head -2
mercurial @3.9.2 (devel, python)
Sub-ports:mercurial-devel


$ port info --index mercurial | head -2
mercurial @4.0 (devel, python)
Sub-ports:mercurial-devel


OK, so the Portfiles are up to date but not the PortIndex. Not sure why 
that would be happening; I guess Ryan needs to take a look.


To work around you can probably run portindex.

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

Re: rsync not being kept up to date?

[Joshua Root]

On 2016-11-4 14:41 , Blair Zajac wrote:

Seeing some odd things with rsync with this config:

root@poppy-mbp:~#  grep -v ^# /opt/local/etc/macports/sources.conf | uniq

rsync://rsync.macports.org/release/ports/ [default]



root@poppy-mbp:~# port -v outdated
The following installed ports are outdated:
curl-ca-bundle 7.50.3_0 < 7.50.3_1
mercurial  3.9.2_0 < 4.0_0
root@poppy-mbp:~# port -v upgrade --enforce-variants outdated
--->  Scanning binaries for linking errors
--->  No broken files found.
root@poppy-mbp:~#


It doesn’t look like the files on rsync.macports.org are being kept up to date. 
Did I miss a command to run on my MacPort installs?


Ryan mentioned earlier that his internet connection was being saturated 
by package uploads, which delays the update of the ports tree and index.


But in this case you do see the new version, so that can't be what 
happened. Did you activate the older version of these ports after 
upgrading previously? If not, does 'port info mercurial' agree with 
'port info --index mercurial'?


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

Re: How to keep uncommitted work in a git clone

[Joshua Root]

On 2016-11-4 12:56 , Ryan Schmidt wrote:

With Subversion, I was accustomed to keeping changes in my working copy that I 
was not ready to commit yet.

Git doesn't let me do that. It complains and tells me to git stash and later 
git stash pop.

Well, I tried that. I git stashed, then made changes to curl and committed 
them, and later when I tried to git stash pop, my other changes that I had in 
my git clone were not restored. I have no idea where they are now.

I can get these particular changes back from my old Subversion working copy, 
but I don't understand how I'm meant to work with git when I have changes that 
I'm not ready to commit yet, yet there are other changes I need to make and 
commit elsewhere within that same clone.


Using autostash as discussed earlier works well for me:



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

rsync not being kept up to date?

[Blair Zajac]

Seeing some odd things with rsync with this config:

root@poppy-mbp:~#  grep -v ^# /opt/local/etc/macports/sources.conf | uniq

rsync://rsync.macports.org/release/ports/ [default]



root@poppy-mbp:~# port -v outdated
The following installed ports are outdated:
curl-ca-bundle 7.50.3_0 < 7.50.3_1   
mercurial  3.9.2_0 < 4.0_0   
root@poppy-mbp:~# port -v upgrade --enforce-variants outdated
--->  Scanning binaries for linking errors
--->  No broken files found. 
root@poppy-mbp:~# 


It doesn’t look like the files on rsync.macports.org are being kept up to date. 
Did I miss a command to run on my MacPort installs?

Blair

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

Re: Working with Git

[Ryan Schmidt]

On Nov 3, 2016, at 21:41, Lawrence Velázquez  wrote:

>> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt  wrote:
>> 
>> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git
>> branch -d l2dy-curl-ca-bundle-update" failed because of an error.
> 
> Do you remember what the error was? The next time it happens could you
> let me know? I could certainly have overlooked something.

I think the complaint was that not all of the changes in the branch could be 
found elsewhere so deleting the branch might lose information. 

I had committed one additional change to the local branch prior to merging it 
to the local master. 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Working with Git

[Lawrence Velázquez]

> On Nov 3, 2016, at 9:48 PM, Ryan Schmidt  wrote:
> 
> I did already run "git branch -D l2dy-curl-ca-bundle-update" when "git
> branch -d l2dy-curl-ca-bundle-update" failed because of an error.

Do you remember what the error was? The next time it happens could you
let me know? I could certainly have overlooked something.

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

Re: How to keep uncommitted work in a git clone

[Jeremy Lavergne]

Religiously use `git status`, and perhaps update your shell prompt to
reflect it as well: branch name, unstaged changes, staged changes, etc.
Consider looking on Google for prompts that incorporate functions like
__git_ps1:
GIT_PS1_SHOWDIRTYSTATE="1"
GIT_PS1_SHOWUNTRACKEDFILES="1"
PS1="\h:\W \u$BLUE\$(__git_ps1 \" [%s]\")$DEFAULT\$ "


The current working tree is by default unstaged. You must select what to
stage, or explicitly indicate files during actions. For example, these
are equivalent commands for commits changes to foo.txt (a file already
in the repo):

 1echo "asdf" >> foo.txt
  git add foo.txt
  git commit -m "adding foo"

 2echo "asdf" >> foo.txt
  git commit foo.txt -m "adding foo"


That first form is how you commit only explicit files while leaving more
for a subsequent commit. Same idea for `git add -p` for parts of files.
Once things are staged, leaving off filenames means the actions apply to
the staged changes.



Regarding the stash situation:  The nice thing about git is won't do
anything destructive without you forcing it.

Checkout the stashes and see if you perhaps made a second one?
   git stash list  # (or otherwise `git help stash`)
   git show stash@{0}


So your changes are very likely still there: either as a second stash,
or perhaps conflicting with the new working tree.

git status :-)


On 11/03/2016 09:56 PM, Ryan Schmidt wrote:
> With Subversion, I was accustomed to keeping changes in my working copy that 
> I was not ready to commit yet.
> 
> Git doesn't let me do that. It complains and tells me to git stash and later 
> git stash pop.
> 
> Well, I tried that. I git stashed, then made changes to curl and committed 
> them, and later when I tried to git stash pop, my other changes that I had in 
> my git clone were not restored. I have no idea where they are now.
> 
> I can get these particular changes back from my old Subversion working copy, 
> but I don't understand how I'm meant to work with git when I have changes 
> that I'm not ready to commit yet, yet there are other changes I need to make 
> and commit elsewhere within that same clone.

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

Re: Working with Git

[Ryan Schmidt]

> On Nov 3, 2016, at 10:36 AM, Lawrence Velázquez  wrote:
> 
>> On Nov 2, 2016, at 11:24 PM, Ryan Schmidt  wrote:
>> 
>> Yes, there are "command line instructions" on the web site, but they
>> are different from the commands you gave below, which are again
>> different from other commands suggested in previous threads, so it is
>> difficult to know which set of instructions to follow.
> 
> Obviously I think you should follow mine ;)
> 
> The GitHub instructions assume that you're okay with nonlinear history
> (they create merge commits), so we can't really use them. But I found
> them useful for developing my instructions.

Your instructions and theirs already differ in the way in which the branch 
changes are obtained.

You said:

> To obtain the submitter's changes:
> 
>   $ git fetch https://github.com/l2dy/macports-ports.git 
> curl-ca-bundle-update
>   $ git checkout -b l2dy-curl-ca-bundle-update FETCH_HEAD
>   $ git rebase master l2dy-curl-ca-bundle-update
> 
> The first command imports changes from the submitter's
> "curl-ca-bundle-update" branch. The second command creates a new local
> branch to match. The third command transplants the submitter's changes
> onto the top of your master branch. (Rebasing will fail if the
> submitter's changes don't apply cleanly to the current ports tree. You
> can just ask them to fix this themselves and push a new branch.)
> 
> Now you can check out the new branch and try out the submitter's
> changes. You can also modify the branch as you see fit.
> 
>   $ git checkout l2dy-curl-ca-bundle-update

They say:

> Step 1: From your project repository, check out a new branch and test the 
> changes.
> 
> git checkout -b l2dy-curl-ca-bundle-update master
> git pull https://github.com/l2dy/macports-ports.git curl-ca-bundle-update




>> Thanks, that worked, up until the "git push origin master" command,
>> which asked me to authenticate, and supplying my username and password
>> was unsuccessful:
>> 
>> $ git push origin master
>> Username for 'https://github.com': ryandesign
>> Password for 'https://ryandes...@github.com': 
>> remote: Invalid username or password.
>> fatal: Authentication failed for 
>> 'https://github.com/macports/macports-ports.git/'
> 
> That's curious. What does "git remote -v" print?

$ git remote -v
origin  https://github.com/macports/macports-ports.git (fetch)
origin  https://github.com/macports/macports-ports.git (push)

Possibly relevant: I do, of course, use two-factor authentication, but I just 
supplied my password; I was not asked to provide a two-factor auth token. I 
remember having to follow some instructions to set up GitHub Desktop with some 
kind of access to allow it to commit, but that was months ago so I couldn't 
tell you what I did.


>> Now I still seem to have this branch in my local git repo:
>> 
>> $ git branch
>> l2dy-curl-ca-bundle-update
>> * master
>> 
>> Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"?
> 
> Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
> suggested because these instructions are designed so that you can always
> fast-forward merge the PR branch into master. If "git branch -d" fails,
> something is not right, and you have to go back and figure out what.

I did already run "git branch -D l2dy-curl-ca-bundle-update" when  "git branch 
-d l2dy-curl-ca-bundle-update" failed because of an error.


> One small addendum: Before "git push origin master", you should run "git
> pull --rebase" to get any new commits that were pushed by other
> committers.

I assume if this was necessary I would have received an error message when I 
tried to push?


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

Re: Pull Requests for Work in Progress (WIP)

[Arno Hautala]

>>> The main question of procedure is: Should the main macports repo be
>>> used for proposing review of work in progress via pull requests?  If
>>> not, what is the proposed method?
>>
>> I propose you put your changes on a branch, add the compare URL to a
>> ticket or send an email to macports-dev.
>>
> The downside (as I see it) of using the compare URL, as opposed to a full 
> pull request, is that line by line comments are not available.

I started out on the side of just keeping the pull request for a
completed work. But, it occurs to me that one of the goals of moving
to GitHub is greater collaboration and that is facilitated by inline
comments on the pull request. Plus, a completed pull request is one
comment away from a work in progress anyway.

The other side that I see is that this furthers the existing
separation where pull requests (and now work-in-progress discussions)
are on GitHub and ticket discussions are on Trac. Given that pull
requests are already on GitHub, I don't think this is a significant
issue.

The alternative to WiP pull requests is posting multiple comparison
URLs to reference different lines of code that must be opened in
different windows. Plus, those references will break as soon as any
changes are made to the branch.

-- 
arno  s  hautala/-|   a...@alum.wpi.edu

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 2:46 PM, Lawrence Velázquez  wrote:
> 
> 
>> On Nov 3, 2016, at 2:16 PM, Rainer Müller  wrote:
>> 
>> On 2016-11-03 18:57, Lawrence Velázquez wrote:
 On Nov 3, 2016, at 1:46 PM, Rainer Müller  wrote:
 
 I think the proper way to do it on GitHub would be as follows:
 When the pull request author checked the box for "Allow modifications by
 maintainers" [1], you can force-push your changes to the pull request
 branch, replacing the original commits. Then you can merge the pull
 request from the GitHub web interface.
>>> 
>>> GitHub will also automatically close the PR as "merged" if you push the
>>> PR branch's changes to master from a local client. It's quite nice.
>> 
>> If I understand this correctly, the exact commits have to be on the pull
>> request branch for GitHub to recognize you want to close the PR. So I
>> would have to push them first to the pull request branch and then to master.
> 
> Yeah, I think that's right. That means that rebasing from the command
> line is not feasible for most PRs because the contributors' branch is
> unlikely to be based on the absolute latest master. So I think the
> process you mentioned (push to collaborator's branch, rebase from the
> web) might become our standard operating procedure.

Actually I think I was mistaken about this. Rebasing onto master + fast-forward 
merging + pushing from the command line works fine, as long as you force-push 
your local changes to the PR branch first. It doesn't seem to matter where the 
PR branch was branched from; GitHub knows to isolate the changes that aren't in 
the base branch.

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

Re: Properly merging pull requests

[Ivan Larionov]

My 2 cents:

* cherry-pick will always change commit hash and github won't see it as the
same commit as from original PR
* "Closed #10" syntax was designed to close Issues from commit messages. I
think if you do "Closes #10" for PR it will close a PR in the way it will
look like it was declined
* I think asking contributor to make required changes and then just merging
is a proper way to manage PRs. If you want to help contributor add comments
to bad lines or provide correct code snippets

On Thu, Nov 3, 2016 at 11:46 AM, Lawrence Velázquez 
wrote:

>
> > On Nov 3, 2016, at 2:16 PM, Rainer Müller  wrote:
> >
> > On 2016-11-03 18:57, Lawrence Velázquez wrote:
> >>> On Nov 3, 2016, at 1:46 PM, Rainer Müller  wrote:
> >>>
> >>> I think the proper way to do it on GitHub would be as follows:
> >>> When the pull request author checked the box for "Allow modifications
> by
> >>> maintainers" [1], you can force-push your changes to the pull request
> >>> branch, replacing the original commits. Then you can merge the pull
> >>> request from the GitHub web interface.
> >>
> >> GitHub will also automatically close the PR as "merged" if you push the
> >> PR branch's changes to master from a local client. It's quite nice.
> >
> > If I understand this correctly, the exact commits have to be on the pull
> > request branch for GitHub to recognize you want to close the PR. So I
> > would have to push them first to the pull request branch and then to
> master.
>
> Yeah, I think that's right. That means that rebasing from the command
> line is not feasible for most PRs because the contributors' branch is
> unlikely to be based on the absolute latest master. So I think the
> process you mentioned (push to collaborator's branch, rebase from the
> web) might become our standard operating procedure.
>
> vq
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>



-- 
With best regards, Ivan Larionov.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 2:16 PM, Rainer Müller  wrote:
> 
> On 2016-11-03 18:57, Lawrence Velázquez wrote:
>>> On Nov 3, 2016, at 1:46 PM, Rainer Müller  wrote:
>>> 
>>> I think the proper way to do it on GitHub would be as follows:
>>> When the pull request author checked the box for "Allow modifications by
>>> maintainers" [1], you can force-push your changes to the pull request
>>> branch, replacing the original commits. Then you can merge the pull
>>> request from the GitHub web interface.
>> 
>> GitHub will also automatically close the PR as "merged" if you push the
>> PR branch's changes to master from a local client. It's quite nice.
> 
> If I understand this correctly, the exact commits have to be on the pull
> request branch for GitHub to recognize you want to close the PR. So I
> would have to push them first to the pull request branch and then to master.

Yeah, I think that's right. That means that rebasing from the command
line is not feasible for most PRs because the contributors' branch is
unlikely to be based on the absolute latest master. So I think the
process you mentioned (push to collaborator's branch, rebase from the
web) might become our standard operating procedure.

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

Re: Properly merging pull requests

[Rainer Müller]

On 2016-11-03 18:57, Lawrence Velázquez wrote:
>> On Nov 3, 2016, at 1:46 PM, Rainer Müller  wrote:
>>
>> I think the proper way to do it on GitHub would be as follows:
>> When the pull request author checked the box for "Allow modifications by
>> maintainers" [1], you can force-push your changes to the pull request
>> branch, replacing the original commits. Then you can merge the pull
>> request from the GitHub web interface.
> 
> GitHub will also automatically close the PR as "merged" if you push the
> PR branch's changes to master from a local client. It's quite nice.

If I understand this correctly, the exact commits have to be on the pull
request branch for GitHub to recognize you want to close the PR. So I
would have to push them first to the pull request branch and then to master.

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

Re: Pull Requests for Work in Progress (WIP)

[Sterling Smith]

On Nov 3, 2016, at 10:47AM, Rainer Müller  wrote:

> On 2016-11-03 17:49, Sterling Smith wrote:
>> The main question of procedure is: Should the main macports repo be
>> used for proposing review of work in progress via pull requests?  If
>> not, what is the proposed method?
> 
> I propose you put your changes on a branch, add the compare URL to a
> ticket or send an email to macports-dev.
> 
> In the case you referred to, this would be:
> 
> https://github.com/mkae/macports-ports/compare/master...mkae:qtcurve_upgrade-for-Qt5
> 
The downside (as I see it) of using the compare URL, as opposed to a full pull 
request, is that line by line comments are not available.

-Sterling

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 1:46 PM, Rainer Müller  wrote:
> 
> I think the proper way to do it on GitHub would be as follows:
> When the pull request author checked the box for "Allow modifications by
> maintainers" [1], you can force-push your changes to the pull request
> branch, replacing the original commits. Then you can merge the pull
> request from the GitHub web interface.

GitHub will also automatically close the PR as "merged" if you push the
PR branch's changes to master from a local client. It's quite nice.

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

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 11:59 AM, Mojca Miklavec  wrote:
> 
> We have recently experienced problems with pull requests showing up as
> rejected on the web interface rather than merged (while the changes
> were in fact accepted, possibly with some modifications).
> 
> I admit my sins. In one case I did a minor modification (squashed
> commits, removed the "Id" line, edited the commit message), while
> basically everything else stayed the same as the author submitted and
> everyone would have preferred if GitHub displayed "Merged" rather than
> the red rejected sign.

I think (don't quote me on this) that GitHub considers a PR "merged"
when the base branch is updated and has incorporated the changes from
the head branch. If a committer modifies their local branch before
merging, the base branch does not look like it has merged in the head
branch because the new content is in fact different.

(This makes sense, in a way. After all, if you had to change a PR branch
before merging it, did you really accept the PR?)

> We could have asked the author to keep fixing the branch forever, but
> at some point it's simply faster and easier if an experienced
> MacPorter just finishes the obvious rather than turning the users away
> due to some stupid mistakes. The users can fix the mistakes in the
> next PR.

To reduce excessive communication, it does seems like a good idea to ask
contributors to allow us to push changes to their PR branches. Those
modified branches should then merge as desired.

https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork

> In another case I (stupidly?) decided to add "Closes: #N" at the end
> of the commit message (I thought it would be useful to have a link to
> the original PR which is something that the committer cannot do anyway
> without knowing the number of PR in advance).

Why was that stupid? Did it cause a problem?

(Note that GitHub shows PR links on closing commits. Look just under the
commit message, next to "master":
https://github.com/macports/macports-infrastructure/commit/1e6b092)

> I probably also sinned by thinking of "playing safe" and using
> cherry-pick rather than "wrongly rebasing" and risking some undesired
> merge.

You cherry-picked instead of rebasing the PR branch onto master? That
shouldn't cause any problems, I think.

> Can someone provide some guidelines of DOs and DONTs when accepting
> (and modifying) pull requests? That should cover the cases that need:
> - squashing commits
> - minor edits of commit messages
> - other minor edits of the sources

My sense is that the only real rule is that you need to push
modifications before doing the merge. For most PRs, that would require
the contributor to enable the setting that I mentioned above.

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

Re: Pull Requests for Work in Progress (WIP)

[Rainer Müller]

On 2016-11-03 17:49, Sterling Smith wrote:
>  The main question of procedure is: Should the main macports repo be
> used for proposing review of work in progress via pull requests?  If
> not, what is the proposed method?

I propose you put your changes on a branch, add the compare URL to a
ticket or send an email to macports-dev.

In the case you referred to, this would be:

https://github.com/mkae/macports-ports/compare/master...mkae:qtcurve_upgrade-for-Qt5

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

Re: Properly merging pull requests

[Rainer Müller]

On 2016-11-03 16:59, Mojca Miklavec wrote:
> Hi,
> 
> We have recently experienced problems with pull requests showing up as
> rejected on the web interface rather than merged (while the changes
> were in fact accepted, possibly with some modifications).
> 
> I admit my sins. In one case I did a minor modification (squashed
> commits, removed the "Id" line, edited the commit message), while
> basically everything else stayed the same as the author submitted and
> everyone would have preferred if GitHub displayed "Merged" rather than
> the red rejected sign.
> 
> We could have asked the author to keep fixing the branch forever, but
> at some point it's simply faster and easier if an experienced
> MacPorter just finishes the obvious rather than turning the users away
> due to some stupid mistakes. The users can fix the mistakes in the
> next PR.
> 
> In another case I (stupidly?) decided to add "Closes: #N" at the end
> of the commit message (I thought it would be useful to have a link to
> the original PR which is something that the committer cannot do anyway
> without knowing the number of PR in advance). I probably also sinned
> by thinking of "playing safe" and using cherry-pick rather than
> "wrongly rebasing" and risking some undesired merge.

GitHub will already add an annotation right next to the branch name in
the commit view to show that this commit came from a pull request. As an
example, note "master (#2)" right below the commit message here:

https://github.com/macports/macports-ports/commit/ec150ad742e511cc38e5a0815c8b5805125d2aea

I think the proper way to do it on GitHub would be as follows:
When the pull request author checked the box for "Allow modifications by
maintainers" [1], you can force-push your changes to the pull request
branch, replacing the original commits. Then you can merge the pull
request from the GitHub web interface.

> Can someone provide some guidelines of DOs and DONTs when accepting
> (and modifying) pull requests? That should cover the cases that need:
> - squashing commits
> - minor edits of commit messages
> - other minor edits of the sources

If commits were made to address review comments, but these commits do
not follow our rules for commit messages, they need to be squashed or
edited. Otherwise, after the changes were brought to master with a
rebase, looking at these commit messages in the linear history would not
clearly show what they addressed.

Rainer

[1]
https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: Properly merging pull requests

[Lawrence Velázquez]

> On Nov 3, 2016, at 12:19 PM, Sterling Smith  wrote:
> 
> The user will not learn if you change it under his/her feet.  I think
> that you should make line by comments of changes that need to be made
> in the files tab of the pull request and ask the pull request
> submitter to make those changes.

While this is all fine in the abstract, in practice committers have
always felt free to improve contributors' patches before committing,
especially if said improvements are minor.

> Or you can make them yourself and push them to the branch of the pull
> request and ask the submitter if s/he is OK with them.

The contributor must first allow us to modify their PR branch:

https://help.github.com/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork

This seems very useful. Perhaps we should request that all contributors
do this when opening PRs.

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

Pull Requests for Work in Progress (WIP)

[Sterling Smith]

Devs,

This thread is meant to continue comments starting with 
https://github.com/macports/macports-ports/pull/7#issuecomment-258057083

The main question of procedure is: Should the main macports repo be used for 
proposing review of work in progress via pull requests?  If not, what is the 
proposed method?

-Sterling

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

Re: How to submit an updated portfile on new system?

[Lawrence Velázquez]

> On Nov 3, 2016, at 12:12 PM, Watson Ladd  wrote:
> 
> Dear all,
> A new version of Pari has come out, and I will update the portfile
> soon. However, I haven't found new git compatible workflow
> documentation anywhere. Should I still do the old-fashioned make a
> patch and submit in a ticket, or should I fork the repo, modify it,
> and submit a pull request?

Either is fine. We do still accept Trac patches and do not plan to stop
doing so.

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

Re: Properly merging pull requests

[Sterling Smith]

On Nov 3, 2016, at 8:59AM, Mojca Miklavec  wrote:

> Hi,
> 
> We have recently experienced problems with pull requests showing up as
> rejected on the web interface rather than merged (while the changes
> were in fact accepted, possibly with some modifications).
> 
> I admit my sins. In one case I did a minor modification (squashed
> commits, removed the "Id" line, edited the commit message), while
> basically everything else stayed the same as the author submitted and
> everyone would have preferred if GitHub displayed "Merged" rather than
> the red rejected sign.
> 
> We could have asked the author to keep fixing the branch forever, but
> at some point it's simply faster and easier if an experienced
> MacPorter just finishes the obvious rather than turning the users away
> due to some stupid mistakes. The users can fix the mistakes in the
> next PR.
The user will not learn if you change it under his/her feet.  I think that you 
should make line by comments of changes that need to be made in the files tab 
of the pull request and ask the pull request submitter to make those changes.  
Or you can make them yourself and push them to the branch of the pull request 
and ask the submitter if s/he is OK with them.  Either way, the submitter 
learns of the MacPorts Way, and will be less likely to make those mistakes in 
the future.  
> 
> In another case I (stupidly?) decided to add "Closes: #N" at the end
> of the commit message (I thought it would be useful to have a link to
> the original PR which is something that the committer cannot do anyway
> without knowing the number of PR in advance). I probably also sinned
> by thinking of "playing safe" and using cherry-pick rather than
> "wrongly rebasing" and risking some undesired merge.
> 
> Can someone provide some guidelines of DOs and DONTs when accepting
> (and modifying) pull requests? That should cover the cases that need:
> - squashing commits
> - minor edits of commit messages

When a committer is happy with the changes of the pull request, but not the 
commit messages, then they should request that the submitter make appropriate 
changes to the branch (with an interactive rebase), and force push those 
changes.  The branch will then be in a position to push the GitHub rebase 
button.
> 
> - other minor edits of the sources
See my comment above about pushing changes to the branch of the pull request 
and asking the submitter for their approval.
> 
> Thank you,
>Mojca

My two cents.

-Sterling


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

How to submit an updated portfile on new system?

[Watson Ladd]

Dear all,
A new version of Pari has come out, and I will update the portfile
soon. However, I haven't found new git compatible workflow
documentation anywhere. Should I still do the old-fashioned make a
patch and submit in a ticket, or should I fork the repo, modify it,
and submit a pull request?

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

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[Lawrence Velázquez]

> On Nov 3, 2016, at 8:01 AM, René J.V. Bertin  wrote:
> 
> On Thursday November 03 2016 12:42:40 Rainer Müller wrote:
> 
>> Overall, can we just stop this discussion, please? We settled to stay
>> with Trac and it is not going to change.
> 
> Really, all your decisions are always set in stone from the very
> moment you make them regardless of how things evolve?

This is not the first discussion we have had about possibly switching
bug trackers. All have generally concluded that, despite Trac's warts,
migrating is not worth it right now. At this point, we are kicking
a horse that is dead and buried and worm food, and it is wasting
everyone's time and energy. Enough.

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

Properly merging pull requests

[Mojca Miklavec]

Hi,

We have recently experienced problems with pull requests showing up as
rejected on the web interface rather than merged (while the changes
were in fact accepted, possibly with some modifications).

I admit my sins. In one case I did a minor modification (squashed
commits, removed the "Id" line, edited the commit message), while
basically everything else stayed the same as the author submitted and
everyone would have preferred if GitHub displayed "Merged" rather than
the red rejected sign.

We could have asked the author to keep fixing the branch forever, but
at some point it's simply faster and easier if an experienced
MacPorter just finishes the obvious rather than turning the users away
due to some stupid mistakes. The users can fix the mistakes in the
next PR.

In another case I (stupidly?) decided to add "Closes: #N" at the end
of the commit message (I thought it would be useful to have a link to
the original PR which is something that the committer cannot do anyway
without knowing the number of PR in advance). I probably also sinned
by thinking of "playing safe" and using cherry-pick rather than
"wrongly rebasing" and risking some undesired merge.

Can someone provide some guidelines of DOs and DONTs when accepting
(and modifying) pull requests? That should cover the cases that need:
- squashing commits
- minor edits of commit messages
- other minor edits of the sources

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

Re: Working with Git

[Lawrence Velázquez]

> On Nov 2, 2016, at 11:24 PM, Ryan Schmidt  wrote:
> 
> Yes, there are "command line instructions" on the web site, but they
> are different from the commands you gave below, which are again
> different from other commands suggested in previous threads, so it is
> difficult to know which set of instructions to follow.

Obviously I think you should follow mine ;)

The GitHub instructions assume that you're okay with nonlinear history
(they create merge commits), so we can't really use them. But I found
them useful for developing my instructions.

> Thanks, that worked, up until the "git push origin master" command,
> which asked me to authenticate, and supplying my username and password
> was unsuccessful:
> 
> $ git push origin master
> Username for 'https://github.com': ryandesign
> Password for 'https://ryandes...@github.com': 
> remote: Invalid username or password.
> fatal: Authentication failed for 
> 'https://github.com/macports/macports-ports.git/'

That's curious. What does "git remote -v" print?

> Now I still seem to have this branch in my local git repo:
> 
> $ git branch
>  l2dy-curl-ca-bundle-update
> * master
> 
> Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"?

Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
suggested because these instructions are designed so that you can always
fast-forward merge the PR branch into master. If "git branch -d" fails,
something is not right, and you have to go back and figure out what.

One small addendum: Before "git push origin master", you should run "git
pull --rebase" to get any new commits that were pushed by other
committers.

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

branch -d and pushing (Was: Working with Git)

[Jeremy Lavergne]

Ensure you pull or fetch your merged changes otherwise you'll never be
allowed to delete the branch. So if on branch X you have GitHub merge
branch Y, you cannot delete Y until you fetch X.

If we get lots of branches, you can prune remote tracking easily:
git fetch -p

(remember:
 - local tracking "master"
 - remote tracking "origin/master")

On 11/03/2016 11:36 AM, Lawrence Vel�zquez wrote:
> Yeah, you can delete it. You should NOT use "git branch -D" as Sterling
> suggested because these instructions are designed so that you can always
> fast-forward merge the PR branch into master. If "git branch -d" fails,
> something is not right, and you have to go back and figure out what.
> 
> One small addendum: Before "git push origin master", you should run "git
> pull --rebase" to get any new commits that were pushed by other
> committers.

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

Re: [MacPorts] #1: foo @1.2: fails to build from source

[Rainer Müller]

On 2016-11-03 15:01, MacPorts wrote:
> #1: foo @1.2: fails to build from source
> -+--
>   Reporter:  anonymous   |  Owner:  somebody
>   Type:  defect  | Status:  new
>   Priority:  blocker |  Milestone:
>  Component:  component1  |Version:
> Resolution:  |   Keywords:  haspatch
>   Port:  foo |
> -+--

Sorry, this notification was from my local test setup of Trac and should
not have gone to the real mailing list.

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

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[René J . V . Bertin]

On Thursday November 03 2016 12:42:40 Rainer Müller wrote:

> What do you want to discuss then? A bug tracker is for tracking, we will
> not throw everything away that was reported.

Not converting isn't the same as throwing away.

> Overall, can we just stop this discussion, please? We settled to stay
> with Trac and it is not going to change.

Really, all your decisions are always set in stone from the very moment you 
make them regardless of how things evolve?
You'd love it here in France, you could even participate in popular riots that 
arise when governments dare to investigate change to something the populace 
considers something they've earned for all posterity.

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

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[Rainer Müller]

On 2016-11-03 12:38, René J.V. Bertin wrote:
> Conversion of existing tickets would be nifty, but I don't think it's 
> something I'd miss myself.

What do you want to discuss then? A bug tracker is for tracking, we will
not throw everything away that was reported.

Overall, can we just stop this discussion, please? We settled to stay
with Trac and it is not going to change.

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

Re: Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[René J . V . Bertin]

On Thursday November 03 2016 11:30:50 Clemens Lang wrote:

> We also looked into other bugtrackers, and there was no clear benefit over 
> Trac
> to justify switching.

It may just be an impression, but bugzilla comes across as more feature-rich to 
me.

Conversion of existing tickets would be nifty, but I don't think it's something 
I'd miss myself.
(FWIW, Bugzilla has a programmatic interface for use by remote clients; this 
could be used to add references to tickets on a previous tracker, in case a 
migration is ever done.)

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

Using a different bugtracker [Was: Re: Poll: should Trac send email notifications when adding or replacing an attachment?]

[Clemens Lang]

Hi,

- On 3 Nov, 2016, at 10:58, René J.V. Bertin rjvber...@gmail.com wrote:

> Not to open another can of worms, but just how married are we to trac? Of 
> course
> it's never evident to migrate a web service, but has it never been considered 
> to
> investigate other popular bug trackers (e.g. bugzilla) and possibly switch 
> over
> by redirecting all new ticket requests to the new service?
> Github also has an issue tracker, for instance. I'm not familiar enough with 
> its
> advanced features. I couldn't say if it does attachments, but it does have 1
> rare feature I like very much: replying by email.

We actually investigated other solutions for the GitHub move. Some of us would
have preferred using the GitHub issue tracker, and we even had a conversion of
our tickets to GitHub already, but the longer we looked at it, the more problems
and limitations we actually found, which is why we ended up staying with Trac.

We also looked into other bugtrackers, and there was no clear benefit over Trac
to justify switching.

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

Re: Poll: should Trac send email notifications when adding or replacing an attachment?

[René J . V . Bertin]

Mojca Miklavec wrote:


>> 1- Do you agree there is no need for (this many) notifications concerning
>> changes to attachments (= you never missed it)?
> 
> No. I have always been annoyed by the fact that some users (me
> included) uploaded an attachment and then I had to tell everyone
> explicitly that a new attachment was there, and some users (me
> included) forgot.

The only thing I've been mildly annoyed with is that you have to browse back to 
the ticket page and then post a new comment. Other bug tracker allow you to 
attach a comment to a new attachment with only some scrolling down the page 
required.


> attachment, the submitter fixes the problems, but then nobody is aware
> that those things have been changed.

But you'll notice the next time you think of looking at it; I don't think 
there's really a problem here if it concerns something either of the parties 
considers important/urgent.

>> 3- Do you agree that ideally this should be a per-user setting?
> 
> This cannot hurt, but as you said this is not up to us to implement
> and you should ask upstream.

That was the idea - if there's enough demand. A random (from upstream 
perspective) trac user filing requests about features missing on some trac 
installation might well have adverse effects so I think we need to be careful 
with that.

> The only "problem" with per-user setting is that:
...
> ready to be committed" (or anything else). And then people might end
> up with three notifications (attachment deleted, attachment added, the
> additional comment by the user) or no notification at all.

Well, you can't have everything, but I'd assume that if notifications are on by 
default, those users who bother to turn them off will know they'll have to 
monitor for silent changes themselves.
Either way, I consider it bad practice to change an attachment (or add a new 
one) without a word of explanation except if it concerns only minor changes. 
Trac (also) doesn't have a diff feature for attachments, so without explanation 
you're leaving it up to your "audience" to figure out what just changed.
So yes, I indeed get 3 emails most of the time when I change an attachment, 2 
of 
which are to be trashed immediately.

> PS: Isn't that question more suitable for the development mailing
> list? Regular users that don't maintain any port might open a ticket

Yes and no (I did consider cross-posting). I'd assume that most if not all 
developers are also on the users list. Of course the direction this discussion 
is taking has no place on the users list so I'm redirecting. But originally I 
wanted to reach the broadest audience to have the best chance to know what the 
entire community thinks. But above all, it's the people who open a ticket who 
are the most likely to be unhappy with the new set-up, because they really 
don't 
need all those notifications. It's been happening several times now that I made 
a 
number of changes to one of my tickets (that never drew much feedback) and 
moments later had a wow-moment when I saw the number of notifications in my 
inbox. That got old VERY quickly when I realised all those emails just 
confirmed 
things I knew I had done not even minutes before.
The problem here is also that it seems risky to filter out these notifications 
automatically, but I haven't looked into that yet. Would prefer not to, of 
course.

Maybe I would find attachment notifications less annoying for the tickets I'm 
following but didn't author. IOW, maybe trac could avoid sending the 
notification 
to the person making the attachment change. I'm rarely really interested in a 
copy of my own prose either, in fact.
Either way, there is really no need for 2 notifications when you replace an 
attachment. In fact, I find that all the more irksome because each deletion 
notification is a reminder I can't *delete* attachments...


Clemens wrote:
> 
> Option 4: I'm glad we now have notifications for attachments. It used to be
> quite annoying that you wouldn't notice if somebody attached a patch to a
> ticket without leaving a comment.

That's a no to question 1...

> They are, however, not worded to avoid bias against the status quo.


Of course they aren't. I'm not sure they could have been, but that's why I 
pointed out the fact. The ultimate goal was mostly to get people to reply who 
would otherwise have dismissed this as another one of my crazy ideas.

>> (and I agree this isn't for us to fix though evidently someone could try and
>> submit a patch).
> 
> That someone could be you! That would be very welcome!

I guess you know me well enough that if this were written in a language I knew 
and was set up to work with I'd already have done so before even opening a 
ticket. As it is someone would have to provide guidance, and that would 
probably 
cost more time than figuring out the patch.

Not to open another can of worms, but just how married are we to trac? Of 
course 
it's never evident to migrate a web service, but has it never been 

Re: Removing "$Id$" lines

[Mojca Miklavec]

On 2 November 2016 at 05:07, David Evans wrote:
>
> Another reason for not canceling such a build would be to generate a record 
> of how many ports and which ones are
> currently broken.  I suspect there are a number that never get reported 
> because they are old or obscure or just not used
> very much.

A reason for not doing this (= not not cancelling) might be a total
crash of our build infrastructure that won't serve anyone anyway.

We should at least:

- switch to PostgreSQL

- implement "successcache", so that ports with existing binary
archives won't even be added to the portbuilder

- implement a way to trigger rebuild of all ports without having to
create artificial commits (I can imagine an additional variable on the
buildbot interface or a "meta port name" like the port variable being
set to "list:all" or "category:python" or "dir:perl" or
"dependon:libcurl")

- (useful, but irrelevant for this particular case) implement merging
of commits to a single job on portwatcher

- test this on a single build slave, ideally on one that's least used
(perhaps on 10.8; but certainly not on the ultra slow 10.5 PPC)

and only scale things once we think we are ready for a mass build.
Mass builds were already problematic on the old infrastructure, but
the new infrastructure is even less efficient and way more resource
hungry.

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

Re: Working with Git

[Sterling Smith]

> 
> Now I still seem to have this branch in my local git repo:
> 
> $ git branch
>  l2dy-curl-ca-bundle-update
> * master
> 
> Can I delete it? With, I presume, "git branch -d l2dy-curl-ca-bundle-update"?

Yes, you can delete it with the command you show (unless it complains that it 
is not merged into master, in which case you might need -D instead of -d).

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