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.org/thread/72ORWNKPA6AOFJHLX2DAIMWDBG5NA4XH/ > > >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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
