On Mon, Jul 14, 2008 at 07:39:40AM -0800, Jeff Spaleta wrote:
On Sun, Jul 13, 2008 at 7:29 AM, Richard W.M. Jones
> and because having libvirt on Windows is a highly desirable outcome
> for us, we would be prepared to do the work either with maintainers,
> or ourselves, to maintain MinGW subpackages of these packages. If at
> some point in the future we aren't able to continue that work, then as
> with any other Fedora package they would eventually be removed from
> Fedora by standard processes.
> The same would apply on a case-by-case basis to any other library.
I abhor case by case restrictions.. especially ones where we are
trying to judge whether or not a single person as the time to actually
maintain the package. We sure as hell don't do that for the rest of
the packaging space. You have to do much better than "highly unlikely
due to time commitment". I don't consider that a bright line at all.
I need something as a policy statement which we block on at the time
of package review.
On the contrary, this is exactly how Fedora packaging works right now.
"A Contributor is defined as someone who wants to submit (and
maintain) a package in Fedora."
"When Fedora maintainers do not want or are not able to maintain a
package any longer, they can orphan or retire the package."
And speaking of review... since you are doing this as a subpackage
existing packages we don't even have a requirement that this sort of
thing goes through a peer review process because they aren't new
Well, with respect this is a problem with the Fedora process. Coming
myself from a Debian background, I was always very surprised by the
fact that once a package is in Fedora, it's virtually a free-for-all
as to how that package is maintained. In Debian, things are quite
different - large numbers of automated tests run continuously over
existing packages, and any which don't conform to policy have an
escalating scale of sanctions against them.
We can have a separate discussion about fixing the Fedora process.
What I still don't have an answer for is why does this need to be
the main repo? Why can't we spin off a mingw compiled repo as a
separate addon repository inside our infrastructure? And then the
minGW SIG can deal with library inclusions into that addon repo
however they want..with their own submission and review
policy..separate from the main repository policy.
Same could apply to, eg., Perl packages (no offence to perl
maintainers :-). It is much more useful if these packages are part of
Fedora, rather than unnecessarily cordoned off in a separate
New packages go through a peer review step before we let them in.
a minimum mingw cross-compiled crap is going to need its own
submission review..which isn't going to happen if we allow this in as
subpackages because our existing review process doesn't extend to
With your use of phrases such as "mingw cross-compiled crap", I
suggest you are not taking a level-headed approach to this. This is
entirely free software, just that maybe it's not being used for
purposes which you approve of. Fedora software is also used in the
manufacture of tobacco products, cluster bombs and SUVs.
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.