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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
