Re: streamline github dev process

2017-05-31 Thread Mojca Miklavec
On 1 June 2017 at 03:43, Helmut K. C. Tessarek wrote: > On 2017-05-31 20:42, Joshua Root wrote: >> That's an unavoidable side effect of rebasing (or squashing) -- it's no >> longer the same commit that you signed. > Right, this is why one usually does a merge with --no-ff. Thus my commit > is intac

Re: streamline github dev process

2017-05-31 Thread Helmut K. C. Tessarek
On 2017-05-31 20:42, Joshua Root wrote: > That's an unavoidable side effect of rebasing (or squashing) -- it's no > longer the same commit that you signed. Right, this is why one usually does a merge with --no-ff. Thus my commit is intact and the merge commiter gets their own commit. Problem solved

Re: streamline github dev process

2017-05-31 Thread Joshua Root
On 2017-6-1 08:19 , Helmut K. C. Tessarek wrote: I would like that the buildbots are triggered for a PR. only when my PR is commited, I can see, if the build actually works. it should be the other way around: I should be able to verify that the PR really does what it is intended to do (since we d

Re: streamline github dev process

2017-05-31 Thread Joshua Root
On 2017-6-1 08:18 , Helmut K. C. Tessarek wrote: Also, I have noticed that whenever you guys commit my PRs, my gpg signature is gone. I believe we should find a proper way to handle this. That's an unavoidable side effect of rebasing (or squashing) -- it's no longer the same commit that you si

Re: streamline github dev process

2017-05-31 Thread Helmut K. C. Tessarek
On 2017-05-31 13:11, Daniel J. Luke wrote: > One other (more radical) idea would be to split the ports tree into > two - one where changes are auto-committed if they pass certain tests > (lint ok, buildbot ok, test suite ok), and the 'curated' tree where > someone has done a review and merged from

Re: streamline github dev process

2017-05-31 Thread Helmut K. C. Tessarek
On 2017-05-31 11:55, Zero King wrote: > We disabled "squash and merge" on GitHub's web interface so we have to > do `git merge --squash` locally to complete the typical workflow, much > harder than clicking a button twice. In certain circumstances (some ppl love to spread out one change into sever

Re: streamline github dev process

2017-05-31 Thread Daniel J. Luke
On May 31, 2017, at 4:40 AM, Mojca Miklavec wrote: > What I believe could help a bit would be to get some > "mentors" assigned to new maintainers. Then those mentors would be > kind of obliged to review submissions from them and keep track of > their progress and vouch for commit rights once appli

Re: streamline github dev process

2017-05-31 Thread Rainer Müller
On 2017-05-31 18:25, Zero King wrote: > On Wed, May 31, 2017 at 06:09:44PM +0200, Rainer Müller wrote: >> On 2017-05-31 16:38, Craig Treleaven wrote: >>> 0) The wiki currently includes the following: >>> >>> https://trac.macports.org/wiki/WorkingWithGit >>> >>> I presume we would adapt your Gist to

Re: streamline github dev process

2017-05-31 Thread Zero King
On Wed, May 31, 2017 at 06:09:44PM +0200, Rainer Müller wrote: On 2017-05-31 16:38, Craig Treleaven wrote: 0) The wiki currently includes the following: https://trac.macports.org/wiki/WorkingWithGit I presume we would adapt your Gist to become something like “WorkingWithGitHubPullRequests”? I

Re: streamline github dev process

2017-05-31 Thread Rainer Müller
On 2017-05-31 16:38, Craig Treleaven wrote: > 0) The wiki currently includes the following: > > https://trac.macports.org/wiki/WorkingWithGit > > I presume we would adapt your Gist to become something like > “WorkingWithGitHubPullRequests”? I think the current page would be > unweildy if the gis

Re: streamline github dev process

2017-05-31 Thread Zero King
On Wed, May 31, 2017 at 10:38:45AM -0400, Craig Treleaven wrote: On May 31, 2017, at 8:52 AM, Zero King wrote: I wrote a Gist about making changes to PRs, feedback via email is welcome. https://gist.github.com/l2dy/7da9621954ebcf1a19869f391662a41e I currently know very little about the GitHub

Re: streamline github dev process

2017-05-31 Thread Craig Treleaven
> On May 31, 2017, at 8:52 AM, Zero King wrote: > > On Wed, May 31, 2017 at 10:40:07AM +0200, Mojca Miklavec wrote: >> The new bot could solve some of those problems, but it's still a pity >> that maintainers cannot have slightly higher permissions set. > > What kind of slightly higher permissio

Re: streamline github dev process

2017-05-31 Thread Zero King
On Wed, May 31, 2017 at 10:40:07AM +0200, Mojca Miklavec wrote: The new bot could solve some of those problems, but it's still a pity that maintainers cannot have slightly higher permissions set. What kind of slightly higher permissions? I can make the bot auto-merge PRs approved by all related

Re: Buildbot emails

2017-05-31 Thread Mojca Miklavec
Dear Ryan (& Rainer/Clemens), The emails are now reaching the mailing list since May 28th, but they still don't end up in my inbox for the ports I maintain. Could you please look into that as well? Thank you, Mojca On 25 May 2017 at 13:35, Mojca Miklavec wrote: > Dear Ryan, > > In case you

Re: streamline github dev process

2017-05-31 Thread Rainer Müller
On 2017-05-31 10:40, Mojca Miklavec wrote: > On 30 May 2017 at 20:23, Helmut K. C. Tessarek wrote: >> Maybe you could allow maintainers to review and approve other pull requests. > > This would be ideal, but I don't know if there is any way to allow > that. This is again a question for the GitHub

Re: streamline github dev process

2017-05-31 Thread Mojca Miklavec
On 30 May 2017 at 20:23, Helmut K. C. Tessarek wrote: > Hello, > > Maybe we can streamline the github process a bit. As Mojca mentioned > earlier, the macports project is heavily understaffed. > > Is there a way to allow maintainers to set labels? (e.g. the > 'maintainer' or 'update' label) This i