On 01/05/2012 09:13 PM, Kevin Kofler wrote:
On Thursday 05 January 2012, Michael J Gruber wrote:
> I don't know anything about rpmfusion packaging and infrastructure, so
> I'd be happy if someone picks up xine-ui there. In fact, xine-ui gets
> most xine related abrt reports, it seems, and I always found it
> difficult to decide whether those are really xine-ui or xine-lib issues.
> So, xine-ui would best be put into the xine-lib maintainer's hands
> anyways ;)
Well, to be honest, I'd be glad if xine-lib also got a new maintainer.
(Xavier? :-) ) As I wrote, I only really maintain xine-lib because of Kaffeine,
and I'll stop caring about xine-lib the day Kaffeine releases its MPlayer-based
code (or something else not based on xine-lib). In particular, I also really
don't want to maintain xine-ui…
I can help with xine-lib and xine-ui in RPM Fusion, but I'm not sure
I'll be a good primary maintainer for them. I'm more of a package monkey
than a developper. Anyway, for some reason, I still value xine-lib and
I'd hate to see it go away, so I'll take it if nobody else step up to
the plate. I also use xine-ui, and I could take care of it too, but I
have the feeling it doesn't receive much upstream love...
Note that xine-lib-extras-freeworld can be merged back into xine-lib
when it
moves to RPM Fusion, and the new xine-lib can Obsolete/Provide it. That'll
allow making the packaging a bit less of a wicked mess than it is now.
I'm sure having only one package for all the xine-lib bits will ease the
life of the both the package and the repos maintainers.
Regards,
Xavier