On Mon, 06 Mar 2017 10:29:54 +0100, "Raphael Bircher" <rbircherapa...@gmail.com> wrote: > As long as all goes to the list, it's probably ok, but I would prefer ASF > Tools over third party tools. Thy are under the Foundation control. Even > GH is really strong at the moment, you don't know the future of the tools > there. If you use tired party tools it's every time a chance of data loss.
Agreed on not relying too heavily on the third-party tools - we have seen many of these may gradually degrade/fail or change business models. Discussions on GH pull requests is common in several projects, which should then be set up to mirror these to dev@ through the ASF GitHub bot you are not forced to use GH to contribute and it goes into the list archive. Pull Request mMerging happens using normal git commands and pushed back to apache.org's git - GitHub recognizes the commit (you can also say "This closes #15" in the commit message in case you don't do a normal merge) . Using GitHub issues will in theory work the same email wise (as is done for the Ponymail podling), but it is a bit more tricky because of lack of admin control for normal committers, e.g. to assign issues or labels. (As we don't want to give repository git commit directly at GitHub). It is possible to work around this with emails to the bot, but it gets cumbersome. A second option perhaps would be a secondary empty git repository? I think generally GitHub Pull Requests is good - it is a very structured way to converse about a code change that still works well on email, and a very welcoming way for third-party developers to get started contributing. A pull request is also fairly transient/short-lived - it would not be too big deal if say a year later github.com disappears, as you would still find a thread per pull request on list.apache.org and the commits in the git log - although perhaps not as beautiful as the GH rendering :-) Using GitHub issues is a bit different - as that is part of the planning and management of the project, which is a (P)PMC matter. For one you would force the PMC/committers to use a third-party tool; which some may be reluctant too for personal reasons, or even have institutional or national firewall issues with. Secondly keeping track of what is done or not should remain accessible for longer-term, e.g. to see what was part of a release a year ago. That's another reason to be more sceptical about using a third-party issue tracker (without a contractual binding). -- Stian Soiland-Reyes The University of Manchester http://www.esciencelab.org.uk/ http://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
