incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: GitHub workflows?
Date Mon, 06 Mar 2017 11:02:45 GMT
On Mon, 06 Mar 2017 10:29:54 +0100, "Raphael Bircher" <> 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'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

A pull request is also fairly transient/short-lived - it would not
be too big deal if say a year later disappears, as you would
still find a thread per pull request on 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message