uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kl├╝gl <peter.klu...@averbis.com>
Subject Re: How about moving to GitHub?
Date Mon, 28 Aug 2017 10:10:30 GMT
+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 <rec@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
>>
>>


Mime
View raw message