12:54 p.m.
On 07/10/2013 01:42 PM, Michael J Gruber wrote:
Do you top-post on rpmfusion-developers? I'm sorry if I messed
that up,
I'm not on that list and don't know the policy.
As on most lists, no, we don't top post, but no worries ;-)
We were talking about restructuring the xine packages, and xine-ui
was
supposed to be subsumed by another package if I remember correctly.
Ok, I see what you had in mind now.
Currently, xine-lib is split into the main package in Fedora, and a
companion package in RPM Fusion (xine-lib-extras-freeworld) that ships
all the bits of xine-lib that cannot be in Fedora for some reason.
xine-ui and the other xine-lib dependant packages don't suffer from this
kind of split, so they'll stay as they are, just at a different location.
Do we move first than repackage?
I guess the plan could be to have all the packages created in RPM
Fusion, then all the packages retired from Fedora. We'll need to first
build xine-lib, then all the other packages. I don't have experience on
this particular matter, so I welcome any advice. Especially, I don't
know if the moved packages will need to be re-reviewed or not. There is
a review ticket open for xine-lib in RPM Fusion bugzilla, but this is a
bit different, as this is about merging xine-lib and
xine-lib-extras-freeworld packages.
Please note the target is Fedora 20, so we'll have a bit of time to land
all of this in devel, I'd say the target could be before branching
Rawhide for F20. Indeed, the packages that are currently in Fedora 19
and earlier and EPEL are not affected. Only the devel and f20 branches
will be touched.
In that case we would need an rpmfusion maintainer for xine-ui, or I
would need to become one. If someone wants to jump in - by all means go
for it. Otherwise I hope that rpmfusion maintainership doesn't differ
too much from fedora maintainership in terms of tools etc. I won't be
able to before mid August, though.
RPM Fusion strictly follows the Fedora packaging guidelines, but is less
strict on the allowed software and licenses. However, the tools are a
bit different than what we have now in Fedora (git vs cvs, koji vs
plague, bodhi vs manual scripts). I think moving closer to the Fedora
build infrastructure is in the works, but I don't know about the current
status.
About maintainership of the packages, the easiest would probably be to
keep the current maintainers. That's true even for xine-lib, but as I'm
looking at updating it to a more recent release and Kevin wants to step
down from maintaining it, I'm de facto volunteering myself ;-) About
xine-ui, that's one of the frontends I'm using so I could be maintainer
or co-maintainer if you wish, but again, I'm not trying to grab more
packages, I have already my share ;-)
Michael
Regards,
Xavier
Xavier Bachelot venit, vidit, dixit 10.07.2013 12:34:
> On 07/10/2013 11:57 AM, Michael J Gruber wrote:
>> Xavier Bachelot venit, vidit, dixit 10.07.2013 10:58:
>>> Hi,
>>>
>>> On 01/05/2012 08:56 PM, Kevin Kofler wrote:
>>>> The following packages currently depend on xine-lib:
>>>> * gxine
>>>> * (k9copy – already in RPM Fusion, not affected)
>>>> * kaffeine (my package, the reason why I maintain xine-lib in the first
place)
>>>> * oxine
>>>> * xine-plugin
>>>> * xine-ui
>>>> These packages would have to move to RPM Fusion along with xine-lib.
>>>
>>> Fwiw, I've rebuilt all the above packages (but k9copy, not tested yet)
>>> against the xine-lib 1.2.3 rpm I prepared and all the builds succeeded.
>>> No runtime tests yet.
>>>
>>> Would all the impacted maintainers be ok to move their package to RPM
>>> Fusion, alongside with xine-lib 1.2 ?
>>
>> Yes, more than happy.
> great.
>
>> I assume that packages such as xine-ui would be
>> subsumed in other packages then?
> I'm not sure to understand what you mean here, but each package would be
> retired from Fedora and a corresponding package be created in RPM
> Fusion. The RPM Fusion maintainer can be the same person as the former
> Fedora maintainer, as a sponsored Fedora packager is entitled to be an
> RPM Fusion packager automatically. Indeed, if the Fedora packager
> doesn't want to keep maintaining his package in RPM Fusion, another
> maintainer will have to be found or else the package would have to
> unfortunately be retired, if no one steps up.
>
>> I'd pass over maintainership to the
>> corresponding superpackage maintainer then.
>>
>> Michael
>>
> Regards,
> Xavier
>