[MPlayer-dev-eng] [PATCH] Simplify and factorize EOSD code

[Uoti Urpala]

On Fri, 2009-02-27 at 10:22 +0100, Nicolas George wrote:
> Le nonidi 9 ventôse, an CCXVII, Uoti Urpala a écrit :
> > No. Such a feature would be positive, but too irrelevant to make that a
> > principle you should follow, and it is not worth much effort or added
> > code. Adding a new independent overlay source in the code is, and should
> > be, rare. Cleanup after adding a possible new subtitle source for DVB
> > could be better handled by creating shared code for all subtitle sources
> > (which would be one user from overlay use point of view). After that
> > there would be no expected new independent users of "general overlay"
> > functionality.
> 
> I fear to actually understand what you are saying. Do you mean that if I
> submit a patch that actually implements DVB subtitle support by directly
> plugging it whenever I need, keeping cleanup for later, I would stand a
> better chance of inclusion?

Probably for the DVB part. I think the cleanup would probably be best
done in somewhat different way (more about that in another mail). The
more I think about it the less I feel there would be any need for a
general EOSD API designed for arbitrary users now.

> > http://repo.or.cz/w/mplayer.git
> 
> Alas, it does not seem to have a branch kept in sync with the official SVN
> repository. I will have to keep using my own git-svn repository.

You mean an extra branch with the plain git-svn contents that would be
automatically updated whenever there are svn commits? I guess that would
be possible to set up, but one problem is that immediate updates would
miss all retroactive modifications of svn history. There have been quite
a few commit message edits. Some outdated commit messages might not by
themselves be a particular problem for all possible uses of the branch;
but then either the main development branch would also have those
messages or the history of the git-svn branch would differ from the
version used for development. The main branch should have proper
messages if possible (though unfortunately the average quality of commit
messages from svn is low even after any edits).