Hi,
sorry for the long mail..the tl;dr is that I would like to propose we use github pull-requests as the preferred way of submitting patches instead of sending e-mail attachments to the list. You might already have noticed a pull-request notification arrived to the list: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.o...
I'm aware of the reservations people have against github being non-free, but in my opinon it's still worth it.
The goals are: - use PRs to track what needs review and who is working on the review. Right now it's not clear if someone adding a comment to a patch means the person will do the whole review or just has a single comment. And it's not easy to see what are the pending reviews..patchwork helps quite a bit, but it's just not polished and easy to use. (Also, it runs under Simo's desk :-)) The core developers should be added as 'collaborators' to be able to edit tags and close PRs. For notifications, I think collaborators already receive notifications automatically. Others can just 'watch' the sssd repo on github. Opening a pull request triggers a mail notification to the sssd-devel list. The e-mail notifications plug to the fedmsg bus which plugs to github and are just one-way, sorry. To reply to a PR, either the github web UI can be used or, if you subscribe to github directly, it's possible to reply to notifications that originate at github.
- plug in hosted CentOS CI to run our pre-push CI tests automatically and not worry about forgetting to run CI for some patchset or sending the wrong patchset to CI. We will still run our internal CI post-push or could even do pre-push with a user whitelist. We already have the CI accounts at centos.org set up, we 'just' need to plug the CI to github.
- use the github diff viewer to comment on code in pull requests inline
- use the available tools that have been developed around github (such as hub) to be able to easily apply patches from a PR (example: hub am https://github.com/SSSD/sssd/pull/5)
- make it easier for non-core developers to submit patches. Many developers are more familiar with the github workflow than submitting patches and have accounts on github already. Submitting a trivial patch would no longer require subscribing to the list.
Explicit non-goals are: - we should not move the repo to github. I think keeping the code at fedorahosted.org gives us more control in case the same thing that happened to sourceforge happens to github. The mailing list notifications give us history in case we ever move away from github for one reason or another.
- we should not merge the pull requests. While we can't disable the 'merge' button on the PR page, even merging the PR wouldn't have a permanent effect because the code is kept on fedorahosted and force-pushed to the github mirror
- we should not use github issues. As a matter of fact, I disabled the issues on github. We should IMO add a note to README.md telling people to file bugs at fedorahosted. The primary reason is that we have a ton of tooling around Trac already.
If some developers have reservations about github, either technical or philosophical, the mailing list is here to stay. But I really think the benefits outweight the dangers of github.
Does anyone explicitly disagree with SSSD using github pull requests?
On (19/08/16 11:49), Jakub Hrozek wrote:
Hi,
sorry for the long mail..the tl;dr is that I would like to propose we use github pull-requests as the preferred way of submitting patches instead of sending e-mail attachments to the list. You might already have noticed a pull-request notification arrived to the list: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.o...
I'm aware of the reservations people have against github being non-free, but in my opinon it's still worth it.
The goals are:
use PRs to track what needs review and who is working on the review. Right now it's not clear if someone adding a comment to a patch means the person will do the whole review or just has a single comment. And it's not easy to see what are the pending reviews..patchwork helps quite a bit, but it's just not polished and easy to use. (Also, it runs under Simo's desk :-)) The core developers should be added as 'collaborators' to be able to edit tags and close PRs. For notifications, I think collaborators already receive notifications automatically. Others can just 'watch' the sssd repo on github. Opening a pull request triggers a mail notification to the sssd-devel list. The e-mail notifications plug to the fedmsg bus which plugs to github and are just one-way, sorry. To reply to a PR, either the github web UI can be used or, if you subscribe to github directly, it's possible to reply to notifications that originate at github.
plug in hosted CentOS CI to run our pre-push CI tests automatically and not worry about forgetting to run CI for some patchset or sending the wrong patchset to CI. We will still run our internal CI post-push or could even do pre-push with a user whitelist. We already have the CI accounts at centos.org set up, we 'just' need to plug the CI to github.
use the github diff viewer to comment on code in pull requests inline
use the available tools that have been developed around github (such as hub) to be able to easily apply patches from a PR (example: hub am https://github.com/SSSD/sssd/pull/5)
make it easier for non-core developers to submit patches. Many developers are more familiar with the github workflow than submitting patches and have accounts on github already. Submitting a trivial patch would no longer require subscribing to the list.
Explicit non-goals are:
we should not move the repo to github. I think keeping the code at fedorahosted.org gives us more control in case the same thing that happened to sourceforge happens to github. The mailing list notifications give us history in case we ever move away from github for one reason or another.
we should not merge the pull requests. While we can't disable the 'merge' button on the PR page, even merging the PR wouldn't have a permanent effect because the code is kept on fedorahosted and force-pushed to the github mirror
we should not use github issues. As a matter of fact, I disabled the issues on github. We should IMO add a note to README.md telling people to file bugs at fedorahosted. The primary reason is that we have a ton of tooling around Trac already.
If some developers have reservations about github, either technical or philosophical, the mailing list is here to stay. But I really think the benefits outweight the dangers of github.
Does anyone explicitly disagree with SSSD using github pull requests?
I would prefer pagure.io because I can use the same authentication/authorisation mechanism for trac, pagure, copr ... Or you can persuade github to use Fedora Open ID :-)
IMHO, it still worth to have notifications from github for ocassional contributores.
LS
On Fri, Aug 19, 2016 at 12:54:25PM +0200, Lukas Slebodnik wrote:
On (19/08/16 11:49), Jakub Hrozek wrote:
Hi,
sorry for the long mail..the tl;dr is that I would like to propose we use github pull-requests as the preferred way of submitting patches instead of sending e-mail attachments to the list. You might already have noticed a pull-request notification arrived to the list: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.o...
I'm aware of the reservations people have against github being non-free, but in my opinon it's still worth it.
The goals are:
use PRs to track what needs review and who is working on the review. Right now it's not clear if someone adding a comment to a patch means the person will do the whole review or just has a single comment. And it's not easy to see what are the pending reviews..patchwork helps quite a bit, but it's just not polished and easy to use. (Also, it runs under Simo's desk :-)) The core developers should be added as 'collaborators' to be able to edit tags and close PRs. For notifications, I think collaborators already receive notifications automatically. Others can just 'watch' the sssd repo on github. Opening a pull request triggers a mail notification to the sssd-devel list. The e-mail notifications plug to the fedmsg bus which plugs to github and are just one-way, sorry. To reply to a PR, either the github web UI can be used or, if you subscribe to github directly, it's possible to reply to notifications that originate at github.
plug in hosted CentOS CI to run our pre-push CI tests automatically and not worry about forgetting to run CI for some patchset or sending the wrong patchset to CI. We will still run our internal CI post-push or could even do pre-push with a user whitelist. We already have the CI accounts at centos.org set up, we 'just' need to plug the CI to github.
use the github diff viewer to comment on code in pull requests inline
use the available tools that have been developed around github (such as hub) to be able to easily apply patches from a PR (example: hub am https://github.com/SSSD/sssd/pull/5)
make it easier for non-core developers to submit patches. Many developers are more familiar with the github workflow than submitting patches and have accounts on github already. Submitting a trivial patch would no longer require subscribing to the list.
Explicit non-goals are:
we should not move the repo to github. I think keeping the code at fedorahosted.org gives us more control in case the same thing that happened to sourceforge happens to github. The mailing list notifications give us history in case we ever move away from github for one reason or another.
we should not merge the pull requests. While we can't disable the 'merge' button on the PR page, even merging the PR wouldn't have a permanent effect because the code is kept on fedorahosted and force-pushed to the github mirror
we should not use github issues. As a matter of fact, I disabled the issues on github. We should IMO add a note to README.md telling people to file bugs at fedorahosted. The primary reason is that we have a ton of tooling around Trac already.
If some developers have reservations about github, either technical or philosophical, the mailing list is here to stay. But I really think the benefits outweight the dangers of github.
Does anyone explicitly disagree with SSSD using github pull requests?
I would prefer pagure.io because I can use the same authentication/authorisation mechanism for trac, pagure, copr ...
Feel free to try out and set up pagure with some hosted CI and notifications. I've never tried pagure myself, just looked at other projects and it seems kindof OK, just a bit bare-bones.
Or you can persuade github to use Fedora Open ID :-)
IMHO, it still worth to have notifications from github for ocassional contributores.
Well, the other effect is that github just gets more views, so anyone could see the activity and the patch review discussions.
sssd-devel@lists.fedorahosted.org