Re: How about moving to GitHub?

[Joern Kottmann <ko...@gmail.com>]

Richards has a few good points here. The combination of PR reviews and
CI for each PR really help with high quality maintenance.
I wouldn't enable any of the branch protection features other than
disallowing force push, in the end it is anyway about trusting other
committers and not to about enforcing rules.

Indeed it is true that many people have a hard time to get started
with git, and it was also the same for me, but once you get it, it
seems very natural way of doing things because it allows to influence
every commit to the last detail before you send it in via a PR and
merge it.

A team with little git experience can formalize a step-by-step guide
everyone should use to begin with. Maybe something like this.

This could be:
Create a branch for the work you do with
`git checkout -b branch_name`

Change some files and commit it via
`git commit -a -m "commit message"` (commits all changed files)

Need more changes? Then update that commit via
`git commit -a --amend`

Done?
Push to the remote repository and then send a PR via GitHub webinterface
To push: `git push --set-upstream branch_name`

Maybe now you get some feedback and need to update the PR:
Again `git commit -a --amend`
Then `git push -f`

The PR itself can be merged via button click on the PR GitHub page
after positive review.

If you follow these steps you have a svn like experience but with the
git advantages.

The big conceptual difference from a committer perspective between svn
and git is that what is a commit in svn, is a PR merge in git.
And the later can be done by a button click, which can only be clicked
by committers.

Anyway, it would be quite a bit of work to get this project migrated
and then everyone needs to still spend an hour or two to earn the new
way of doing things.

Just my 2 cents

Jörn

On Mon, Aug 28, 2017 at 3:21 PM, Jaroslaw Cwiklik <cw...@apache.org> wrote:
> Lou and I were "exposed" to Git and Gerrit on a project and suffered quiet
> a bit when problems arose. A bunch of times we had to beg Git experts for
> help with recovery. I am not against learning something new, but at this
> time I don't have the time to go through the learning curve Git requires.
> For what I need now, the svn works just fine.
> Jerry
>
> On Mon, Aug 28, 2017 at 9:11 AM, Marshall Schor <ms...@schor.com> wrote:
>
>> I don't have much experience with git/ github (but have used both briefly).
>>
>> My main feeling at the moment is that due to personally being
>> overcommitted, I'm
>> reluctant to switch horses at this time...
>>
>> The UIMA V2/V3 development is currently making very nice use of the SVN
>> merge
>> capability:  I make a change in v2 (say, to fix a bug), and then "merge"
>> it in
>> one svn operation into v3, mostly works great (occasional conflicts need
>> resolution, for example when the change involves the main change in v3 for
>> Feature structure representation, indexes and iterators).
>>
>> I don't know how well git would do for this kind of thing...
>>
>> -Marshall
>>
>>
>> On 8/26/2017 6:54 AM, Richard Eckart de Castilho 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
>> >
>> >
>>
>>

Re: How about moving to GitHub?

[Richard Eckart de Castilho <re...@apache.org>]

I was trying git svn with UIMA a while back, but I don't remember anymore why I gave it up again. I think the way I wanted to do branching somehow didn't work out... and/or the GIT UIs may not have been working nicely either with git svn... but I should read that Apache documentation try again.

Cheers,

-- Richard

> On 10.11.2017, at 21:16, Marshall Schor <ms...@schor.com> wrote:
> 
> I'm wondering, since we have a git mirror already for uima projects, if that
> could allow those who want the advantages described to work with git? e.g.
> 
> 
> git://git.apache.org/uima-uimafit.git <git://git.apache.org/uima-uimafit.git>
> 
> and https://github.com/apache/uima-uimafit
> 
> from https://git.apache.org/
> 
> That page also mentions a link to how to set up git svn dcommit support, which
> allows pushing changes from git back into svn. 
> 
> I haven't used this myself... But it kind of looks like we might already be able
> to use git environment if we want?
> 
> -Marshall

Re: How about moving to GitHub?

[Marshall Schor <ms...@schor.com>]

I'm wondering, since we have a git mirror already for uima projects, if that
could allow those who want the advantages described to work with git? e.g.


git://git.apache.org/uima-uimafit.git <git://git.apache.org/uima-uimafit.git>

and https://github.com/apache/uima-uimafit

from https://git.apache.org/

That page also mentions a link to how to set up git svn dcommit support, which
allows pushing changes from git back into svn. 

I haven't used this myself... But it kind of looks like we might already be able
to use git environment if we want?

-Marshall


On 11/10/2017 10:34 AM, Richard Eckart de Castilho wrote:
> On 01.11.2017, at 11:46, Joern Kottmann <ko...@gmail.com> wrote:
>> Indeed it is true that many people have a hard time to get started
>> with git, and it was also the same for me, but once you get it, it
>> seems very natural way of doing things because it allows to influence
>> every commit to the last detail before you send it in via a PR and
>> merge it.
> There is something related in SVN that I find increasingly annoying
> now that I know git: SVN does not support committing partial changes
> from a file.
>
> In git, I can inspect all changes in my workspace and if a file
> contains some changes I want to commit and some that I don't want
> to commit, then I can simply select which lines should be included
> and which not. As far as I know, there is nothing like that in SVN.
>
> Cheers,
>
> -- Richard
>

Re: How about moving to GitHub?

[Richard Eckart de Castilho <re...@apache.org>]

On 01.11.2017, at 11:46, Joern Kottmann <ko...@gmail.com> wrote:
> 
> Indeed it is true that many people have a hard time to get started
> with git, and it was also the same for me, but once you get it, it
> seems very natural way of doing things because it allows to influence
> every commit to the last detail before you send it in via a PR and
> merge it.

There is something related in SVN that I find increasingly annoying
now that I know git: SVN does not support committing partial changes
from a file.

In git, I can inspect all changes in my workspace and if a file
contains some changes I want to commit and some that I don't want
to commit, then I can simply select which lines should be included
and which not. As far as I know, there is nothing like that in SVN.

Cheers,

-- Richard