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.fedorahoste...
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?