| Hi John,
Thanks a lot for sharing your thoughts.
While I fully understand your arguments about fragmentation, I believe giving projects the choice to use Github as a primary code repository and hence also Github PRs instead of Gerrit for contributions, this fragmentation is already a matter of fact. And as you can see from the comments of the project leads, it is actually Bugzilla which our contributors have to learn additionally, which is the main pain point. They browse the code on Github, they do their PRs on Github, the code review and discussions around it happen on the Github PR and then they they really wonder what is this „Bugzilla thing“ that they are supposed to use aside as well. Note that many discussions naturally already take place on Github PRs, which are effectively nothing else than a Github issue with an associated code branch.
I understand that for „traditional“ projects that are using the Eclipse Git repo and Gerrit, Github Issues would be a bad choice. But for projects that primarily use Github already, it is a logical step and Bugzilla really means pain for the project leads as well as for contributors.
Best regards, Kai
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.
_______________________________________________ iot-pmc mailing list iot-pmc@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/iot-pmc
|
