On Fri, Nov 1, 2013 at 11:08 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
"Fedora Server WG where we discover product solutions that work well for our users, our administrators, our developers and our project." --> T-shirt anyone <-- ;)
We should be identifying which server applications work well on their own or work well with each other out of those 500+ we have ( think of them as ingredients ).
Once we have done that we add a Fedora secret sauce ( what we feel they are lacking for the 21 century which for example could be that missing configuration api ) and form a PRD for that recipe and implement it.
I agree with the focus on "product solutions" and the end-user-visible goal.
From an implementation point of view, I don't think creating many
individual "recipes" is optimal.
If you look at user's interaction, and correspondingly implementation/packaging/integration complexity, for a server-provided service (e.g. a daemon), and at the underlying "infrastructure" (for lack of better word), it basically goes like this: - The service: set up access rights 1-5 primary parameters (mail server: place to store mail; DB server: place to store the database, access rights; ...) - The underlying server "infrastructure": set up - Networking (several parameters per interface, perhaps bonding/vLANs / ... - Storage (arbitrarily complex stack) - Identity database - Setting up updates ...
(Obviously the situation is actually more complex than "1-5 primary parameters" for the service, there may be dozens or hundreds of tunables, but the same is true for the underlying server infrastructure components, so the relationship holds.)
So, it doesn't make much sense to me to make individual recipes starting with the application, and potentially diverging in the "infrastructure"; rather, the "infrastructure" should be common and the base of the product, with the various services being treated more like "applications" for the infrastructure (potentially some "bundled" and some separate). That doesn't mean that the services/"applications" are less important, but it does mean that the "infrastructure" is the same for all of them (which may require adjusting both the "applications" and the "infrastructure"). Mirek