Re: streamline github dev process

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

Re: streamline github dev process

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

Re: streamline github dev process

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

Re: streamline github dev process

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

Re: streamline github dev process

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

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

Re: streamline github dev process

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

Re: streamline github dev process

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

Re: streamline github dev process

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”?

Re: streamline github dev process

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

Re: streamline github dev process

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

Re: streamline github dev process

> 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

Re: streamline github dev process

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

Re: streamline github dev process

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

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

Re: streamline github dev process

You can achieve that nicely by either editing the revert commit after-the-fact (git commit --amend) or you can actually ask revert to not auto-commit (git revert -n). This way you can make further necessary edits while keeping to one solid revert commit. On 05/30/2017 08:34 PM, Helmut K. C.

Re: streamline github dev process

On 2017-05-30 20:25, Sterling Smith wrote: >> 1) git revert xyz >> 2) makes changes and sets v1.2 >> 3) commit >> 4) git push >> >> The last 4 lines were local, so it is ok to have the version changed >> temporarily back to pre-1.1 in step 1 (the git revert). > This is only true if the bad

Re: streamline github dev process

On May 30, 2017, at 8:03PM, Helmut K. C. Tessarek wrote: > On 2017-05-30 17:36, Ryan Schmidt wrote: >> Wouldn't requiring a certain number of reviews make things more >> difficult than they are now, where we don't require reviews? > > Well, this depends. I haven't

Re: streamline github dev process

On May 30, 2017, at 16:36, Ryan Schmidt wrote: > On May 30, 2017, at 13:23, Helmut K. C. Tessarek wrote: > >> Maybe you could allow maintainers to review and approve other pull requests. >> >> This is git. It's very easy to revert a broken commit. Since almost all >> of these commits are not

Re: streamline github dev process

> On May 30, 2017, at 13:23, Helmut K. C. Tessarek wrote: > > Hello, > > Maybe we can streamline the github process a bit. Sure. Those familiar with GitHub should chime in. I'm not familiar so I won't answer most of your questions, except: > As Mojca mentioned >

streamline github dev process

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) Also you could block merges until 1 or 2 people have reviewed and