On Mon, Jul 14, 2008 at 7:50 AM, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > With your use of phrases such as "mingw cross-compiled crap", I I have to apologize.. i use the word "crap" quite liberally as a synonym for "stuff". I need to stop doing that. Just wanted to say that first. >On the contrary, this is exactly how Fedora packaging works right now. > >https://fedoraproject.org/wiki/Package_Review_Process > "A Contributor is defined as someone who wants to submit (and > maintain) a package in Fedora." > >https://fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages > "When Fedora maintainers do not want or are not able to maintain a > package any longer, they can orphan or retire the package." > All of these definitions speak to my original concern. If we let you package up mingw built libraries.. there is nothing in our policy which would keep any one else from doing exactly the same with other libraries. The "highly unlikely" argument doesn't hold water. There is no bright line between you or any other contributor. If you can add a subpackage.. then anyone else can..and we could quite easily in 2 releases end up with a large collection of cross-compiled paylods in the main repository..that we expect all our mirrors to digest. I'd rather plan for that sort of future, instead of pretending that you and a few other contributors are special compared to other library maintainers. If you can't stand up a reason any better than "most package maintainers won't be able to do it" then I have to assume that other library maintainers will do it, because you will enable them to do it. The stuff that is being drafted right now for the mingw SIG is going to lower the bar significantly for the next group of maintainers who want to get a dll compiled. > 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. No we are going to have a discussion in the context of dealing with cross-compiled content. You have to present how you expect cross-compiled content to be reviewed for submission or I'm going to push back really hard, harder than I am right now, about seeing any cross-compiled content into the main repository. This stuff is so different than are regular workflow, that it requires some care concerning how to fit in the review into our existence submission and review model. These are exactly the sort of questions I expect the mingw SIG to have some initial answers for. You can't just throw a few of these subpackages over the wall and call the work of the SIG done. You must, you absolutely must propose how these things are to be reviewed. >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 >infrastructure. Are you saying that enabling an additional repository in your package manager is in fact too burdensome for a developer who is looking to cross-compile? C'mon. I don't understand why its much more useful in the main repo. The repo definition would exist in the default configs and it could either be enabled or disable by default. Hell you could enable it by default in the developer spin, but disable it by default in the Desktop spin. Isn't the target market for this stuff developers? The point however is that we do not demand that all the main mirrors host this material. They would be given a choice to pick this up and if you are wrong and this becomes popular and a lot of people want to rebuild libraries against mingw..we will have the structure in place to support it without burdening the main repository with 2x the library binaries. Stop dogging the question by holding up other sorts of payloads as strawmen. If you continue to do that, I'm going to stop asking the question hoping for a defensable answer. First..these mingw libraries do not directly benefit Fedora users. Perl, python, native libraries are directly provided to be used as part of the users of the Fedora Linux distribution. There is a clear distinction between what we provide currently and anything that is cross-compiled. Yes the mingw compiled dlls are useful to a subset of developers. I'm not questioning that. But I am less and less sure that the value there is worth opening up the main repository to this sort of cross-compiled content. And I am becoming more sure that the value that is there is maximized by having an expansive set of such dlls.. not limited to the immediate needs of libvirt. By setting this up as a separate repo but still inside the Fedora project, we can move forward and give you want you need but also start a process by which we can maximize the community value of these builds. In a lot of ways, this would almost be its own distribution that was built on Fedora. Second..we don't even ship all possible arches of the libraries that we do have. We have this concept called secondary arches so that individual contributors who want to extend Fedora onto new hardware platforms can do so, by bring resources to the table to do it, without asking the main mirrors to take on the distribution of that additional compiled material. A collection mingw compiled dlls feels very much like a cross between a distribution and secondary arch. Which sort of makes sense..since we are talking about cross-comppiling. Why shouldn't we ask you or anyone else who wants to cross-compile for another platform to be treated similarly from a policy perspective to how we ask our secondary arch developers to be treated? Why can't we make mingw a virtualized arch, and ask that the mingw payloads be ifarch'd in the spec file and built only for a specific arch target so that it can be treated as a secondary arch for a hosting and distribution point of view? Would you call secondary arches like sparc or arm "cordoned off" in our current policy. You aren't going to dodge the review burden on mingw payloads by waving your hands and saying the Fedora process is broken. If you feel our process needs fixing, then we fix it first before the mingw payloads are allowed in... not the other way around. -jef -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
