Re: [xine-devel] xxmc patch commited

[Michael R. <mr...@us...>]

Hi Thomas, Hi Miguel,

> i'd like to thank Thomas for his great work ;-)

Many thanks from me too. This is really fantastic work. VIA's own modification 
of xine was certainly better than nothing and it demonstrated VIA's good 
will, but this new implementation is really shiny clean. Not only that, it 
helps improves plain XvMC as well. Really cool!

> my current plan is to obsolete the older xvmc plugin in the long run.
> there's no hurry though.

Now that we are at throwing away plugins, would it be messy/difficult/stupid 
to merge drop the Xv plugin as well and somehow integrate it into XxMC too?
At least with the old XvMC video out I had the feeling that it shared a lot of 
common code with Xv and some fixes had to go into both files.

> ps: Thomas, as we talked before, i'm giving you cvs access. welcome to
> the xine project ;-)
> i must have some general cvs access comments written somewhere, but in
> short: try not to break things. when in doubt, ask on xine-devel
> before commiting something.

I have kept my notes from last time. I hope this does not frighten anyone, but 
I think I should convert this to HTML and put it on the website somewhere:

* The developer documentation for xine-lib is the xine hacker's guide.
  This is a good starting point for any fundamental questions.
* When you commit new code, please follow the xine coding style you can
  see in (almost ;) ) any file.
* The usual things apply for CVS: Break as little as possible, at least
  have it compile. Be extra careful before a release (which is
  announced some days before on xine-devel), since we release from
  CVS HEAD and usually do not use CVS branches.
* It is a good idea to subscribe to the various xine mailing lists,
  especially xine-devel (I guess you are already) and xine-cvslog.
  The latter receives a copy of all CVS commits, so you can easily see,
  if someone changed (or even broke) your code.
* xine-lib includes copies of code from a lot of other projects to
  support as much media as possible without forcing the user to install
  dozens of libraries. When you make modifications to any of that code,
  try to feed the changes back into the original project or provide a
  patch to ease merging future versions of the external project.
* When you are in doubt about something you want to commit or you are
  making bigger changes or changes to critical parts of the xine engine,
  post a patch to xine-devel for discussion before committing.
* Tell us, if you do not need your account any more, since abandoned
  accounts are a security risk.

So much on regulation, now: Welcome to the team and happy coding!

Michael

-- 
"Order is for the simple-minded - it's the genius who rules the chaos."
	-Sir Arthur Conan Doyle