Hi John,
thanks for sharing your point of view on this matter.
I tend to agree with Kai Kreuzer and, in particular, Jens Reimann regarding his preference for either being able to consistently use GitHub (for
code, PRs and issues) or not using GitHub at all. Kai K. has pointed out that Bugzilla is actually the tool contributors (and users and committers) have to learn in addition to GitHub. I could not agree more with him and from practice I can tell that if a
user is about to turn into a contributor by providing his first PR I would rather not scare him off by forcing him to create a Bugzilla issue in addition to simply using GitHub’s super easy to use PR/issue system. In the projects that I am working on, linking
to other eclipse projects’ issues was not important (so far) and even if it were, we could still link using a full URL instead of just an issue number.
So, I second Jens opinion: if we can use GitHub for hosting a project’s source code and PRs we should also be able to use GitHub issues. This is
what I would prefer from a user experience standpoint. Otherwise, if the eclipse foundation thinks that it is more important to only use vendor neutral infrastructure then we should refrain from using GitHub at all, which I would deeply regret since it really
makes it easy to get in touch with users and (potential) contributors.
Regards,
Kai Hudalla
From: iot-pmc-bounces@xxxxxxxxxxx [mailto:iot-pmc-bounces@xxxxxxxxxxx]
On Behalf Of John Arthorne
Sent: Thursday, June 18, 2015 3:55 AM
To: iot-pmc@xxxxxxxxxxx
Subject: Re: [iot-pmc] GitHub Issues for Eclipse projects
Hi all,
I am an Eclipse Committer Rep in the Eclipse Board of Directors, and I was asked to comment on this. I don't speak for the whole board or even all the committer reps, but I will give you my thoughts on this based on discussions help in past Board meetings
and from speaking with other committers.
I am completely sympathetic to developers wanting to use GitHub Issues instead of Bugzilla. It is super simple to use, integrates well with the pull request model, and is easily searchable.
One of the problems raised is that of course GitHub Issues is a proprietary tool. Should the company go away, change its terms of use, start charging for the feature, etc, it would be disruptive to the Eclipse community. It may be hard to imagine this happening,
but think for example of the disaster of SourceForge in recent years [1]. However, GitHub Issues are not very complex, and are reachable via an API, so it is not hard to imagine doing synchronization of the content to a secure location hosted by the Eclipse
Foundation to preserve freedom of action in the future. So, in the end this is a concern but not a show-stopper.
The biggest concern I have is fragmentation. An issue tracker is not just a tool for committers, it is one of the primary interfaces between the committers and the wider community. If we allowed GitHub Issues we would have to allow other proprietary but
free issue trackers as well (Jira and Trello for example are also very popular with developers). It is an important part of the Eclipse Foundation by-laws and culture that we be vendor-neutral - where vendor specific options are available they need to be open
to all vendors equally. If we have three, four, or more different issue trackers across Eclipse projects, it creates friction for communication with the wider community, and across Eclipse projects. Contributors and users need to learn multiple tools to communicate
with us, and moving/linking bugs across projects becomes much more difficult. In the end I would rather have a single issue tracker across all Eclipse projects, even if it is a bit clunky compared to some of the proprietary options out there.
John
[1] http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html
> If you, as an Eclipse IoT project, are interested using GitHub issues
> for your project, please reply to this E-Mail. Maybe with a _short_
> explanation why.
|
