Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-project-leadership] Use of GitHub Issues by Eclipse Projects


On 11 November 2015 at 04:44, Mickael Istria <mistria@xxxxxxxxxx> wrote:
Anyway, testimonials such as the one from Jetty claiming that they have more community investment in GitHub rather than Bugzilla+Gerrit are very convincing about the need to be there for some projects.

As Jetty is 20 years old next month (OK we lied when we said it was October at JavaOne), we have other experiences that are relevant here.   The Jetty project has at various time been hosted on:
  • private SCCS with private issue tracker
  • Source force
  • Codehaus
  • Codehaus version 6, Eclipse versions 7
  • Eclipse
  • Eclipse master + Github slave

So lessons learnt over these many migrations include:

  1. It is important to use recent tools and development cultures. Most of those moves have been motivated to access either tools and/or communities and generally they have all been worthwhile.
  2. Some moves (eg from Codehaus) have also been motivated (at least in part) by shrinking communities as the culture fades.  Being reliant on third parties can mean your hand is forced.
  3. Tools do change behaviour.   The culture of bugzilla is very much "I'm reporting a problem for you to fix" and that is how it is used.  Github on the other hand has issues, code and PRs integrated in a way so the culture is more "This is an issue that we should fix... how about this solution?"
  4. Moving can be painful in both technical and project cultural terms.  You do lose contributors and the disruption can impact productivity sometimes for years.
  5. Keeping history is hard, but important.  We still need to lookup jetty-6 stuff sometimes and the death of codehaus did break things.
  6. Running dual issue trackers (as we did with codehaus JIRA & eclipse bugzilla) can be extremely painful and confusing.   However we are currently manually mirroring github issues to bugzilla and while a sligtht PITA it is at least not too confusing.
So I think those that have expressed caution about being dependent on a third party and the disruption that a move can incur are spot on.  Caution is needed.

However, I think the Board's resolutions are spot on.  We do need to embrace the latest tools and culture, but we have to do so in a way that preserves history and maintains some independence from third parties.  Any move has to be done in a considered and planned way, so stating the intention and initiating discussions like this is the right way to go.

For me, the way we go forward depends a lot on what future is planned for bugzilla.   If bugzilla is going to be maintained and extended into the future (Even if many/most project use github as primary), then a mirroring approach should work.   But if bugzilla is considered to be in terminal decline, then a migration with data backup approach may be better.

regards

--

Back to the top