User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
On 15/10/2015 4:23 AM, Julien
Vermillard wrote:
Hi,
Thanks for the status Mike.
Now since we are waiting for a long time, do you think you
would accept something developed by the community but probably
cruder, like copying GH issues and copying them to a plain
text file or posting then to a read-only bugzilla? So if GH
fuckup we can activate the bugzilla project.
Sadly, no. The Board approved a particular solution, not the general
one. That may have been a mistake in retrospect, but that's where
we're at. I will push on this to get it moving.
Committer reps - should we put this topic on the F2F meeting agenda?
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.
> 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.