Hello,

To help address the backlog of PRs on the aports repository I'm suggesting more automation to make things easier all around.

 1. https://probot.github.io/apps/invite-contributors/ <https://probot.github.io/apps/invite-contributors/>
	Configuration: .github/invite-contributors.yml
		isOutside: true

 2. https://github.com/zalando/zappr <https://github.com/zalando/zappr>
	Configuration: .zappr.yaml
		approvals:
		  minimum: 3
		  from:
		    collaborators: true
		    orgs:
		      - alpinelinux
		  pattern: "^(:\\+1:|👍)$"
		  veto:
		    pattern: "^(:\\-1:|👎)$"

 3. https://probot.github.io/apps/dep/ <https://probot.github.io/apps/dep/>

 4. https://probot.github.io/apps/wip/ <https://probot.github.io/apps/wip/>

 5. https://zapier.com/apps/github/integrations/mattermost/13208/post-new-github <https://zapier.com/apps/github/integrations/mattermost/13208/post-new-github>

Also, since the master branch is being managed external to GitHub, I'd suggest protecting that branch and making a new one (e.g. github) that can be used to quickly merge the PRs to. This will allow simple use of the GitHub web interface to merge PRs using squash / rebase / merge commits to that branch from which you can move those commits to master in your external repository. You could do this with patch sets or setup github as a remote or some other preferred way.

The idea behind this workflow is that contributors get invited after their first contribution and from that point on can help with merging new PRs into the github branch but would not be able to change the master branch (as that's hosted external to GitHub and protected). This way you can get a pool of contributors helping out with simple changes and give the developers a single source to find the changes that have been community approved.

Thoughts?

> On Jul 26, 2018, at 4:51 PM, Natanael Copa <ncopa@alpinelinux.org> wrote:
> 
> On Mon, 16 Jul 2018 05:08:56 -0400
> Chris Ely <tcely@icloud.com <tcely@icloud.com>> wrote:
> 
>> 3. https://probot.github.io/apps/dep/ <https://probot.github.io/apps/dep/>
>> <https://probot.github.io/apps/dep/ <https://probot.github.io/apps/dep/>>
> 
> We sort of have dependencies in our redmine tracker, which is our
> official bug tracker.

This is for dependencies between PRs. An example, I currently have testing/dnsdist that depends on testing/fstrm. That dep bot would prevent anyone from merging testing/dnsdist before testing/fstrm.

On Mon, 16 Jul 2018 05:08:56 -0400
Chris Ely <tcely@icloud.com> wrote:

> Hello,
> 
> To help address the backlog of PRs on the aports repository I'm
> suggesting more automation to make things easier all around.

I would love more automation.

>  1. https://probot.github.io/apps/invite-contributors/
> <https://probot.github.io/apps/invite-contributors/>
> Configuration: .github/invite-contributors.yml isOutside: true
> 
>  2. https://github.com/zalando/zappr
> <https://github.com/zalando/zappr> Configuration: .zappr.yaml
> 		approvals:
> 		  minimum: 3
> 		  from:
> 		    collaborators: true
> 		    orgs:
> 		      - alpinelinux
> 		  pattern: "^(:\\+1:|*)$"
> 		  veto:
> 		    pattern: "^(:\\-1:|*)$"
> 

I like those.

>  3. https://probot.github.io/apps/dep/
> <https://probot.github.io/apps/dep/>

We sort of have dependencies in our redmine tracker, which is our
official bug tracker.

>  4. https://probot.github.io/apps/wip/
> <https://probot.github.io/apps/wip/>

This looks good.

>  5.
> https://zapier.com/apps/github/integrations/mattermost/13208/post-new-github
> <https://zapier.com/apps/github/integrations/mattermost/13208/post-new-github>

we don't use mattermost, but I wouldn't mind connect it as long someone
else does the job and maintains it.
 
> Also, since the master branch is being managed external to GitHub,
> I'd suggest protecting that branch and making a new one (e.g. github)
> that can be used to quickly merge the PRs to. This will allow simple
> use of the GitHub web interface to merge PRs using squash / rebase /
> merge commits to that branch from which you can move those commits to
> master in your external repository. You could do this with patch sets
> or setup github as a remote or some other preferred way.
> 
> The idea behind this workflow is that contributors get invited after
> their first contribution and from that point on can help with merging
> new PRs into the github branch but would not be able to change the
> master branch (as that's hosted external to GitHub and protected).
> This way you can get a pool of contributors helping out with simple
> changes and give the developers a single source to find the changes
> that have been community approved.
> 
> Thoughts?

I am sceptic to have a parallel branch on github only since I am afraid
it will diverge from master branch.


That said, if collaborators can rebase it, then it would be great
to simply do a single pull request.

Other worry I have is that I don't want make it a hard requirement to
have github account to be able to contribute.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---