On 21 January 2015 at 03:23, Honza Horak <hhorak(a)redhat.com> wrote:
These are really interesting ideas, even if I don't understand
all physics
equivalences :)
About the amount of man-hours needed for any different model, I think the
current model does not require little amount of man power at all, I'd rather
say keeping all things work nicely together require actually quite
substantial amount of knowledge and time fixing compatibility issues.
Decoupling could help to see and fix the issues.
However, as we start decoupling things, I see there might arise new
challenges regarding compatibility of those parts -- which is actually where
I see the discussions about rings model should give us some answers and we
should find a way how to ensure the compatibility with reasonable amount of
man-power. Anyway, I agree that in case we find it requires too much
resources, it should be a reason to change the concept.
One thing to keep in mind is that when we talk about "Stacks" in the
Environments & Stacks model, the idea is that Fedora is responsible
for providing the *base* of the stack, and potentially tools for
application level dependency management within the stack. What we're
*not* responsible for is integration testing *of* the stack.
The whole point of this is to provide a layer where Fedora as a distro
provider says "above this point, the onus for integration testing and
security updates is on the application developer, not the distro".
*Within* Fedora, we should *not* be providing divergent copies of
applications. httpd should be httpd, regardless of whether you're
running Workstation, Server or Cloud.
But a developer may choose to do their own integration testing and use
a httpd Software Collection, rather than the one integrated directly
into the Fedora platform. They'd then gain the benefit that their SCL
based project could use the *same* SCL to also run on supported
versions of RHEL and CentOS, rather than just on Fedora. However,
they'd have to build and test their own packages to run *on top* of
the SCL, or use a non-RPM dependency management system like pip, cpan
rubygems, etc for the application components.
Regards,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia