RE: Teleconference - Friday Feb-24 2012 - Summary

[Yves Savourel]

Okapi Teleconference - Friday Feb-24 2012 - Summary

=== Migration to Git

Pretty much done.
Report from Jim and all.

Remaining tasks:

1. Find solution for how to host private maven repo on git or alternative solution (/maven2)
-> no solution yet
Only swt jars are in maven2 now. (trov4j exists in a public repo)
Note: SVN repo is read-only.
Eclipse has a test repo.
Another option is to check-out, another to create a repo in Sonatype.
Will need a solution for when to upgrade.
Another option: our own Cloudbees repo.

2. Port sandbox projects - need to pick which ones
Maybe we can just leave the old stuff SVN and start fresh on Git.
Decision: we don't convert the sandbox. But anyone who needs it can do it.

3. Update cloudbees to work from git source.
Need to update the SCM source.
Maybe Asgeir will have time to this?

4. Decide on general workflow and policies - see Chase and Asgeir's suggestions.
Jim ran into issues when trying to updated a file already updated.
Fetch + Merge is better than Pull (maybe?)

Jim considering creating a clone for public updates.

=== Segmenter implementation

Report from Sergei

Code ready. Fast and stable.
Support ICU 4.8.11, Unicode 6.0, etc. Latest stuff.
Need to check ICU version in main branch.

Very long to implement.

=== Sub-Filters

See:
http://groups.google.com/group/okapi-devel/browse_thread/thread/11174b00ca36eb71

Jim will try to start a branch on this.
Will need to track the main branch. Git should pay off here.
Should we have also a branch for Drupal subfilter?
Will see.

=== Top-10 items

Yves was to post the list in dev and CC tools:
-> Will try to do that ASAP.

=== HTML5

Yves was to provide unit tests for the translate issue.
-> Pending
-> Yves to check if we have an issue for this.

But case of added <meta>/<meta/> is resolved.

=== Olifant/tmdb

Report from Fredrik/Yves.

=== Drupal filter:

Fredrik/Yves will work on this.
Will use the drupal Services module (the REST API).
Will include sub-filter support.

=== Any Other Business

--- Related to segmenter:

Some non-standard SRX options in our segmenter.
Inline code handling should be revisited. We have an issue on this.

Dan: access token with MS Connector
-> Dan to work on it.

Sergei: docx input + Pensieve TM.
Inline code. TM hit was without the code. Resulting on a invalid docx.
We could have an extra step to "fix-up" target segment for missing codes: could be useful!
Without human: docx + fuzzy matches are a problem.

-end

[Sergei Vasilyev]

> === Segmenter implementation
>
> Report from Sergei
>
> Code ready. Fast and stable.

> Support ICU 4.8.1, Unicode 6.0, etc. Latest stuff.

>>> Need to check ICU version in main branch.

Also 4.8.1 in okapi-step-tokenization and okapi-lib-search (okapi-lib-
segmentation to come).

[Asgeir Frimannsson]

On Fri, Feb 24, 2012 at 6:03 PM, Yves Savourel <yves.s...@gmail.com> wrote:

4. Decide on general workflow and policies - see Chase and Asgeir's suggestions.
Jim ran into issues when trying to updated a file already updated.
Fetch + Merge is better than Pull (maybe?)

The maths:

git pull == git fetch + git merge

  and

git pull --rebase == git fetch + git rebase 

Keep in mind that useless and somewhat disturbing merge-commits (like those displayed in the log right now at http://code.google.com/p/okapi/source/list) can be avoided using pull --rebase. In my experience, merges are 99.9% of the time not needed and just cause noise.

cheers,

asgeir

[Jim Hargrave]

http://stackoverflow.com/questions/3357122/git-pull-vs-git-fetch-git-rebase

Here's a good visual on the difference - it does look like rebase is what you would expect and cleans up some of our "wondering paths" in our history.

Now I need to figure out how to get egit to do this by default.

Jim

[Jim Hargrave]

Its this kind of stuff that scare me to death:

http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions

are the exceptions to the rules going to kill us here. For example:

"I confirm that the correct workflow in that case (evolutions on common set of files) is rebase first, then merge.

However, that means that, if you push your local branch (for backup reason), that branch should not be pulled (or at least used) by anyone else (since the commit history will be rewritten by the successive rebase)."

what about our shared branches then like subfilter?

Jim

[Asgeir Frimannsson]

You cannot rewrite the history of a remote branch without forcing a push (git push -f), so if you avoid that, you should be pretty safe, i.e. rebasing only happens locally. 

We've also worked with rebasing remote branches. It works well when the team is comfortable with git. It works well when you communicate when you are rebasing, so that the rest of the team can update their branch. I've recently done that with branches with upto 250 commits, and it looks like all work has been done on top of master even if the branch has been going for months (not that that's a healthy sign at all!).

cheers,

asgeir

[Jim Hargrave]

That is the cool thing about git - I can do many commits on the bus over a few days - then push when I'm ready. This also encourages many, smaller, atomic commits - which are a good thing IMHO.

thanks for the info and encouragement - hopefully a few months from now we won't even blink when doing this stuff.

Jim

[Chase Tingley]

I would tread carefully about rebase for a little while until you are comfortable with the basic functionality.  It's a great feature, but if you try to use it before you develop a good feel for how the history/commit model works in git, it can cause some headaches.

I second Asgeir's rule of thumb -- if you find that something you want to do would require "push -f" to update the server, don't do it.