2014-03-21 14:46 GMT+01:00 Dennis Jacobfeuerborn <dennisml@xxxxxxxxxxxx>:
As I perceive it one of the biggest problems for Fedora as a development platform for new technologies is that everything is tied to very rigorous guidelines and controls that tend to be fairly conservative. This is great when you care about overall stability and coherence of the platform but terrible if you want to enable people to use Fedora as a platform to spearhead new technologies.
One example is the policy that patches for packages should first be submitted and accepted upstream before they make it into Fedora. This works great because that way you can ensure that once features are added in Fedora it is unlikely that they have to be removed later again because they are rejected upstream. It's terrible though if you want to live on the bleeding edge. Take for example the networking features of OpenStack that required kernel changes that weren't yet committed upstream or the fact that Docker required AUFS for a long time. In both cases Fedora was a terrible platform to develop these technologies because of its conservative stance.
Well, a distribution is an integration project. Everyone is perfectly free to replace individual components with HEAD checkouts, or the equivalent copr RPMs, to be able to develop such bleeding-edge software; but that doesn't automatically mean that the millions of Fedora users should have the same bleeding-edge software imposed on them just so that the developers of that specific project have an easier time.
For users, Fedora really should include and promote software that is past the bleeding-edge state, something that we can honestly recommend to the end-users as safe and practical to use. That does tend to rule out major out-of-tree patches, especially for kernel, and especially especially for union filesystems, which have a multi-decade history of being created out-of-tree and never becoming good enough to include in the mainline.
For developers, the current work of enabling copr and other related activities should make the developers' life easier without impacting the end users.
For developers, the current work of enabling copr and other related activities should make the developers' life easier without impacting the end users.
That said, I do think we should not be hostile to small Fedora-specific patches that include the integration of the distribution.
What I hope will happen with the "Productization" of Fedora is that these products will be allowed to have a more independent identity and given more leeway to do things different. I will go so far and hope that eventually these products will be allowed to have their own policies regarding packaging and for example be able to ship their own kernel packages likely to be derived from the main kernel but with additional patches as the ones mentioned above.
So far FESCo has had a fairly strong consensus on minimizing the differences within packages between Products—it's fine for the Products to differ in package selection, but differences in package content, while probably inevitable, should be minimized.
Anyway my point is that telling product A that they cannot proceed with their work until product B is released is pretty much the opposite of what you want to do.
That's not the F21 situation: what has been considered is that no new products (not targeted at any particular one) could proceed until we know that the infrastructure for all projects is workable (with the current three products serving as guinea pigs, thinking that we do need some guinea pigs but having more is not useful).
Instead the message should be: "Want to create a new way to manage the update life-cycle of systems (OSTree)? Want to create a new way to manage better application deployment (Docker)? Build a Fedora product as Fedora can provide you with a solid foundation for whatever you are trying to accomplish!"
Well, the Fedora Products do need to still be Fedora. We shouldn't end up in the other extreme position of Fedora providing hosting to dozens of software distribution projects that have nothing in common, and there is a definite balance to be struck. To me, a significant factor in the balance is "does the subproject benefit from, and is it beneficial to, the work of the thousands of Fedora contributors not working on that subproject?", which would rule out single Products unilaterally moving away from RPM and ignoring the bugfixing and patching done by Fedora contributors on the RPMs, for example.
Mirek
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
