Looking back at e-mails from 2015 on this topic, we used Git & Gerrit. Even merge conflicts were sometimes a nightmare. It was just 2 of us, and we got stuck more than once needing expert help.
With respect to the DUCC part of UIMA, things seems fine to me the way they are using Jira. But then again, we have very few patches (if any). My vote 0 is unchanged, so far. Lou. On Mon, Aug 28, 2017 at 6:10 AM, Peter Klügl <peter.klu...@averbis.com> wrote: > +1 from me > > > At work, we use mercurial which is probably quite similar to git. I had > some hard to time adapt and learn at the beginning, but now I would not > want to miss it. I find it much simpler to develop stuff in parallel. > > The last weeks, I gained some experience with GitHub and git > (dkpro-core). It took me a bit to get "productive", but after a short > while it was OK. For me, it's important to find the right tooling. > > A switch to GitHub will not open the floodgates, but it could lower the > hurdle for contributions, and even some more contributions would really > be good. Just speaking for ruta: the first release was in March 2013 and > I am still the only active developer. That's not a desirable situation. > > Peter > > > Am 26.08.2017 um 14:47 schrieb Lou DeGenaro: > > I applaud your taking the initiative towards improvement. I did have > > experience perhaps 1.5 years ago using GitHub for another non-Apache > > project. My view was negative, though I could not now recite the precise > > issues encountered. My best recollection is that the happy paths worked > > fine, but when mistakes were made or problems were encountered recovery > was > > often difficult and frustrating. If I am the only objector then I vote > 0, > > but my gut votes -1. > > > > With respect to speculation, my sense is that switching to GitHub will > not > > open the floodgates to contributions. > > > > Lou. > > > > On Sat, Aug 26, 2017 at 6:54 AM, Richard Eckart de Castilho < > r...@apache.org> > > wrote: > > > >> Hi all, > >> > >> several Apache projects have moved parts of their development to GitHub, > >> some > >> more (no more Jira), some less (issues in Jira, code on GitHub). > >> > >> I have used GitHub more and more lately and find its processes quite > >> convenient. > >> This mostly revolves around the concept of "pull requests". People > submit > >> "pull-requests" instead of patches. Based on these, GitHub allows to do: > >> > >> * convenient code reviews > >> * leave comments (line-based as well as general) > >> * approve/request changes > >> * discuss the pull request as it evolves > >> * even exporting a pull request as a patch is easy > >> > >> Pull requests are essentially branches and it is possible for > >> interested developers to: > >> > >> * check out these branches > >> * collaborate on them > >> * finally merge them into the master (trunk) branch when ready. > >> > >> I have also made some experience setting up Jenkins in such a way that > >> it can automatically check pull requests: > >> > >> * an admin developer leaves a comment on a pull request such as > >> "Jenkins, test this please" > >> * Jenkins sees this comment and triggers a build of that particular > >> contribution > >> * Jenkins updates a "build status" that is visible directly in the > >> discussion thread of the pull request on GitHub. Depending on the > >> result of the build, it will give a red or green light. > >> * That is very useful to do an integration test of a contribution after > >> an initial code screening - no need to locally integrate a patch, > >> locally test it, etc. The initial screening can happen by looking at > >> a side-by-side div on the GitHub website - again no local effort. > >> > >> Finally, GitHub allows to enforce certain processes if desired. E.g. > >> one can *optionally* enforce that: > >> > >> * limit access to specific branches (e.g. master/trunk or maintenance > >> branches) > >> * no changes can go into master (trunk) without being reviewed first as > >> pull requests (a very strong 4 eyes principle, has ups and downs) > >> * pull requests must have passed a Jenkins check before they can be > merged > >> > >> All in all, I believe our project would benefit from moving to GitHub. > >> After an initial transition and adaption phase, our processes should > become > >> smoother, easier and as a result more interactive. The main hurdle for > >> us developers would in my view be to learn how do to source code > management > >> using a distributed approach. The way one has to think about code > >> management > >> in git (or probably any other DSCM tool) is different from a centralized > >> approach like SVN. To take full advantage, branches move into the center > >> of attention and branching/merging becomes a much more common operation > >> than in SVN. Fortunately, git supports such operations very well. > >> > >> The hurdle for contributions would also be lower (more and more people > are > >> familiar with GitHub processes, and already have GitHub accounts. > >> Juggling with patch files is (at least for me) a great annoyance). > >> > >> Of course, there is also the draw back that GitHub may shut down > >> at some point (like Google Code did) or start charging or introduce > >> terms-of-service that are incompatible with our goals. But due to the > >> strong interest of various Apache projects on using the GitHub > >> infrastructure, > >> INFRA has been working on various integrations e.g. mirroring GitHub > >> repositories (not sure how they handle it when Apache projects use > GitHub > >> issues though). Also at present GitHub appears to be very > >> community-oriented > >> when it comes to the terms-of-service, e.g. making text updates > available > >> to > >> the community early, soliciting and incorporating community feedback, > etc. > >> > >> On the bottom line, my personal judgement at this point in time is, that > >> the > >> benefits of smoother process and easier community involvement seriously > >> outweigh such risks and that many of the risks have been mitigated by > INFRA > >> anyway. > >> > >> What do you think? > >> > >> Best, > >> > >> -- Richard > >> > >> > >
