On Wed, 2013-11-13 at 19:29 +0000, "Jóhann B. Guðmundsson" wrote:
I can answer that quickly you cant install multiple roles
afterwards.
And to answer your next question no you cannot switch roles either.
What you can do is install FOSSP and then manually install mariadb and
corosync ( and all the server "generic" bits we on top of that ) and set
things up yourself.
Server roles will need to be each in their own branch, with their own
repository and each on their own release cycle.
I tend to disagree here. It would make any mistake an horrible
experience for the user.
This is what you would go in the FOSS home page help to choose the
server role(s) you need and would even as to delivery you ( with ks we
might be able to pull that of harder with VM's ) optimized server role
for you infrastructure.
I fail to parse this phrase.
>> And keeping things separate from "Fedora" in
separated branches
>> allows us to move further at a faster pace. ( By my estimation we are
>> the WG that has the biggest momentum as things stand now )
> What do you mean by 'branches' in this case?
FOS and it's bits on it's own FOS master branch with their own ( yum )
repository with it's own release cycle
FOSSP and it's bits on it's own FOSSP master branch with their own ( yum
) repository ( all server bits belong there ) with it's own release cycle
Each application in a defined server roles and it's bits on it's own
master branch with their own ( yum ) repository with it's own release cycle
Isn't this going to create a lot of work and a lot of chance for
incompatibility between the repositories ?
>> A) FOS release cycle should be tied to the kernel release
cycle
>> ( which means roughly 3 FOS platform releases per year with the
>> exception of the kernel's LTS release which we would have to tie our
>> LTS release upon )
> Why?
Inevitable evolution of how the coreOS bit are getting intertwined with
the kernel which means you can either try to continue to ignore that
fact or now re-act to it with that in mind.
if the coreOS runs faster than all the bits we want to lie on top, how
do we rely on it ?
>> C) Server Roles each need to be on their own release cycle.
( mostly
>> due to upstream participation as in they control the release cycle of
>> their application after all they are the ones that have to maintain
>> it )
> How would that work? So, I install Fedora Server and install the
> mariadb role. in 3 months, a new mariadb upstream is released. Would
> this be pushed out as an update? Or would it be opt in if I wanted it?
> or ?
Not following you, you can always decide to update ( or not ) to the
bits made available to.
What is the maintenance scheme for each role in your proposal ?
I'm not sure you have realized this since I have not written it
on the
FOSSP draft yet but we would be working closely with the mariadb
maintainers ( if they are willing to participate in this effort )
defining mariadb as one of the available relational dbms database
services server role and they themselves have full control over how long
they intend to support it as well as to how frequent they push update to
it to their mariadb server role repository.
This means each role would vary wildly in stability. One group of
developers could be rightfully (for a *server* product) conservative and
another could keep pushing unstable changes that keep breaking the
system, I do not find your plan workable.
We can only come up with a recommendation guidelines to server roles
where we say we would like you to do things this way but you are not
*forced* to follow it.
One of the concerns that I have been approached with by maintainers in
relation to the work we are doing here, is if we are signing them up for
something they dont want to take a part of and my approach most
certainly does not quite the opposite and that's something to bear in
mind as well.
I think the only thing we should really care for are prompt security
releases and really critical bugs, if a product is not further updated
it is not a big deal, but it would be a lot worse if a product is
updated every 3 months to the latest and greatest (and most borked)
release.
Simo.
--
Simo Sorce * Red Hat, Inc * New York