All,
I owe everyone an apology for not responding to this thread quite
some time ago.
John did lay out the issues that we were grappling with concerning
the use of GitHub Issues. However, I would like to add that in the
end the Board decided some time ago that we would allow Eclipse
project to use GH Issues once we have established a reliable
mechanism to replicate the data back to Eclipse's servers. Ideally
this replication would be a live two-way synchronization with
Bugzilla so that we can have the best of both worlds. To that end,
we have been working with Tasktop to get Tasktop Sync working
between GH and BZ. Unfortunately, this has taken far longer that
we had originally hoped.
The key principle at play here is "freedom of action". Similar to
the approach that we took when we allowed the use of GitHub at
all, we want to make sure that if we use any external service,
that if that service goes away the Eclipse projects affected can
continue on. Obviously, there would be some short-term disruption,
but no loss of critical data or history.
So I think that we have overcome the philosophical concerns, and
are now in the implementation phase. However, we do seem to be
stalled on that implementation. Please be patient with us while we
work this out.
On 17/06/2015 9:54 PM, John Arthorne wrote:
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-pmc
|