A pinch of Symfony for D8MI?

http://www.mjdinteractive.com/mjd-blog/2012/04/drupal-8-to-utilize-symfony-2-components/
One of the goals of Drupal 8 Multilingual Inititive is to refactor Gettext file handling by a component. The first effort was Make gettext .po generation its own abstracted functionality by Gábor Hojtsy, Sutharsan, fubhy, sun and clemens.tolboom While I (clemens.tolboom) was working on that issue I skimmed over the Translation component delivered by Symfony to see whether we could match their architecture (why reinvent components?) or even take over their components. Progressing further and discussing progress with Gábor Hojtsy and sun on #drupal-i18nsun suggested to create a new issue trying to use the Symfony Translation component and see what happens with Let Symfony Translation component handle language messages. This lead me into a new world of GPL versus MIT, php development, git squash, github pull requests etc. Here are some experiences from my pull requests for Symfony (click closed button to see all.)

Experiences

Licenses and the copy paste cat

My initial D8MI related pull request Drupal gettext was a bummer as I added a slightly changed and objectified copy-paste version of some parts of gettext.inc forgetting GPL does not allow loosening the license into a MIT version.

git squash et al

By having a pull request the receiving party wants a clean commit. But as a developer you commit every new feature into a local commit to make cherry-picking possible. For this to work you need to squash all commits into the commit belonging to the pull request. Thanks to stloyd pointed me to Using Git Rebase to Squash Commits explained a great deal to me and http://symfony.com/doc/master/contributing/code/patches.html

Should we go using Symfony Translation component

The Symfony Trans2drupal pull request is developed based on the patch for Drupal Let Symfony Translation component handle language messages. That introduces a brittle dependency as it is not committed. It is not actively commented too. So that's not comforting. The flip side is we can drop a lot of code and focus on our Drupal code when the pull request lands. In writing the code I learned new ways of coding (more PHP less Drupal) which is nice. Image taken from http://www.mjdinteractive.com/mjd-blog/2012/04/drupal-8-to-utilize-symfony-2-components/

Comments

The GPL bit is unfortunate. We'll have to be careful about that.

btw, You wrote GLP in the 4th paragraph when you meant GPL.

It flies against a couple thousand years of scientific practice to throw away the notes leading to a discovery, or in this case, the code. It doesn't hurt anyone to see a single line commit saying "typos". The mainline history should contain nothing more than just merge this feature, merge that branch and then only those who actively seek the the detailed information can see it -- but they can see. If you squash you lose information. Never do that.

I totally agree ... partly :p

While working on my Symfony pull request I also did stupid things. Those are only interesting for Historians interested in the developer experience.

What I 'discovered' while squash-ing was I can keep (merge) all commit messages into one commit.

Locally I was annoyed have squash-ed my commit as that disallowed for cherry picking. So I have to figure out how to do that and still comply to the Symfony way.

Note that Drupal does squash-ing all the time by using patch files :p