Few notes about FedoraOS Server Platform ( FOSSP )
Which touches serveral topics we have been discussing.
JBG
On Tue, 12 Nov 2013 16:32:13 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Few notes about FedoraOS Server Platform ( FOSSP )
Which touches serveral topics we have been discussing.
JBG
Hey. Quite a document. ;)
Some questions/comments:
Is FOS (Fedora OS) the product from our base working group? Or something else?
I'd not list some of those specific things FOSSP 'consists' of, as they may be decided by the base working group. Perhaps we switch from dracut to something else someday, etc. Additionally, some of them are subject to debate.
I'll say again that I don't think we should provide kickstarts. Additionally, I don't think we should try and provide images for every featured stack. I'd prefer something like the netinstall iso with anaconda tweaked for server use, and groups for package stacks.
We should talk with the Cloud WG and confirm what stuff they want to handle and what they would like us to handle as well.
I like the idea of getting something/fedup to provide some kind of 'before upgrade' report that can point out problems.
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
Service packs sound interesting, but need more information to say for sure. Are you seeing this as something like a point release? where all the updates are rolled up and tested as a group, then people can upgrade to x.1, x.2, etc? How often would this happen? Additionally we would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't people who want those just apply updates as they come out?
Thanks for writing things up... helps as a way to start more discussion for sure.
kevin
On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 16:32:13 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
Few notes about FedoraOS Server Platform ( FOSSP )
Which touches serveral topics we have been discussing.
JBG
Hey. Quite a document. ;)
Note this is an work in progress and without pictures ( as it says there in the DRAFT statement ).
Some questions/comments:
Is FOS (Fedora OS) the product from our base working group? Or something else?
That depends heavily on the outcome of the base working group but as things stand now what they have discussed and how I see us moving forward to the future are quite different.
As you are well aware of I had already given the "FedoraOS" a great deal of thought otherwise I would not have asked fesco to grant me time to put my data together the community proposal an alternative to rings to rule them all or PRD's.
For example I create this [1] in sometime in July, ( as well as briefly mention this to Bill over beer at flock ) I asked the kernel community about a new naming scheme in ( related to this ) and few other things here and there.
As well as I was not chosen for that group so...
I'd not list some of those specific things FOSSP 'consists' of, as they may be decided by the base working group. Perhaps we switch from dracut to something else someday, etc. Additionally, some of them are subject to debate.
Of course that list was just a list to start working with as well as to what is in those 16 server roles ( or even if we need more roles like for example there is no role that covers "printing". )
I'll say again that I don't think we should provide kickstarts. Additionally, I don't think we should try and provide images for every featured stack. I'd prefer something like the netinstall iso with anaconda tweaked for server use, and groups for package stacks.
I disagree ( with the exception of point you make about anaconda which I agree with )
And here's why...
ks files are easy to maintain. ks files area easy to deploy ks files are easy to adapt ks files are ready to use in already existing infrastructures. No additional learning curve for "new format" for existing administrators to learn since they are already familiar with ks syntax. Dnf in the distant future could use them to directly install into ( os ) containers Minimal code changes would be needed for Anaconda.
Releasing a full blown iso ( with each role ) makes no sense while ready to use virtual images for the cloud or just virtualsation in general however does.
I even shall go as far as saying ks files should be our primary release format ( or atleast the first one we implement )
We should talk with the Cloud WG and confirm what stuff they want to handle and what they would like us to handle as well.
Quite frankly I dont grasp that separation there never should have been an cloud WG to begin with.
Matt could have gotten what he wanted quite easily without it from my pov.
Both the hosting and the creation belongs within the server community.
I like the idea of getting something/fedup to provide some kind of 'before upgrade' report that can point out problems.
Dont forget the missing infrastructure or web tool which helps administrators to dermine which server roles they are looking after and should deploy
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base and their workflow by implementing this as well as what ever comes out of the other WG's into our existing release model?
Why do you think I came up with a new brand "FedoraOS" other then to make a clear distinction between this was not Fedora but something new.
Not really we are nine voting members and each of us could select one application that is in one server role ( or belongs in one but is not listed there ) and write prd's about that application ( home assignment ).
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 )
Service packs sound interesting, but need more information to say for sure. Are you seeing this as something like a point release? where all the updates are rolled up and tested as a group, then people can upgrade to x.1, x.2, etc? How often would this happen? Additionally we would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't people who want those just apply updates as they come out?
Here things start to get interesting complicated and are in heavy state of flux since I have reach the conclusion that
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 )
B) FOSSP needs to be on it's own release cycle as in different from the FOS as well as the Server Roles themselves
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 )
Thanks for writing things up... helps as a way to start more discussion
And hopefully sort things out in the process.
JBG
On 11/12/2013 09:41 PM, "Jóhann B. Guðmundsson" wrote:
For example I create this [1] in sometime in July, ( as well as briefly mention this to Bill over beer at flock ) I asked the kernel community about a new naming scheme in ( related to this ) and few other things here and there.
The missing [1]
1. https://fedoraproject.org/wiki/User:Johannbg/Systemd/systemd-rebase
Updating to more current systemd releases is, generally, safe. However, we're going through a ton of transitions right now, including the cgroups refactor, the move to systemd-bus (to prep for the kdbus move), and network management. While none of these explicitly break backward compatibility, they have introduced temporary stability issues. I'd worry about tracking upstream too closely for a server OS. Also, RHEL will have to have some answer for this, too.
On 11/13/2013 05:08 AM, David Timothy Strauss wrote:
Updating to more current systemd releases is, generally, safe. However, we're going through a ton of transitions right now, including the cgroups refactor, the move to systemd-bus (to prep for the kdbus move), and network management. While none of these explicitly break backward compatibility, they have introduced temporary stability issues. I'd worry about tracking upstream too closely for a server OS. Also, RHEL will have to have some answer for this, too.
RHEL only has to have answers for RHEL and in relation to Fedora/RH and LTS, a while back ( 2011 and earlish 2012 ) I looked at bit into Fedora and an long term support release with to come up with a mutual beneficial long time supported egosystem proposal within specific parameters which would benefit not only us to but as well to RH as well as it clones due to that corporates entity's endosymbiosis relationship with us.
However people seem not have reach the point to ask themselves one significant question in the relation to Fedora server releases and RHEL. If and when that question will be asked I will provide one proposal how that can be addressed since it requires a significant alteration on RH end to be able to achieve it.
And at at that point in time people might be more open to making actual changes as opposed to paint things pinks instead of blue which seems to be taking place with the WG effort.
Now Systemd has been in state of flux and will be in a state of flux while there is room for progress, innovation and improvement much like the kernel and other bits, which is why there exist an release and a long time maintained release in the first place for most component out there.
That is one of the reason why FOS needs to be on it's release cycle,which in turn is tied with the kernel so when the kernel has an lts release so does FOS and the components it's made up of.
JBG
On Tue, 12 Nov 2013 21:41:34 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
...snip...
I'll say again that I don't think we should provide kickstarts. Additionally, I don't think we should try and provide images for every featured stack. I'd prefer something like the netinstall iso with anaconda tweaked for server use, and groups for package stacks.
I disagree ( with the exception of point you make about anaconda which I agree with )
And here's why...
ks files are easy to maintain. ks files area easy to deploy ks files are easy to adapt ks files are ready to use in already existing infrastructures. No additional learning curve for "new format" for existing administrators to learn since they are already familiar with ks syntax. Dnf in the distant future could use them to directly install into ( os ) containers Minimal code changes would be needed for Anaconda.
Releasing a full blown iso ( with each role ) makes no sense while ready to use virtual images for the cloud or just virtualsation in general however does.
I even shall go as far as saying ks files should be our primary release format ( or atleast the first one we implement )
I strongly disagree, and here's why: :)
First, what would be the difference between say (for example) the MariaDB and Postgresl kickstart files? Would it just be the things listed in the %packages section? or changes beyond that?
If it's just in the packages section, we aren't adding any value there. Users could as easily click that role in the installer, or use their own kickstart with their more detailed local config. Or yum/dnf install it after the fact. Shipping our kickstart there just means more deliverables for us that no one would use.
If it's more than just the packages section, then we are making it so you can only install roles via this method and can't easily do so after the install. If you install MariaDB role and want to add say Corosync how do you do that?
If we instead have (at most) one ks file (just for the base install/our best practices), and use comps groups for all the roles, it will instead be easy to mix and match as many or as few roles as the end user wants.
Additionally, comps groups would be portable to the other working groups deliverables. In cases where say a workstation user wanted to install mariadb to test something, they could easy do so. If we delivered a kickstart they could not.
We should talk with the Cloud WG and confirm what stuff they want to handle and what they would like us to handle as well.
Quite frankly I dont grasp that separation there never should have been an cloud WG to begin with.
Matt could have gotten what he wanted quite easily without it from my pov.
Both the hosting and the creation belongs within the server community.
ok, thats a valid point of view. However, we have what we have, so we should communicate with them and see what we can work out.
I like the idea of getting something/fedup to provide some kind of 'before upgrade' report that can point out problems.
Dont forget the missing infrastructure or web tool which helps administrators to dermine which server roles they are looking after and should deploy
This could just be organized in comps so it's clear... perhaps using a server keyword or something higher level.
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base and their workflow by implementing this as well as what ever comes out of the other WG's into our existing release model?
As opposed to? I think building on what parts of what we have that are still good for our needs is a much better idea than burning down everything and building new stuff that is very similar, or serves the same purpose.
Why do you think I came up with a new brand "FedoraOS" other then to make a clear distinction between this was not Fedora but something new.
No idea. I have not seen your FedoraOS proposal.
Not really we are nine voting members and each of us could select one application that is in one server role ( or belongs in one but is not listed there ) and write prd's about that application ( home assignment ).
Only if we all agree this is the way to go.
I think 9 or 15 roles is going to be a lot of work, and not sure if we will be able to handle that. But perhaps it's good to start big and work from there.
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?
Service packs sound interesting, but need more information to say for sure. Are you seeing this as something like a point release? where all the updates are rolled up and tested as a group, then people can upgrade to x.1, x.2, etc? How often would this happen? Additionally we would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't people who want those just apply updates as they come out?
Here things start to get interesting complicated and are in heavy state of flux since I have reach the conclusion that
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? The kernel is one of the more stable parts of the platform, and it's release cycle is somewhat fluid. Additionally, lots of the time people don't see much change there with new stuff.
B) FOSSP needs to be on it's own release cycle as in different from the FOS as well as the Server Roles themselves
I think there's a number of disadvantages to splitting out release cycles per product. I guess it will somewhat depend on what the Base group decides on. Having seperate releases means that the different products can't share things like freezes, press cycles, testing of some components, etc.
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 ?
kevin
On 11/13/2013 04:19 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 21:41:34 +0000 "Jóhann B. Guðmundsson"johannbg@gmail.com wrote:
...snip...
I'll say again that I don't think we should provide kickstarts. Additionally, I don't think we should try and provide images for every featured stack. I'd prefer something like the netinstall iso with anaconda tweaked for server use, and groups for package stacks.
I disagree ( with the exception of point you make about anaconda which I agree with )
And here's why...
ks files are easy to maintain. ks files area easy to deploy ks files are easy to adapt ks files are ready to use in already existing infrastructures. No additional learning curve for "new format" for existing administrators to learn since they are already familiar with ks syntax. Dnf in the distant future could use them to directly install into ( os ) containers Minimal code changes would be needed for Anaconda.
Releasing a full blown iso ( with each role ) makes no sense while ready to use virtual images for the cloud or just virtualsation in general however does.
I even shall go as far as saying ks files should be our primary release format ( or atleast the first one we implement )
I strongly disagree, and here's why: :)
First, what would be the difference between say (for example) the MariaDB and Postgresl kickstart files? Would it just be the things listed in the %packages section? or changes beyond that?
Changes beyond. ( otherwise this entire server wg effort is meaningless )
In other words simply doing yum install MariaDB on Fedora != the same experience as deploying FOSSP with the MariaDB in a Database Role via our delivery methods.
If it's just in the packages section, we aren't adding any value there. Users could as easily click that role in the installer, or use their own kickstart with their more detailed local config. Or yum/dnf install it after the fact. Shipping our kickstart there just means more deliverables for us that no one would use.
If it's more than just the packages section, then we are making it so you can only install roles via this method and can't easily do so after the install.
Yes that is the purpose we are delivering best out of the box experience in server roles.
If you install MariaDB role and want to add say Corosync how do you do that?
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.
If we instead have (at most) one ks file (just for the base install/our best practices), and use comps groups for all the roles, it will instead be easy to mix and match as many or as few roles as the end user wants.
Additionally, comps groups would be portable to the other working groups deliverables. In cases where say a workstation user wanted to install mariadb to test something, they could easy do so. If we delivered a kickstart they could not.
For the first we are not going to be play mix match with what ever the workstation or other WG comes up with and what we are working on.
We should talk with the Cloud WG and confirm what stuff they want to handle and what they would like us to handle as well.
Quite frankly I dont grasp that separation there never should have been an cloud WG to begin with.
Matt could have gotten what he wanted quite easily without it from my pov.
Both the hosting and the creation belongs within the server community.
ok, thats a valid point of view. However, we have what we have, so we should communicate with them and see what we can work out.
Yeah sure we can try that.
I like the idea of getting something/fedup to provide some kind of 'before upgrade' report that can point out problems.
Dont forget the missing infrastructure or web tool which helps administrators to dermine which server roles they are looking after and should deploy
This could just be organized in comps so it's clear... perhaps using a server keyword or something higher level.
No it cannot so ignore comps altogether we need alternative route and this tool is entirely outside comps what so ever.
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.
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base and their workflow by implementing this as well as what ever comes out of the other WG's into our existing release model?
As opposed to? I think building on what parts of what we have that are still good for our needs is a much better idea than burning down everything and building new stuff that is very similar, or serves the same purpose.
We would not be burning down everything Fedora would still be Fedora generically useful or useless depending how you look at it.
FedoraOS as I see it is something we add separately to the side ( at least to begin with ) and has a specific purpose in each of it's "layer".
Why do you think I came up with a new brand "FedoraOS" other then to make a clear distinction between this was not Fedora but something new.
No idea. I have not seen your FedoraOS proposal.
Not really we are nine voting members and each of us could select one application that is in one server role ( or belongs in one but is not listed there ) and write prd's about that application ( home assignment ).
Only if we all agree this is the way to go.
I think 9 or 15 roles is going to be a lot of work, and not sure if we will be able to handle that. But perhaps it's good to start big and work from there.
If you think this is starting big ( I was thinking this was starting small )
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
Service packs sound interesting, but need more information to say for sure. Are you seeing this as something like a point release? where all the updates are rolled up and tested as a group, then people can upgrade to x.1, x.2, etc? How often would this happen? Additionally we would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't people who want those just apply updates as they come out?
Here things start to get interesting complicated and are in heavy state of flux since I have reach the conclusion that
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.
B) FOSSP needs to be on it's own release cycle as in different from the FOS as well as the Server Roles themselves
I think there's a number of disadvantages to splitting out release cycles per product. I guess it will somewhat depend on what the Base group decides on. Having seperate releases means that the different products can't share things like freezes, press cycles, testing of some components, etc.
I see nothing but advantage in what you see as disadvantage.
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.
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.
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.
JBG
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.
On 11/13/2013 08:45 PM, Simo Sorce wrote:
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.
Explain in further detail.
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.
Yeah understandably so thunderbird is freezing and failing faster, crashing harder here on F20 beta so I'm retyping ever thing so often.
In anycase we are no way near what I was referring to so you can just ice that thought for now.
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 ?
Depends on how we move forward and how you look at this.
So far a lot seem to be viewing and wanting to mutual existing Fedora into the outcome of all the WG while re-using the same base to most extent ( which is what we are doing already so why are we bothering with this effort)
I do not share that vision and I actually thought this whole effort was about a change.
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 ?
With my QA hat on I would actually it would be more reliably then those bits are now separated.
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 ?
Minimal expectation of an maintenance scheme for an server application to be applicable to an server role is something we define together as well of the rest of server roles expectations.
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.
Re-stating ( since it's one of our role as an WG ).
" Minimal expectation of an maintenance scheme for an server application to be applicable to an server role is something we define together as well of the rest of server roles expectations."
JBG
On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 16:32:13 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote: Is FOS (Fedora OS) the product from our base working group? Or something else?
That depends heavily on the outcome of the base working group but as things stand now what they have discussed and how I see us moving forward to the future are quite different.
That kind of defeats the point of having a "base" group. Where will we find extra maintainers for doing the same kind of work one more time for the two "quite different" bases?
I'd not list some of those specific things FOSSP 'consists' of, as they may be decided by the base working group. Perhaps we switch from dracut to something else someday, etc. Additionally, some of them are subject to debate.
Of course that list was just a list to start
I'd rather have a fairly small list of things we guarantee to keep compatible, driven "top-down" by what the sysadmins will need to interact with, rather than "bottom-up" from the upstream components. Implicitly importing every feature a project may implement wholesale would be fairly restrictive if we ever wanted to change or replace the implementation of any particular feature.
I'll say again that I don't think we should provide kickstarts. Additionally, I don't think we should try and provide images for every featured stack. I'd prefer something like the netinstall iso with anaconda tweaked for server use, and groups for package stacks.
I disagree ( with the exception of point you make about anaconda which I agree with )
And here's why...
ks files are easy to maintain.
Not the ks files I have seen; they are at least as difficult as shell scripts, with the added difficulty that you can't easily test them without firing up a scratch machine (VM if you are lucky) and waiting for the installation to finish.
ks files area easy to deploy
Only if you PXE already setup.
ks files are easy to adapt
They mix many of different kinds of information into a single file (you can split it into more than one file but there's no standard way to do it, so every site differs and tools can't help).
ks files are ready to use in already existing infrastructures. No additional learning curve for "new format" for existing administrators to learn since they are already familiar with ks syntax. Dnf in the distant future could use them to directly install into ( os ) containers Minimal code changes would be needed for Anaconda.
Releasing a full blown iso ( with each role ) makes no sense while ready to use virtual images for the cloud or just virtualsation in general however does.
I even shall go as far as saying ks files should be our primary release format ( or atleast the first one we implement )
I'd much prefer if the configuration management method / file formats were, ideally, exactly the same for installation and post-install configuration changes: Same GUI interface, same $puppet_or_ther_config_mechanism file format and structure, only a different command/method to deploy them.
Not only it should be possible to add a role post-install, it should be possible to configure the role using exactly the same tools / interfaces (having only one set of documentation, and only one implementation to test).
Kickstart might be a way to ultimately make the installation happen, or something we can ship to allow quickly installing a "clean, non-configured" role on a new server, but I don't think it's a suitable user interaction method for the common case.
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base and their workflow by implementing this as well as what ever comes out of the other WG's into our existing release model?
I was expecting that "the default" is that the existing RPMs managed in dist-git continue to exist, and we will continue to make it possible to install them (or, perhaps, some fairly large subset of them) on the future Fedora Server. So, even if we didn't ship any mail server role in Fedora Server 1.0, existing users could install the same kind of RPMs as in the past, and configure using them the same way as in the past. (Well, the users might have to click once or twice to say "yes, I really want to set up a server with none of the nice roles", or something similar.)
I don't currently see any need to noticeably disrupt the existing user base and workflow for the areas where we don't manage to implement server roles. (I'm not sure about the areas where we do implement server roles - I could imagine that our integrated setup would make some possible deployments of the upstream project that differ from the Fedora Server model more difficult to set up, but that's purely theoretical at this point.)
Service packs sound interesting, but need more information to say for sure. Are you seeing this as something like a point release? where all the updates are rolled up and tested as a group, then people can upgrade to x.1, x.2, etc? How often would this happen? Additionally we would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't people who want those just apply updates as they come out?
Here things start to get interesting complicated and are in heavy state of flux since I have reach the conclusion that
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 )
I think there are far too many upstreams that may make a big difference to the release to tie us into a single project. Looking back at the past Fedora releases, can you recall a kernel-only ever being the first thing advertised about the release? IIRC it's pretty much always something purely user-space or with a large user-space component.
B) FOSSP needs to be on it's own release cycle as in different from the FOS as well as the Server Roles themselves
"Needs"? Why? As a heuristic, keeping a synchronized release cycle would allow us to avoid testing cross-release interactions (we'd test FOS 1+FOSSP 1, and FOS 2+FOSSP 2, but not FOS 2 + FOSSP 1), so is "by default" more preferable to me.
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 )
Same as B), and for the Fedora Server I'm picturing more integration work than we've done in the past, so being F1rst!!! to package an upstream release doesn't necessarily mean the Fedora Server Role should be immediately release as well. Mirek
On 11/14/2013 11:44 PM, Miloslav Trmač wrote:
On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 16:32:13 +0000 "Jóhann B. Guðmundsson"johannbg@gmail.com wrote: Is FOS (Fedora OS) the product from our base working group? Or something else?
That depends heavily on the outcome of the base working group but as things stand now what they have discussed and how I see us moving forward to the future are quite different.
That kind of defeats the point of having a "base" group. Where will we find extra maintainers for doing the same kind of work one more time for the two "quite different" bases?
The "Base" layer is on top of the "Core" layer and it cannot be shared however the "Core" can and should.
The "Core" needs to cover embedded hence has to be as small as possible, the absolute minimum to deliver running system and this is the only part that can be "shared" if the aim is to have targeted platforms since for example our needs greatly differ from the workstation one thus we ( or they ) would have to start nitpick pieces out from the "Base" layer if it was shared.
FedoraOS is that "Core Layer" of the operating system FedoraOS Server Platform "Is the "Base Layer for servers" what *we* define should be on it and made available to *all* administrator' FedoraOS Server Platform Server Role is the "Server Application Layer" which provides the functionality the administrator is seeking.
The core layer in the GNU/Linux has becoming an ecosystem of it's own with it's own mutual direction with it's own momentum you can try to turn an blind eye to the fact that,that freight train is coming and run when it's far off in the distance and keep running before it catches up with you essentially do what the Debian community does crack open a beer, watch it come and cry "I want the core/base OS bits to be hot swappable!" as their famous last words or you can layout it's tracks and help steer it's direction or simply jump in it, buy a ticket and trust it's engineers while enjoying the ride.
The base Layer for servers is something we design,manage and control and need to different us from other distribution out there to become the server platform of choice for the administrator and that layer needs to be separated from the rest since applications in server roles can come and go as the marked demands it.
Server application layer is made up of application or application stack that each can come and go and each is maintained differently it.
I'd not list some of those specific things FOSSP 'consists' of, as they may be decided by the base working group. Perhaps we switch from dracut to something else someday, etc. Additionally, some of them are subject to debate.
Of course that list was just a list to start
I'd rather have a fairly small list of things we guarantee to keep compatible, driven "top-down" by what the sysadmins will need to interact with, rather than "bottom-up" from the upstream components. Implicitly importing every feature a project may implement wholesale would be fairly restrictive if we ever wanted to change or replace the implementation of any particular feature.
Which is one of the reason why I came to the conclusion that we should keep each FedoraOS in it's own release cycle in it's own repositiory, FedoraOS Server Platform in another and each application in specific Fedora Server Role in their own.
This is a community driven distribution and as such we cannot guarantee anything heck I have yet to see the maintainer even just *one* that is willing to stand behind an long maintained release cycle so we cannot depend on anything or anyone but some people like pretend they can.
I'll say again that I don't think we should provide kickstarts. Additionally, I don't think we should try and provide images for every featured stack. I'd prefer something like the netinstall iso with anaconda tweaked for server use, and groups for package stacks.
I disagree ( with the exception of point you make about anaconda which I agree with )
And here's why...
ks files are easy to maintain.
Not the ks files I have seen; they are at least as difficult as shell scripts,
Hmm perhaps a bit of history lesson is in order here an no one better to tell it other then Bryan Cantrill so I suggest you listen to [¹].
There is a reason why the shell is an administrator tool of chose which plays a big part in the success of the *nix platforms in the servers space.
with the added difficulty that you can't easily test them without firing up a scratch machine (VM if you are lucky) and waiting for the installation to finish.
ks files area easy to deploy
Only if you PXE already setup.
Last time I checked you still could perform a ks install in anaconda on a stick or it made somewhere available on the network so ?
ks files are easy to adapt
They mix many of different kinds of information into a single file (you can split it into more than one file but there's no standard way to do it, so every site differs and tools can't help).
It's not cross distributable either, so you know eventually it will die eventually if things continue to progress in certain direction but it fit's an short term goal perfectly.
ks files are ready to use in already existing infrastructures. No additional learning curve for "new format" for existing administrators to learn since they are already familiar with ks syntax. Dnf in the distant future could use them to directly install into ( os ) containers Minimal code changes would be needed for Anaconda.
Releasing a full blown iso ( with each role ) makes no sense while ready to use virtual images for the cloud or just virtualsation in general however does.
I even shall go as far as saying ks files should be our primary release format ( or atleast the first one we implement )
I'd much prefer if the configuration management method / file formats were, ideally, exactly the same for installation and post-install configuration changes: Same GUI interface, same $puppet_or_ther_config_mechanism file format and structure, only a different command/method to deploy them.
As an long term to goal ( 5 years time ) to achieve sure but in the meantime we need something and that something is ks.
Not only it should be possible to add a role post-install, it should be possible to configure the role using exactly the same tools / interfaces (having only one set of documentation, and only one implementation to test).
Again you cannot achieve this if our end goal is to go provide the "best experience" because we cannot tune the installation to mix match of roles ( and quite frankly in today's age mixing roles is something that sounds more like and old habit ).
You cannot tune a database server and for example a web server on the same host heck you don't even partition these in a filesystem level the same and today is that really necessary.
Kickstart might be a way to ultimately make the installation happen, or something we can ship to allow quickly installing a "clean, non-configured" role on a new server, but I don't think it's a suitable user interaction method for the common case.
Common/generic is the problem here , which is an place we already are at so why this effort if we are not going that extra mile that extra length to separate us from the masses?
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base and their workflow by implementing this as well as what ever comes out of the other WG's into our existing release model?
I was expecting that "the default" is that the existing RPMs managed in dist-git continue to exist, and we will continue to make it possible to install them (or, perhaps, some fairly large subset of them) on the future Fedora Server. So, even if we didn't ship any mail server role in Fedora Server 1.0, existing users could install the same kind of RPMs as in the past, and configure using them the same way as in the past. (Well, the users might have to click once or twice to say "yes, I really want to set up a server with none of the nice roles", or something similar.)
I dont expect that I expect us to cherry pick application throw them through a migration process and become an application that files a specific role in FOSSP in fact I expect that for each "layer" and we clean things up in the process and make us agile again while doing so under another brand FedoraOS to keep the separation clear and without disrupting our existing Fedora userbase or the workflow they have gotten used to.
If you want something generic where you can install *anything* use Fedora however if you want something that serves a specific purpose use "FedoraOS"
I don't currently see any need to noticeably disrupt the existing user base and workflow for the areas where we don't manage to implement server roles. (I'm not sure about the areas where we do implement server roles - I could imagine that our integrated setup would make some possible deployments of the upstream project that differ from the Fedora Server model more difficult to set up, but that's purely theoretical at this point.)
We have become this big slow elephant glue together and thrown on the floor like a pile of packed spaghetti mess and we are as agile in IT industry as that pile of mess.
I thought "fedora.next" was an effort to try to turn the tide around and change that. Putting first back into Fedora not in the sense necessary of latest and the greatest from upstream but more in the sense, on top leading, not keep things, under the same old outdated mentality, the same outdate ways of doing things so if the intent is to keep things the same I really is not worthwhile for *anybody* participating in this effort.
Quite frankly looking at our whole ecosystem what we need is a generation change to flush out that outdated way's of thinking perhaps that's what's is slowly making us irrelevant and obsolete.
Anyway to be able to clean us up and make us agile again we need to keep that work separated from "Generic Fedora" because it will cause disruption and yes I'm aware of what that means work wise but it's absolutely necessary for us to do, to succeed in the long run.
Service packs sound interesting, but need more information to say for sure. Are you seeing this as something like a point release? where all the updates are rolled up and tested as a group, then people can upgrade to x.1, x.2, etc? How often would this happen? Additionally we would need a way to decide if something is Critical or not.
I'm not sure minor (x.x.1, x.x.2) releases add much value. Wouldn't people who want those just apply updates as they come out?
Here things start to get interesting complicated and are in heavy state of flux since I have reach the conclusion that
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 )
I think there are far too many upstreams that may make a big difference to the release to tie us into a single project. Looking back at the past Fedora releases, can you recall a kernel-only ever being the first thing advertised about the release? IIRC it's pretty much always something purely user-space or with a large user-space component.
Not following your thought process here if I'm understanding that correctly you can apply that argument to the entire distribution it would just be x12000
B) FOSSP needs to be on it's own release cycle as in different from the FOS as well as the Server Roles themselves
"Needs"? Why? As a heuristic, keeping a synchronized release cycle would allow us to avoid testing cross-release interactions (we'd test FOS 1+FOSSP 1, and FOS 2+FOSSP 2, but not FOS 2 + FOSSP 1), so is "by default" more preferable to me.
Actually with my QA hat on FOS/FOSSP/FOSSR will break making things more manageable pieces for us in QA.
There is but one "FOS" there are 2 other ( base ) layers on top of that, the FOSSP and FOSW ( workstation ) ( or FOSD desktop depending on how you view those things ). The cloud stuff really falls under us and that SCL is being driven in the wrong direction and that direction actually slows down progress in certain are instead of enhancing 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 )
Same as B), and for the Fedora Server I'm picturing more integration work than we've done in the past, so being F1rst!!! to package an upstream release doesn't necessarily mean the Fedora Server Role should be immediately release as well.
Absolutely agree here.
On Fri, 2013-11-15 at 12:04 +0000, "Jóhann B. Guðmundsson" wrote:
Again you cannot achieve this if our end goal is to go provide the "best experience" because we cannot tune the installation to mix match of roles ( and quite frankly in today's age mixing roles is something that sounds more like and old habit ).
You cannot tune a database server and for example a web server on the same host heck you don't even partition these in a filesystem level the same and today is that really necessary.
Sorry Jóhann, but this statement made me clear we need to take a step back.
Can you tell me who you target with your vision of a Server OS ?
Because creating a server with database and web server on the same machine is what I do *regularly*. If you know tell me I can't do that you are telling me Fedora Server is not for me (and for many other people that have *one* beefy machine available not a whole data center).
I think we are on completely different tracks here and need to really create the "personas" you so much didn't want to because it is clear we are not agreeing on who is the target of this exercise.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2013 08:19 AM, Simo Sorce wrote:
On Fri, 2013-11-15 at 12:04 +0000, "Jóhann B. Guðmundsson" wrote:
Again you cannot achieve this if our end goal is to go provide the "best experience" because we cannot tune the installation to mix match of roles ( and quite frankly in today's age mixing roles is something that sounds more like and old habit ).
You cannot tune a database server and for example a web server on the same host heck you don't even partition these in a filesystem level the same and today is that really necessary.
Sorry Jóhann, but this statement made me clear we need to take a step back.
Can you tell me who you target with your vision of a Server OS ?
Because creating a server with database and web server on the same machine is what I do *regularly*. If you know tell me I can't do that you are telling me Fedora Server is not for me (and for many other people that have *one* beefy machine available not a whole data center).
I think we are on completely different tracks here and need to really create the "personas" you so much didn't want to because it is clear we are not agreeing on who is the target of this exercise.
I think what Jóhann is saying is that we should be promoting the use of separate VMs/Containers/<pick_your_tech> on the Fedora Server such that each role is entirely isolated from one another. I don't think that the physical location is necessarily relevant.
That being said, I think you're right that we should step back and discuss target audience and deployment goals FIRST and then focus on implementation after.
I'll start a new thread on that.
On 11/15/2013 01:23 PM, Stephen Gallagher wrote:
I think what Jóhann is saying is that we should be promoting the use of separate VMs/Containers/<pick_your_tech> on the Fedora Server such that each role is entirely isolated from one another. I don't think that the physical location is necessarily relevant.
Precisely.
JBG
On Fri, Nov 15, 2013 at 1:04 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/14/2013 11:44 PM, Miloslav Trmač wrote:
On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 16:32:13 +0000 "Jóhann B. Guðmundsson"johannbg@gmail.com wrote: Is FOS (Fedora OS) the product from our base working group? Or something else?
That depends heavily on the outcome of the base working group but as things stand now what they have discussed and how I see us moving forward to the future are quite different.
That kind of defeats the point of having a "base" group. Where will we find extra maintainers for doing the same kind of work one more time for the two "quite different" bases?
<snip>
FedoraOS is that "Core Layer" of the operating system FedoraOS Server Platform "Is the "Base Layer for servers" what *we* define should be on it and made available to *all* administrator'
Never mind the naming, what's the point of the base WG if we won't use what they produce?
I'd rather have a fairly small list of things we guarantee to keep compatible, driven "top-down" by what the sysadmins will need to interact with, rather than "bottom-up" from the upstream components. Implicitly importing every feature a project may implement wholesale would be fairly restrictive if we ever wanted to change or replace the implementation of any particular feature.
Which is one of the reason why I came to the conclusion that we should keep each FedoraOS in it's own release cycle in it's own repositiory, FedoraOS Server Platform in another and each application in specific Fedora Server Role in their own.
I can't see how release cycles and repositories (which are pretty much per-package) are related to the concern that per-package stability promises may not be what we want.
ks files are easy to maintain.
Not the ks files I have seen; they are at least as difficult as shell scripts,
Hmm perhaps a bit of history lesson is in order here an no one better to tell it other then Bryan Cantrill so I suggest you listen to [¹].
There is a reason why the shell is an administrator tool of chose which plays a big part in the success of the *nix platforms in the servers space.
Yes, primarily, "you don't have any other option". (Insert rant about shell making the rare things easy and the common things difficult, starting with quoting variable expansions.)
Regardless whether shell is a good language or not, it is a _language_, hence impossible to generally manage with higher-level software.
ks files area easy to deploy
Only if you PXE already setup.
Last time I checked you still could perform a ks install in anaconda on a stick
Right, I forgot about that option.
Kickstart might be a way to ultimately make the installation happen, or something we can ship to allow quickly installing a "clean, non-configured" role on a new server, but I don't think it's a suitable user interaction method for the common case.
Common/generic is the problem here , which is an place we already are at so why this effort if we are not going that extra mile that extra length to separate us from the masses?
I think "write a kickstart shell script" or "set up your own puppet-based management infrastructure" is exactly where we are at. We can go many extra miles further from there :)
The server roles section has a number of things that should be debated before being decided on, IMHO. For an inital f21 timeframe we should again look at just a few, IMHO.
You are not seriously suggesting that we disrupt our existing user base and their workflow by implementing this as well as what ever comes out of the other WG's into our existing release model?
I was expecting that "the default" is that the existing RPMs managed in dist-git continue to exist, and we will continue to make it possible to install them (or, perhaps, some fairly large subset of them) on the future Fedora Server. So, even if we didn't ship any mail server role in Fedora Server 1.0, existing users could install the same kind of RPMs as in the past, and configure using them the same way as in the past. (Well, the users might have to click once or twice to say "yes, I really want to set up a server with none of the nice roles", or something similar.)
I dont expect that I expect us to cherry pick application throw them through a migration process and become an application that files a specific role in FOSSP in fact I expect that for each "layer" and we clean things up in the process and make us agile again while doing so under another brand FedoraOS to keep the separation clear and without disrupting our existing Fedora userbase or the workflow they have gotten used to.
"Sometimes you get to do a complete reboot, and when you can, it's a beautiful thing" (or something like that, I can't find the exact quote about Java). Yes, I'm also maintaining a list of items a from-the-ground-up-rewritten-and-cleaned-up OS should have (starting with a better language, and a real common runtime so that there aren't hundreds of string and hashing libraries, and on from there).
I'm afraid Fedora.next isn't that complete-cleanup OS though. 1) We don't have the consensus on the need to reinvent. ("kickstarts/puppet/shell/X11/fork()/... work just fine, thank you") 2) We don't have the manpower and time. It took ~10 years for Linux to become reasonably-feature complete, with a world-wide collaboration pretty much on one project, _which was sorely needed because nothing like it existed_. We don't have 10 years, we are one project among many, and everyone has other options (perhaps not as good but better than spending a month programming a missing component). 3) The various upstreams will continue expanding and modifying the "Linux" ecosystem faster than we can "clean it up" for FedoraOS.
(Or perhaps you have a much more limited "clean up" in mind?)
I don't currently see any need to noticeably disrupt the existing user base and workflow for the areas where we don't manage to implement server roles. (I'm not sure about the areas where we do implement server roles - I could imagine that our integrated setup would make some possible deployments of the upstream project that differ from the Fedora Server model more difficult to set up, but that's purely theoretical at this point.)
We have become this big slow elephant glue together and thrown on the floor like a pile of packed spaghetti mess and we are as agile in IT industry as that pile of mess.
I thought "fedora.next" was an effort to try to turn the tide around and change that. Putting first back into Fedora not in the sense necessary of latest and the greatest from upstream but more in the sense, on top leading, not keep things, under the same old outdated mentality, the same outdate ways of doing things so if the intent is to keep things the same I really is not worthwhile for *anybody* participating in this effort.
Quite frankly looking at our whole ecosystem what we need is a generation change to flush out that outdated way's of thinking perhaps that's what's is slowly making us irrelevant and obsolete.
The trouble is that flushing out that outdated ways of thinking automatically implies flushing out all the working software with no replacement but well-intentioned ideas. So I think we can practically only choose _specific areas that matter to us_ (perhaps configuration and monitoring) and fix those, and _only_ those.
Perhaps, sometime somewhere, someone will start from scratch, and design a complete new thing that is so great that the community will eventually migrate, but I honestly can't see that. I've seen far too many "this is my hobby OS kernel that has better API than Linux", "this is my hobby language that is better than C++ and Java", "this is my better IPC", "this is my unified configuration library" projects that have had no chance to ever gather critical mass.
Of course, that leads to the question "why can't Fedora lead the change? It is big enough after all". Yes, perhaps it is big enough, but _only if we stay as big as we are_, not if we throw out all existing packages and then try to introduce a new mechanism from the position of a big distribution while actually being one of the smallest ones.
Anyway to be able to clean us up and make us agile again we need to keep that work separated from "Generic Fedora" because it will cause disruption and yes I'm aware of what that means work wise but it's absolutely necessary for us to do, to succeed in the long run.
I don't think it's necessary, any more. It might have been necessary 5 years ago, but now the kernel has enough namespacing technology (... which I otherwise... don't like) that it's fairly feasible to keep compatibility. For example, create /FedoraOld1/{bin,etc,usr,...}, let the old system live in there, and take over / for the all new design. (FedoraOld1 because there _will_ be FedoraOld2; we wouldn't get it exactly right either.)
Anyway, to me this is all hypothetical at this point - we might need a disruptive change some time, but until we are actually faced with an user-visible functionality that needs one we shouldn't let the possibility of disruption stop us from getting non-disruptive work done. Mirek
On 11/16/2013 12:34 AM, Miloslav Trmač wrote:
On Fri, Nov 15, 2013 at 1:04 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/14/2013 11:44 PM, Miloslav Trmač wrote:
On Tue, Nov 12, 2013 at 10:41 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/12/2013 08:12 PM, Kevin Fenzi wrote:
On Tue, 12 Nov 2013 16:32:13 +0000 "Jóhann B. Guðmundsson"johannbg@gmail.com wrote: Is FOS (Fedora OS) the product from our base working group? Or something else?
That depends heavily on the outcome of the base working group but as things stand now what they have discussed and how I see us moving forward to the future are quite different.
That kind of defeats the point of having a "base" group. Where will we find extra maintainers for doing the same kind of work one more time for the two "quite different" bases?
<snip> > FedoraOS is that "Core Layer" of the operating system > FedoraOS Server Platform "Is the "Base Layer for servers" what *we* define > should be on it and made available to *all* administrator' Never mind the naming, what's the point of the base WG if we won't use what they produce?
As I see it they would handle the core ( think comps minimal here ) not base since base is something that cannot be shared.
I'd rather have a fairly small list of things we guarantee to keep compatible, driven "top-down" by what the sysadmins will need to interact with, rather than "bottom-up" from the upstream components. Implicitly importing every feature a project may implement wholesale would be fairly restrictive if we ever wanted to change or replace the implementation of any particular feature.
Which is one of the reason why I came to the conclusion that we should keep each FedoraOS in it's own release cycle in it's own repositiory, FedoraOS Server Platform in another and each application in specific Fedora Server Role in their own.
I can't see how release cycles and repositories (which are pretty much per-package) are related to the concern that per-package stability promises may not be what we want.
Community driven distribution cannot promise stability of any sort.
The only thing they can promise is best effort.
ks files are easy to maintain.
Not the ks files I have seen; they are at least as difficult as shell scripts,
Hmm perhaps a bit of history lesson is in order here an no one better to tell it other then Bryan Cantrill so I suggest you listen to [¹].
There is a reason why the shell is an administrator tool of chose which plays a big part in the success of the *nix platforms in the servers space.
Yes, primarily, "you don't have any other option". (Insert rant about shell making the rare things easy and the common things difficult, starting with quoting variable expansions.)
Regardless whether shell is a good language or not, it is a _language_, hence impossible to generally manage with higher-level software.
Not disagreeing here
Common/generic is the problem here , which is an place we already are at so why this effort if we are not going that extra mile that extra length to separate us from the masses?
I think "write a kickstart shell script" or "set up your own puppet-based management infrastructure" is exactly where we are at. We can go many extra miles further from there :)
Yes long term short term to actually start delivering $something we should use what exist.
"Sometimes you get to do a complete reboot, and when you can, it's a beautiful thing" (or something like that, I can't find the exact quote about Java). Yes, I'm also maintaining a list of items a from-the-ground-up-rewritten-and-cleaned-up OS should have (starting with a better language, and a real common runtime so that there aren't hundreds of string and hashing libraries, and on from there).
I'm afraid Fedora.next isn't that complete-cleanup OS though.
- We don't have the consensus on the need to reinvent.
("kickstarts/puppet/shell/X11/fork()/... work just fine, thank you") 2) We don't have the manpower and time. It took ~10 years for Linux to become reasonably-feature complete, with a world-wide collaboration pretty much on one project, _which was sorely needed because nothing like it existed_. We don't have 10 years, we are one project among many, and everyone has other options (perhaps not as good but better than spending a month programming a missing component). 3) The various upstreams will continue expanding and modifying the "Linux" ecosystem faster than we can "clean it up" for FedoraOS.
(Or perhaps you have a much more limited "clean up" in mind?)
Limited to the distribution it's packaging and the selected component that make up FedoraOS, FOSSP and each application it it's server role etc.
Quite frankly looking at our whole ecosystem what we need is a generation change to flush out that outdated way's of thinking perhaps that's what's is slowly making us irrelevant and obsolete.
The trouble is that flushing out that outdated ways of thinking automatically implies flushing out all the working software with no replacement but well-intentioned ideas.
How do you come to that conclusion? ( I'm talking about those making decisions in Fedora lacking fresh mindset/ideas and perspective )
So I think we can practically only choose _specific areas that matter to us_ (perhaps configuration and monitoring) and fix those, and _only_ those.
Perhaps, sometime somewhere, someone will start from scratch, and design a complete new thing that is so great that the community will eventually migrate, but I honestly can't see that. I've seen far too many "this is my hobby OS kernel that has better API than Linux", "this is my hobby language that is better than C++ and Java", "this is my better IPC", "this is my unified configuration library" projects that have had no chance to ever gather critical mass.
Of course, that leads to the question "why can't Fedora lead the change? It is big enough after all". Yes, perhaps it is big enough, sbut _only if we stay as big as we are_, not if we throw out all existing packages and then try to introduce a new mechanism from the position of a big distribution while actually being one of the smallest ones.
Keeping these two things separated ( Fedora vs FedoraOS ) we wont be throwing out anything. We simply will be choosing existing bits cleaning them up, intergrade them better with one another ( if applicable ) and place them in FedoraOS
Anyway to be able to clean us up and make us agile again we need to keep that work separated from "Generic Fedora" because it will cause disruption and yes I'm aware of what that means work wise but it's absolutely necessary for us to do, to succeed in the long run.
I don't think it's necessary, any more. It might have been necessary 5 years ago, but now the kernel has enough namespacing technology (... which I otherwise... don't like) that it's fairly feasible to keep compatibility. For example, create /FedoraOld1/{bin,etc,usr,...}, let the old system live in there, and take over / for the all new design. (FedoraOld1 because there _will_ be FedoraOld2; we wouldn't get it exactly right either.)
This will just lead to a mess for everybody...
JBG
On Sat, 2013-11-16 at 13:23 +0000, "Jóhann B. Guðmundsson" wrote:
As I see it they would handle the core ( think comps minimal here ) not base since base is something that cannot be shared.
I wonder how many people share this idea, so far it seem to me you are the only one that thinks we are forking the distribution in 2/3 independent projects.
To be perfectly clear I did not sign up to fork the distribution, and it is not my understanding of what the 3 products are.
Community driven distribution cannot promise stability of any sort.
Sorry but this is simply untrue, Debian has a recurring release that is stable and relatively well maintained.
The only thing they can promise is best effort.
And that is fine, nobody is asking for miracles.
Quite frankly looking at our whole ecosystem what we need is a generation change to flush out that outdated way's of thinking perhaps that's what's is slowly making us irrelevant and obsolete.
The trouble is that flushing out that outdated ways of thinking automatically implies flushing out all the working software with no replacement but well-intentioned ideas.
How do you come to that conclusion?
( I'm talking about those making decisions in Fedora lacking fresh mindset/ideas and perspective )
Because experience tells us, we've seen already a few generations of young revolutionaries, and yes sometimes they do achieve something great, but those are the exceptions, the vast majority of people that decided to 'start from scratch' ends up badly. So we may look conservative to you, that is fine by me.
Keeping these two things separated ( Fedora vs FedoraOS ) we wont be throwing out anything. We simply will be choosing existing bits cleaning them up, intergrade them better with one another ( if applicable ) and place them in FedoraOS
I wonder if you have a blind spot or are intentionally ignoring the magnitude of work because you give it for granted. We can achieve some success only through the collaboration of a *large* group of people, if every subgroup decides to redo all the work, we go nowhere, because the packaging work, the testing etc.. is the *hard* part done in the distribution. And you are in essence proposing we start from scratch, I am not on that boat.
Simo.
On 11/16/2013 02:24 PM, Simo Sorce wrote:
On Sat, 2013-11-16 at 13:23 +0000, "Jóhann B. Guðmundsson" wrote:
As I see it they would handle the core ( think comps minimal here ) not base since base is something that cannot be shared.
I wonder how many people share this idea, so far it seem to me you are the only one that thinks we are forking the distribution in 2/3 independent projects.
To be perfectly clear I did not sign up to fork the distribution, and it is not my understanding of what the 3 products are.
To be perfectly clear I do not care what you signed up for and I myself signup for a very much different reason then you did and in a such a diverse community I assume all of us did since Fedora means different thing to different people which is one of the reason why labelling it has failed all those years and why it will fail again with these WG's where Fedora has been split into "3 product".
For over half a decade I've been part of the QA community were alot of the processes that exist and are in use today because of me ( with the exception of triagers and proven testers where I told people at that time those processes would fail and guess what they did and my failure was thinking I could improve reporting through better documentation with my how to debug process ) on top of that been the feature owner and migratory of the largest controversial change, the migration to a new init systemd which I'm still doing with the knowledge I have to redo all the units again to bring them up to speed.
I've gotten some of Lennart's "fan mail" ending up in my inbox due that work so I know exactly how much people dislike changes/disruption.
Being an ambassador I know how much regular end user hate their desktop disruptions.
I've gone over up to 500 components migrating services/daemons their packaging script, their startup and now looking at cron jobs and when doing so I go through all their bugs to see if someone has filed or migrated initscript so I see a lot about maintainers and maintainership about the packages they own, majority of which are "poorly" maintained even orphaned or with incomplete features even after they have been flagged 100% complete.
I would be amazed during my entire time here with the project if there is not a shit that I have not encountered or discovered and quite frankly I'm amazed sometimes we can release et all.
This entire effort I see as an opportunity to change that from the ground up and I'm willing to do that work single handedly if I have to because it bugs me and bugs me alot how things that should not be broken are broken ( after all I'm only used to deal with packages in the hundred+ range ) and that's a work that I will be doing anyway despite how this entire WG ends up to be.
Now the only way I see to achieve that ( because of what I have seen and what needs to be done to fix it will break stuff for people ) without disrupting existing workflow for our user base is as you put it "fork the distribution" which to me is just moving package a --> cleaning it up putting it into FedoraOS.
Ones that process is over and that the entire WG effort not been proven as failure then we can drop old "Fedora" and rename FedoraOS as Fedora for all I care.
Community driven distribution cannot promise stability of any sort.
Sorry but this is simply untrue, Debian has a recurring release that is stable and relatively well maintained.
Really how familiar are you with Debian inner workings and which components are being well maintained and which not?
The only thing they can promise is best effort.
And that is fine, nobody is asking for miracles.
Well maintainers have shown concern that WG's are signing them up for something that they neither cant nor wont deliver and RH has responded in a board ticket I filed a while back that it wont support LTS release.
I'm pretty sure you dont know that the Thunderbirds maintainer pushed update to F18 knowingly that broke it's integration with Gnome's notification scheme so I dont share the same faith that you do in our maintainers and since the maintainership of components is heavily depend on the individual(s) behind it , where some do really good job of it, others to pretty ok job of it and some poor job of it and some none et all it and knowing that as well as maintainers concerns, keeping the server roles in separated repo makes the most sense since it gives them the ability and *freedom* ( within reasonable boundaries ) to maintain what they think is to the best to heir ability and us in QA to somewhat test their component in the process.
Honestly I dont know why certain people insist that having FOS/FOSSP/FOSSR each on a multiple different release cycle wont work.
I'm pretty sure we can apply something that was in use as early as in the days of Aristotle is in use today and provides us with the math to calculate ahead of time the outcome for each release cycle to be able to organize us and each team ( marketing,releng,qa etc. ) accordingly but maybe I'm missing something...
Quite frankly looking at our whole ecosystem what we need is a generation change to flush out that outdated way's of thinking perhaps that's what's is slowly making us irrelevant and obsolete.
The trouble is that flushing out that outdated ways of thinking automatically implies flushing out all the working software with no replacement but well-intentioned ideas.
How do you come to that conclusion? ( I'm talking about those making decisions in Fedora lacking fresh mindset/ideas and perspective )
Because experience tells us, we've seen already a few generations of young revolutionaries, and yes sometimes they do achieve something great, but those are the exceptions, the vast majority of people that decided to 'start from scratch' ends up badly. So we may look conservative to you, that is fine by me.
Being conservative is one thing and that's fine + I'm not suggesting we are "starting from scratch" entirely.
Keeping these two things separated ( Fedora vs FedoraOS ) we wont be throwing out anything. We simply will be choosing existing bits cleaning them up, intergrade them better with one another ( if applicable ) and place them in FedoraOS
I wonder if you have a blind spot or are intentionally ignoring the magnitude of work because you give it for granted.
Really quite the opposite I would say I'm actually few of the individuals that exactly knows how much pile of shit we have to cleanup in the distribution and the work that is required do so and I'm not expecting us being able to deliver anything usable in the hands of our end users until first time late next year.
We can achieve some success only through the collaboration of a *large* group of people,
True enough but are you sure that large group of people are behind the WG effort et all?
if every subgroup decides to redo all the work, we go nowhere, because the packaging work, the testing etc.. is the *hard* part done in the distribution. And you are in essence proposing we start from scratch,
Not entirely no but I'm well aware since I'm more anal about this stuff then most people about the amount of work required to do things properly.
JBG
On Sat, Nov 16, 2013 at 9:00 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/16/2013 02:24 PM, Simo Sorce wrote:
On Sat, 2013-11-16 at 13:23 +0000, "Jóhann B. Guðmundsson" wrote:
Being an ambassador I know how much regular end user hate their desktop disruptions.
(Then isn't the right thing to do for our users to _avoid_ disruptions, if we could by doing some extra programming and testing?)
This entire effort I see as an opportunity to change that from the ground up and I'm willing to do that work single handedly if I have to because it bugs me and bugs me alot how things that should not be broken are broken ( after all I'm only used to deal with packages in the hundred+ range ) and that's a work that I will be doing anyway despite how this entire WG ends up to be.
Years ago, * I have written an UNIX-like OS kernel * I have written a libc * I have written 90% of a little-optimizing compiler (with the other 90% of getting it production-reliability remaining) ... all over a period of 9 years, and ended up with something overall _vastly inferior_ to the corresponding GNU components, despite a few nice improvements.[1]
So, I feel very confident in saying that an individual or a small group like the Server WG won't change Fedora "from the ground up" without cooperation of the majority of the maintainers.
Now the only way I see to achieve that ( because of what I have seen and what needs to be done to fix it will break stuff for people ) without disrupting existing workflow for our user base is as you put it "fork the distribution" which to me is just moving package a --> cleaning it up putting it into FedoraOS.
Ones that process is over and that the entire WG effort not been proven as failure then we can drop old "Fedora" and rename FedoraOS as Fedora for all I care.
Despite best efforts of everybody working on RHL and Fedora in the past, we have ended up in this situation where you argue that we should start anew. OK, but if the past work has ended up in something that needs to be thrown away, isn't it reasonable to assume that FedoraOS will eventually also end up in something that needs to be thrown away? That seems, if not inevitable, at least highly plausible to me.
OK, so let's do something different: let's design FedoraOS so that at the point that it will have had to be thrown away, we will also have a mechanism to make a more graceful transition. That would be preferable, wouldn't it? But how can we design such a graceful transition mechanism for an unknown time in the future, and be confident in having the right solution, when we can't test it at all for many years to come?
Hence my suggestion: Design Fedora OS with a graceful transition mechanism, and then _apply and test it on the Fedora->FedoraOS transition_. The best of both worlds (Fedora + FedoraOS), tested, reliable.
There are still very many ways to do this: just continue in the existing RPM world and mark some of them as "blessed"/"cleaned up"/"preferred"; fork the filesystem and allow installing both kinds of packages alongside; or something else entirely. Some of them may look more like the FedoraOS proposal; some of them may look completely unlike the FedoraOS proposal. The critical point is to avoid the user disruption and the associated userbase loss.
The only thing they can promise is best effort.
And that is fine, nobody is asking for miracles.
I'm pretty sure you dont know that the Thunderbirds maintainer pushed update to F18 knowingly that broke it's integration with Gnome's notification scheme so I dont share the same faith that you do in our maintainers and since the maintainership of components is heavily depend on the individual(s) behind it , where some do really good job of it, others to pretty ok job of it and some poor job of it
I think the only possible answer here is to automate whatever we can. If there are problems known to be recurring repeatedly, let's create tools that prohibit any checkin/build with that problem; if features go missing, let's write tests to avoid regressions.
Maintainers are (for the most part, in some sense even those paid by RH) volunteers, and we don't get to choose how great a job they do. (... or how great a job some of us do, for that matter; I know I'm not a stellar maintainer.) Still, hundreds of well-meaning but not perfect maintainers can do much more than a 9-person WG, even if it were composed of perfect people.
and some none et all it and knowing that as well as maintainers concerns, keeping the server roles in separated repo makes the most sense since it gives them the ability and *freedom* ( within reasonable boundaries ) to maintain what they think is to the best to heir ability and us in QA to somewhat test their component in the process.
I can't see how separation addresses any of the quality concerns. One could perhaps say "the $role_a repo is really well maintained" and "the $role_b repo is constantly broken" but the same can be equally true, and equally said about, roles living in a shared RPM repository.
Honestly I dont know why certain people insist that having FOS/FOSSP/FOSSR each on a multiple different release cycle wont work.
For me, I see the complexity of managing different releases of Red Hat products that have interdependencies. It can be done, but it's a lot of work and mistakes happen - work and mistakes entirely avoidable by having a single release cycle and one product release instead of multiple interdependent products.
I'm pretty sure we can apply something that was in use as early as in the days of Aristotle is in use today and provides us with the math to calculate ahead of time the outcome for each release cycle to be able to organize us and each team ( marketing,releng,qa etc. ) accordingly but maybe I'm missing something...
What "something" exactly would that be? My experience in FESCo from the endless F18 slip is that we really don't have that much visibility or control; we can certainly improve visibility at least, however let's talk about specific changes (... probably separately from the PRD discussion, later?) instead of vaguely referring to philosophers.
We can achieve some success only through the collaboration of a *large* group of people,
True enough but are you sure that large group of people are behind the WG effort et all?
Giving them something they can get behind is, to a large extent, our task. If we fail at this, the WG will fail. Mirek
[1] It was extremely useful as a learning exercise, I can very much recommend it if you have so much free time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/12/2013 11:32 AM, "Jóhann B. Guðmundsson" wrote:
Few notes about FedoraOS Server Platform ( FOSSP )
Which touches serveral topics we have been discussing.
JBG
I had a long discussion today with Jóhann and I think I took away from it a somewhat better understanding of what it is that he is proposing. We both agreed that his intentions were less than clear due to communication issues (as opposed to necessarily differing opinions).
I'm going to attempt to rephrase and summarize that discussion in the hope that we can continue this conversation with everyone on the same page (Jóhann, please correct me if I misrepresent anything). I'm responding to the original email here because I'm not aiming to reply to any particular part of the thread other than to re-summarize the initial proposal. Also, this will touch on a couple topics from the other threads, but I don't want to split this discussion too much. I'll add a few of my own thoughts at the bottom.
== Role Assignments == So, after discussing this, I think the general idea is that we agree that assigning roles should be handled by some sort of API whose exact implementation is defined later. It must be consumable by a remote interface and the installer.
The major disconnect here was that it appeared that Jóhann was arguing against supporting multiple roles on the same system. That was not strictly the case; he is arguing that the roles should not be installed without isolation on a single system. After some conversation on the point, I believe that he and I agreed that it was probably sufficient at this stage of planning to define an API that must be capable of installing more than one role on a system. In the short term, we can stick with our previously-agreed plan of only vetting and promising one role at a time, while not strictly preventing multiple roles. We agreed that as isolation technologies such as containers mature, we should plan for this role assignment to act as an abstraction layer so that we can just flip the switch when the day comes that the containers are ready for true service isolation. This should be essentially transparent to administrators.
== Personas == There was some confusion as to the value of defining "personas" in the discussion. This was primarily due to, I think, a few insufficient examples that were used in the meetings. Jóhann was under the impression that we were trying to define "Junior Admin" and "Senior Admin" (nebulous terms) as personas. I explained that a better example of a "Junior Admin" persona would instead be "A person who wants to administer a PostgreSQL database using a graphical or web-based UI tool". With that more concrete example, it became a little more clear what a "persona" really is.
The second disconnect there was that he felt that personas were therefore more applicable to the roles themselves as opposed to the greater Fedora Server effort. I conceded that the examples we had been throwing about would generally make sense there, but also pointed out that we had not yet clearly and explicitly described some of the general personas as well. I cited "A developer or experienced administrator who wants to promote a service to the level of featured role in the Fedora Server" as such a persona that should apply to the Fedora Server effort. I believe we concluded this portion of the discussion agreeing that it made sense to try to define such personas first and then categorize them as applicable to Fedora Server vs. Role.
== FOS, FOSSP and Roles == One place where we very clearly had some confusing terminology is in terms of the three layers that Jóhann is proposing in this thread. Part of the confusion comes from the classic ambiguity between "core" and "base" that we have in Fedora today. For the non-native English speakers reading this, these two words are basically synonyms, but in the context of Fedora, "core" has generally meant the "minimal" install of Fedora and "base" something like the standard headless install.
Jóhann then added new terms, FOS (Fedora OS) and FOSSP (Fedora OS Server Platform) and proceeded to use the terms interchangably with "core" and "base", respectively. It had been unclear to me prior to our conversation today that FOSSP == "base for the Fedora Server".
So to first clarify those three layers as Jóhann defines them:
FOS: Analagous to "core" from traditional Fedora. Should essentially contain the absolute minimal set of functionality necessary to install the bits, get a shell and install software on a running machine. This is what he expects as output from the Base WG.
FOSSP: Analagous to "base" from traditional Fedora. This should be the platform delivered by the Fedora Server. It should provide all of the foundational pieces necessary to support the deployment of the supported roles.
FOSSP Roles: Individual services installable by API as described above, ideally isolated on the target system.
== Release Cycles == Jóhann also posits some changes to release cycle for the FOS and FOSSP layers. They would not deliver on precisely the same cycle but would do so on a common cadence.
Specifically, the idea would be for FOS to tie its releases to the Linux Kernel upstream release schedule, wherein it would make a stable release approximately four times a year.[1]
We would then tie the preview/development release of FOSSP to the upstream kernel release schedule as well. We could continue to have Preview releases as with my lifecycle proposal on a regular basis and then tie the stable, LTM Fedora Server N.0 to the LTS kernel releases, approximately every two years. This is an interesting idea and would serve to address some of the classic Fedora Kernel issues necessitating rebases in stable Fedoras[2]. This idea isn't without merit, but as I mentioned, I'm not certain about the fast cycle on the FOS. We might be able to get away with half as many FOS and FOSSP preview releases by only tying ourselves to alternating kernel releases or something like that. This is worth discussing further, I'd say.
It's important to note that, like my lifecycle proposal in the other thread, this release schedule plan involves having one "rolling" or "preview" branch and exactly one stable/maintained branch of the Fedora server at any time (with some limited overlap for migration). This would generally serve to actually reduce the amount of ongoing maintenance (as compared to right now where I'm doing security releases for F18, F19, F20 and Rawhide all at once).
As long as the mechanism for deploying and configuring roles is standardized on the FOSSP, it may be that individual roles do not need to be tied to the FOSSP release cycle at all. I am not certain that I agree with this yet; I think there is value from a marketing and testing perspective to have the set of roles established at each release of the stable branch of FOSSP at least.
== Installer == Jóhann is also concerned about the level of control in the installer and the potential overlap between Anaconda, gnome-initial-setup (in the Workstation case) and whatever we're calling firstboot these days. He also feels uncertain that Anaconda is sufficiently modular to remove things that aren't necessary for a particular project. The example he gave was iSCSI support for Workstation, but I assume he also feels there are features not needed for the Server. I think we both agree that the modular spokes at least allow us room to grow our own new requirements.[3]
Jóhann also raised concerns that Anaconda is the source of the majority of release-verification failures in current Fedora and that he hopes that the Base WG and Anaconda team can work out a mechanism to avoid breakage (or automate detection of it) so his proposal of more frequent releases could be realized.
== Role Process == Jóhann does not like the term PRD and feels that the term as defined[4] doesn't really make sense for a community project. Moreover, he feels it doesn't make sense when applied to the role projects. He envisions that each role we harden and tie into our deployment API should be developed as a project of its own, following a different (non-PRD-driven) process. He suggested that Stage-Gate[5] might be a useful approach for this.
We discussed that in terms of the January deliverable, it is probably okay for us to set a roadmap for what we want to accomplish, rather than attempting to set down all future processes for sub-tasks at this time. That will not stop Jóhann from preparing early.
== Final Thoughts == Yikes, this email is much longer than I expected it to be. If you're still reading at this point, I commend you.
[1] This is the first point that I think would need serious evaluation. Jóhann claims that this would not introduce more work for QA, particularly if we kept the FOS surface extremely small. I'm not convinced that this would be achievable for the Anaconda people (although it would encourage more of a release early, release often environment). I'd also like to hear an assertion from the general Fedora QA community whether they feel this is achievable. Jóhann, would you mind raising this discussion at the next Fedora QA meeting?
[2] http://fedoraproject.org/wiki/KernelRebases
[3] Jóhann, this is the section I'm not as certain we came to an agreement on, so I may not be recording this accurately.
[4] http://en.wikipedia.org/wiki/Product_requirements_document
[5] http://www.prod-dev.com/stage-gate.php
On Mon, 2013-11-18 at 20:21 -0500, Stephen Gallagher wrote:
== FOS, FOSSP and Roles == One place where we very clearly had some confusing terminology is in terms of the three layers that Jóhann is proposing in this thread. Part of the confusion comes from the classic ambiguity between "core" and "base" that we have in Fedora today. For the non-native English speakers reading this, these two words are basically synonyms, but in the context of Fedora, "core" has generally meant the "minimal" install of Fedora and "base" something like the standard headless install.
Jóhann then added new terms, FOS (Fedora OS) and FOSSP (Fedora OS Server Platform) and proceeded to use the terms interchangably with "core" and "base", respectively. It had been unclear to me prior to our conversation today that FOSSP == "base for the Fedora Server".
So to first clarify those three layers as Jóhann defines them:
FOS: Analagous to "core" from traditional Fedora. Should essentially contain the absolute minimal set of functionality necessary to install the bits, get a shell and install software on a running machine. This is what he expects as output from the Base WG.
Is this what BaseWG had in mind ? I suspect they called it BaseWG because they intend to create a base, not a core image.
FOSSP: Analagous to "base" from traditional Fedora. This should be the platform delivered by the Fedora Server. It should provide all of the foundational pieces necessary to support the deployment of the supported roles.
Why do we need to have different bases per product ? What do people expect to be different between the various 'bases' ?
I fear that building a per-product base would quickly make the 3 products not able to share other packages and diverge too much, effectively forking the distribution in 3 incompatible sets.
FOSSP Roles: Individual services installable by API as described above, ideally isolated on the target system.
I think I would say 'optionally' isolate, rather than 'ideally'. Not that I do not want them to be able to run in isolation, but that should be an informed decision of the Administrator and not forced on by the tools.
Simo.
On 11/19/2013 02:40 PM, Simo Sorce wrote:
Why do we need to have different bases per product ?
Because the core needs to be on different release cycle
What do people expect to be different between the various 'bases' ?
Because the requirements are different between serverWG and workstationWG so divergance is unavoidable.
And what is the purpose of this effort if these things do not diverge?
What would be the difference of what we have now compared to fedora next?
JBG
On Tue, 2013-11-19 at 14:56 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 02:40 PM, Simo Sorce wrote:
Why do we need to have different bases per product ?
Because the core needs to be on different release cycle
What do people expect to be different between the various 'bases' ?
Because the requirements are different between serverWG and workstationWG so divergance is unavoidable.
And what is the purpose of this effort if these things do not diverge?
Configuration and management tools mostly.
What would be the difference of what we have now compared to fedora next?
That you have a coherent set of configuration and management tools that are server oriented. It's not like we need to diverge on the packages, but it would be a side effect of every one going their road.
All Linux distribution ship the same packages, but most incompatibilities come from naming and versions, I do not see as a good thing to have internal divergence in Fedora. It would be especially taxing for those packages that need to go in multiple products if they had to be rebuilt in all of them because underlying packages slightly differ.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 10:12 AM, Simo Sorce wrote:
On Tue, 2013-11-19 at 14:56 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 02:40 PM, Simo Sorce wrote:
Why do we need to have different bases per product ?
Because the core needs to be on different release cycle
What do people expect to be different between the various 'bases' ?
Because the requirements are different between serverWG and workstationWG so divergance is unavoidable.
And what is the purpose of this effort if these things do not diverge?
Configuration and management tools mostly.
What would be the difference of what we have now compared to fedora next?
That you have a coherent set of configuration and management tools that are server oriented. It's not like we need to diverge on the packages, but it would be a side effect of every one going their road.
All Linux distribution ship the same packages, but most incompatibilities come from naming and versions, I do not see as a good thing to have internal divergence in Fedora. It would be especially taxing for those packages that need to go in multiple products if they had to be rebuilt in all of them because underlying packages slightly differ.
If there are packages that belong in multiple products, I'd recommend that those be in the core/FOS definition. I think we can probably talk about allowing individual products to elect to leave things OUT (such as Fedora Cloud not carrying all the drivers), but if multiple products all need e.g. openssh, I think we should assert that they should not fork unless it's thoroughly unavoidable. In other words, if more than one product needs to rely on something, in my opinion that belongs in the Base WG definition.
On 11/19/2013 03:22 PM, Stephen Gallagher wrote:
If there are packages that belong in multiple products, I'd recommend that those be in the core/FOS definition.
? Dont you mean the Base layer ( FOSSP ) would be better suited fo that since the core *really* needs to be on it's own release cycle.
JBG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 10:30 AM, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 03:22 PM, Stephen Gallagher wrote:
If there are packages that belong in multiple products, I'd recommend that those be in the core/FOS definition.
? Dont you mean the Base layer ( FOSSP ) would be better suited fo that since the core *really* needs to be on it's own release cycle.
Just to be clear, we haven't really agreed to this. You're taking a bit too rigid a stand on that. As I mentioned in my other email, I'd *really* like to hear from the larger QA group as well as rel-eng and installer before we agree to separate the cycles, at least at first.
I understand your arguments in favor of this (I think), which is heavily bound to addressing the kernel rebase behavior. I'm just not yet certain it's something we can't defer initially.
On 11/19/2013 03:12 PM, Simo Sorce wrote:
Configuration and management tools mostly.
What's the purpose with this effort and process then if there will be no change other then giving people the fake notion that they matter and this actually will change anything ?
Why dont those that are going to be writing those tools simply do that, package it be done with this.
What's the purpose of wasting people time with a process that's trying to be something it's not?
JBG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 10:36 AM, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 03:12 PM, Simo Sorce wrote:
Configuration and management tools mostly.
What's the purpose with this effort and process then if there will be no change other then giving people the fake notion that they matter and this actually will change anything ?
This response isn't terribly helpful. There are changes coming. At the absolute minimum, we've been making good headway at agreeing on how to integrate roles and services better so that they are easier to use and demonstrate more obvious value.
Why dont those that are going to be writing those tools simply do that, package it be done with this.
We intend for them to do just that. A big part of this effort is building up the guidelines they would need to follow in order to understand what they need to do to get there. It's also setting the constraints on what users see (i.e. by default they may be restricted to seeing only those server roles that we have vetted).
I don't think we need to completely block off our users' ability to do the things they do today, but we add value for them if we can provide a set of featured options that work well with less chance of it breaking on them.
What's the purpose of wasting people time with a process that's trying to be something it's not?
Could you describe in detail what you think it's "trying to be" vs. "is"? I suspect you may just have a different understanding of those two terms than we do.
On Tue, 2013-11-19 at 15:36 +0000, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 03:12 PM, Simo Sorce wrote:
Configuration and management tools mostly.
What's the purpose with this effort and process then if there will be no change other then giving people the fake notion that they matter and this actually will change anything ?
I totally fail to understand what you mean here.
The purpose of this effort is to make sure packages do work properly in a server environment. In some cases it may mean having to compromise with other products so that a package works properly for all products or is built in a way that allows different configurations/plugins to be loaded based on what product it is being installed on.
Why dont those that are going to be writing those tools simply do that, package it be done with this.
Because in order to build a coherent story you need some direction, otherwise nobody will have any idea what is the goal and what helps rather than hinder that goal.
What's the purpose of wasting people time with a process that's trying to be something it's not?
I guess that in order to determine if people's time is being wasted you first need to define what is the process, and what is the goal and what are the expectations, then check if they all match up or not.
It seem you have your own idea of what the process should be but you are not helping me understand what your idea is.
It is also a bit discomforting that if your interpretation of what others says does not meet your personal idea then you write it off as a waste or useless, without even taking the chance to see if you really understood what was being said or proposed. I think we have established that we have a terminology and communication problem already, let's please not take things at face value but explore them a little bit before writing them off as a waste.
Simo.
On 11/19/2013 03:54 PM, Simo Sorce wrote:
It seem you have your own idea of what the process should be but you are not helping me understand what your idea is.
I myself have been looking 5+ years in the future with more then 5+ past experience working in Fedora and I have been looking at this process as an point in time as the opportunity to make a real change and real difference with much needed clean up in distribution in the process.
If not now when I simply ask?
On numerous occasion I have tried to explain the needed work ahead of us but on all those occasion I have failed as it seems.
Given that we do not fundamentally share that vision, I have decided to withdraw my proposals as well as my participation in the ServerWG since I would be more of an burden then a benefit to this effort and focus on my efforts entirely on FedoraOS ( as opposed to try to find the golden middle ground in this process ) and present that to the community and hopefully have them vote on which direction should be taken.
I thank Stephen for have chosen me in the first place and I'm pretty sure he already has an willing replacement that is better aligned with what he's trying to achieve with this effort and the vision of this group.
JBG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 02:05 PM, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 03:54 PM, Simo Sorce wrote:
It seem you have your own idea of what the process should be but you are not helping me understand what your idea is.
I myself have been looking 5+ years in the future with more then 5+ past experience working in Fedora and I have been looking at this process as an point in time as the opportunity to make a real change and real difference with much needed clean up in distribution in the process.
If not now when I simply ask?
On numerous occasion I have tried to explain the needed work ahead of us but on all those occasion I have failed as it seems.
Given that we do not fundamentally share that vision, I have decided to withdraw my proposals as well as my participation in the ServerWG since I would be more of an burden then a benefit to this effort and focus on my efforts entirely on FedoraOS ( as opposed to try to find the golden middle ground in this process ) and present that to the community and hopefully have them vote on which direction should be taken.
I thank Stephen for have chosen me in the first place and I'm pretty sure he already has an willing replacement that is better aligned with what he's trying to achieve with this effort and the vision of this group.
I have to be honest, I'm more than a little surprised by this. It seemed to me that all of your suggestions were being listened to and discussed respectfully.
I would honestly prefer not to lose you from the group. You've been consistently providing good ideas for discussion. While ultimately we may not all agree that they are the right choice for the immediate future, I haven't really seen any of your proposals that were dismissed out of hand.
I'm not sure that our long-term goals disagree in any meaningful way, but I suspect that the disconnect here is that you are looking for a larger change in a shorter time period than the rest of us generally feel we could soak up.
It sounds to me like your complete goal here really amounts to developing an entirely new Linux-based operating system under the Fedora brand. Whereas others in the group (I hesitate even to claim a majority without calling any sort of vote) are looking at incremental changes to minimize the work in each individual cycle but with a clear direction aimed at a more comprehensive server solution.
It seems to me that there is an opportunity for your long-term vision to be brought to fruition through this process, but perhaps on a longer timeline than you would hope.
In any case, it is of course your own decision to withdraw from your voting seat. If you feel that this is the right choice for you, I will understand and respect it, but I would hope that you will not withdraw from our burgeoning community entirely. You have a lot to add and I can guarantee that your suggestions will continue to be heard.
On 11/19/2013 07:49 PM, Stephen Gallagher wrote:
I'm not sure that our long-term goals disagree in any meaningful way, but I suspect that the disconnect here is that you are looking for a larger change in a shorter time period than the rest of us generally feel we could soak up.
As I see it it's quite the opposite this effort here is trying to push those changes in F21 or F22 while I have stated ( in other threads ) the earliest time I see us delivering the first product would be late next year.
It sounds to me like your complete goal here really amounts to developing an entirely new Linux-based operating system under the Fedora brand.
Not entirely but close to it but yes because as I see it we have no other choice both in terms of the brand ( to not cause disruption ) as well as the the bits ( by moving them over and cleaning the distribution in the process ) if when? ( postponing it wont help the situation it will just make things worse )
The fact is ( as I see it ) we have to break things into manageable bits by starting small ( the core ) and gradually built on top of that by cleaning up things in the process. ( With my QA hat on any other way is a no go for us. we have to be able to manage the coreOS )
The different release cycle is because bits are moving at a different speed coreOS bits are moving on a different speed then the baseOS, Gnome is faster then KDE, we want to go slower and probably every application application stack really wants to align with their corresponding upstream and different maintainers even treat their bits differently between GA releases.
We have been on a forced generic release track for all of those bits for 10 years and we have not even managed to release on schedule *once*.
I say this is the time to cut of the fat as well as this also being the time to approach release cycles differently and put it to the test if we can do this ( it's a key factor in an far future evolution point for us if we can but that's a discussion for a different time and place in the future ) and I say we should do this under a different branch completely to not disrupt Fedora as our users know it.
Once we are done working out any kinks in processes and other things we can replace Fedora.new for Fedora.old under "Fedora" name and brand.
Whereas others in the group (I hesitate even to claim a majority without calling any sort of vote) are looking at incremental changes to minimize the work in each individual cycle but with a clear direction aimed at a more comprehensive server solution.
I have come to the conclusion that it is like people within the project that have been here for so many years have gotten so used the way of seeing it their way that they dont like to change it, feel uncomfortable of changes and they feel no need to change it and many of them are saying we are doing so well now why should we change it?
But if you look at the broader view, an view that I think many people in the distribution lack as in step back and look at the Fedora ego system in whole, as well as being able to view the larger GNU/Linux ego system and the moving bits there the mentality for people for lack of better term cant see the bigger picture looks really dangerous for us because in reality we are not doing so well far from it actually and things are moving at a pace we ( of all people ) have been having trouble keeping up with ( much to size and bureaucracy ).
I'm just going to point out *one* just *one* of the serious issues we are faced with.
We already have somewhere around 14500 components in the distribution.
Now the quickest way these days to spot the number of active contributors ( anywhere ) in the communities are badges since as far as I know it's an opt out process not opt in with fedmsg ( but I might be mistaken ) but at least it shows *active* community members and their community activities ( from August ).
Looking at Koji 1 badge which shows successfully completed a koji build we have the staggering number of it being awarded 617 times.
Dividing the total number of packages with the number of active contributors with that koji badge we get each of them maintaining 23.5 components!
Now let's say the average free time an individual has to spend on the project which is I think 2.5 hour and let's be generous here and let's say roughly 1 third of that number as in 7 components get a bug report per day and let's say it takes each maintainer at least one hour ( which should not be that far off ) just looking at that report *if* properly reported and if it was a non trivial fix ( let's just go as low as a spec file change here ) it takes another hour fixing, building and pushing that fix and the rest he spends answering emails, which means he has to dedicate all that time constantly 365 days to just those 7 components every day!
As you can quickly see in just this extremely simplified example the math does not add up in the project we *cannot* efficiently maintain all those packages and this is just *one* again *one of the problem we are faced with in the distribution just one...
If the above example is not enough to raise alarm with people nothing will.
JBG
On Tue, 2013-11-19 at 22:26 +0000, "Jóhann B. Guðmundsson" wrote:
I have come to the conclusion that it is like people within the project that have been here for so many years have gotten so used the way of seeing it their way that they dont like to change it, feel uncomfortable of changes and they feel no need to change it and many of them are saying we are doing so well now why should we change it?
I think the very fact we are trying to change the process should tell you people are willing to change and do not think all is working great.
And there are some quite old people in this list, I agree change is necessary, and I started using Fedora since when it was called RHL5.0 ...
I think the problem is that if you want radical change at the base you need to bush them with the baseWG.
From my part I do want change but going through smooth transitions.
But if you look at the broader view, an view that I think many people in the distribution lack as in step back and look at the Fedora ego system in whole, as well as being able to view the larger GNU/Linux ego system and the moving bits there the mentality for people for lack of better term cant see the bigger picture looks really dangerous for us because in reality we are not doing so well far from it actually and things are moving at a pace we ( of all people ) have been having trouble keeping up with ( much to size and bureaucracy ).
I'm just going to point out *one* just *one* of the serious issues we are faced with.
We already have somewhere around 14500 components in the distribution.
Now the quickest way these days to spot the number of active contributors ( anywhere ) in the communities are badges since as far as I know it's an opt out process not opt in with fedmsg ( but I might be mistaken ) but at least it shows *active* community members and their community activities ( from August ).
Looking at Koji 1 badge which shows successfully completed a koji build we have the staggering number of it being awarded 617 times.
Dividing the total number of packages with the number of active contributors with that koji badge we get each of them maintaining 23.5 components!
Now let's say the average free time an individual has to spend on the project which is I think 2.5 hour and let's be generous here and let's say roughly 1 third of that number as in 7 components get a bug report per day and let's say it takes each maintainer at least one hour ( which should not be that far off ) just looking at that report *if* properly reported and if it was a non trivial fix ( let's just go as low as a spec file change here ) it takes another hour fixing, building and pushing that fix and the rest he spends answering emails, which means he has to dedicate all that time constantly 365 days to just those 7 components every day!
As you can quickly see in just this extremely simplified example the math does not add up in the project we *cannot* efficiently maintain all those packages and this is just *one* again *one of the problem we are faced with in the distribution just one...
You are assuming all packages need the same level of care, that is simply not true. I have a package that I haven't touched since I put it in Fedora, because it is ok as is. It never received a bug report, nor required rebuilds outside of the mass rebuilds. Maybe I am (was) the only user. I think we may have a few hundreds if not a few thousands of packages like that and many more that receive very few bug reports if any that are better maintained. Of course there are hot ones that receive a lot of bugs, but the metric you showed is weak and I think gives a quite distorted picture. I am not saying there is no problem at all, but it is more nuanced.
If the above example is not enough to raise alarm with people nothing will.
But your solution seem to be: let's throw away a few thousand packages and rewrite a few thousand others, if you think we are short in manpower with the current system where do you find the manpower to change a few thousand base packages to adhere to new standards ?
Simo.
On 11/19/2013 10:59 PM, Simo Sorce wrote:
On Tue, 2013-11-19 at 22:26 +0000, "Jóhann B. Guðmundsson" wrote:
I have come to the conclusion that it is like people within the project that have been here for so many years have gotten so used the way of seeing it their way that they dont like to change it, feel uncomfortable of changes and they feel no need to change it and many of them are saying we are doing so well now why should we change it?
I think the very fact we are trying to change the process should tell you people are willing to change and do not think all is working great.
And there are some quite old people in this list, I agree change is necessary, and I started using Fedora since when it was called RHL5.0 ...
Which is the same release as I started using RH which eventually led me to Fedora ( although I stayed on RHL 7.2 up to Fc3 )
I think the problem is that if you want radical change at the base you need to bush them with the baseWG.
I'm perfectly well aware of that otherwise I would not have nominated myself to the baseWG as well.
You are assuming all packages need the same level of care, that is simply not true.
Here you seem to be failing to understanding that those component still costs the community time.
There is *always* a "base" cost of time for a component in the distribution in addition to that is the fact when a maintainer becomes sloppy, leaves or in other words the time he provided is gone for one reason or another or simply reduced, the amount of time he provided just falls on someone else's shoulders until that the component he brought into the distribution is removed from the distribution.
If the above example is not enough to raise alarm with people nothing will.
But your solution seem to be: let's throw away a few thousand packages and rewrite a few thousand others,
I'm not sure where you get that rewrite from?
if you think we are short in manpower with the current system where do you find the manpower to change a few thousand base packages to adhere to new standards ?
We have to do it the same way as we do with anything we have to make/find that time.
JBG
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 05:26 PM, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 07:49 PM, Stephen Gallagher wrote:
I'm not sure that our long-term goals disagree in any meaningful way, but I suspect that the disconnect here is that you are looking for a larger change in a shorter time period than the rest of us generally feel we could soak up.
As I see it it's quite the opposite this effort here is trying to push those changes in F21 or F22 while I have stated ( in other threads ) the earliest time I see us delivering the first product would be late next year.
I think you misunderstood me. Delivering what you're asking for at any point in 2014 would be a herculean effort. What I was trying to suggest is that this looks to me like a 3+ year effort that we might try to attack in stages. I understand that you're of the opinion that we need to rip off the band-aid and do it all at once, but I suspect that this will lead to a minimum of 24 months without a release which would make it very difficult to remain relevant in the public eye.
It sounds to me like your complete goal here really amounts to developing an entirely new Linux-based operating system under the Fedora brand.
Not entirely but close to it but yes because as I see it we have no other choice both in terms of the brand ( to not cause disruption ) as well as the the bits ( by moving them over and cleaning the distribution in the process ) if when? ( postponing it wont help the situation it will just make things worse )
The fact is ( as I see it ) we have to break things into manageable bits by starting small ( the core ) and gradually built on top of that by cleaning up things in the process. ( With my QA hat on any other way is a no go for us. we have to be able to manage the coreOS )
As I said, I'm heavily in favor of dividing up the system into manageable bits. And I agree that we need to have clear delineations of Core, Platform and Roles. The only disagreement I have here is the order of operations. I think we can accomplish a greater bang for the proverbial buck by starting at the top and working down. If we produce useful roles, we can start dictating the platform underneath that we need to support. It's *very* hard to define from the bottom-up and be certain that the platform is going to meet the ultimate needs of the roles.
The different release cycle is because bits are moving at a different speed coreOS bits are moving on a different speed then the baseOS, Gnome is faster then KDE, we want to go slower and probably every application application stack really wants to align with their corresponding upstream and different maintainers even treat their bits differently between GA releases.
We have been on a forced generic release track for all of those bits for 10 years and we have not even managed to release on schedule *once*.
I'm not opposed to the idea of maintaining different schedules for different components. I'm just not certain we need to separate the cycles *initially*. Or at least that it would be okay for a first shot to release a Core, Platform and a small set of initial roles on the same day and then consider diverging at that point.
I say this is the time to cut of the fat as well as this also being the time to approach release cycles differently and put it to the test if we can do this ( it's a key factor in an far future evolution point for us if we can but that's a discussion for a different time and place in the future ) and I say we should do this under a different branch completely to not disrupt Fedora as our users know it.
Once we are done working out any kinks in processes and other things we can replace Fedora.new for Fedora.old under "Fedora" name and brand.
Whereas others in the group (I hesitate even to claim a majority without calling any sort of vote) are looking at incremental changes to minimize the work in each individual cycle but with a clear direction aimed at a more comprehensive server solution.
I have come to the conclusion that it is like people within the project that have been here for so many years have gotten so used the way of seeing it their way that they dont like to change it, feel uncomfortable of changes and they feel no need to change it and many of them are saying we are doing so well now why should we change it?
I don't think that anyone in this Working Group thinks that way. In fact, that's the impetus for this effort in the first place: the status quo isn't sufficient. There are certain things that we *are* good at, though and blindly eliminating everything we do today is going too far to the other extreme.
But if you look at the broader view, an view that I think many people in the distribution lack as in step back and look at the Fedora ego system in whole, as well as being able to view the larger GNU/Linux ego system and the moving bits there the mentality for people for lack of better term cant see the bigger picture looks really dangerous for us because in reality we are not doing so well far from it actually and things are moving at a pace we ( of all people ) have been having trouble keeping up with ( much to size and bureaucracy ).
I agree with this. So do all the people that are pushing for the Working Groups, to the best of my knowledge. We don't think it makes sense for e.g. xcowsay to require the same number of hoops as gcc to be part of the distribution.
There are parts of the process that need to be discussing what is *in* Fedora vs. what is running *on* Fedora. The FOS and FOSSP proposals are pretty clearly *in* Fedora, while the roles are pretty clearly *on* Fedora. It's acceptable to me at least that these different categorizations should receive different treatment.
I'm just going to point out *one* just *one* of the serious issues we are faced with.
We already have somewhere around 14500 components in the distribution.
Now the quickest way these days to spot the number of active contributors ( anywhere ) in the communities are badges since as far as I know it's an opt out process not opt in with fedmsg ( but I might be mistaken ) but at least it shows *active* community members and their community activities ( from August ).
Looking at Koji 1 badge which shows successfully completed a koji build we have the staggering number of it being awarded 617 times.
Dividing the total number of packages with the number of active contributors with that koji badge we get each of them maintaining 23.5 components!
<pedantic>IIRC, the badges system only counts your builds after the next time you run a build, so there are a LOT of packages just sitting in the distro idling and only getting rebuilt at mass rebuilds. That's a different problem, but it does through the math off slightly. I see your point, though.</pedantic>
Now let's say the average free time an individual has to spend on the project which is I think 2.5 hour and let's be generous here and let's say roughly 1 third of that number as in 7 components get a bug report per day and let's say it takes each maintainer at least one hour ( which should not be that far off ) just looking at that report *if* properly reported and if it was a non trivial fix ( let's just go as low as a spec file change here ) it takes another hour fixing, building and pushing that fix and the rest he spends answering emails, which means he has to dedicate all that time constantly 365 days to just those 7 components every day!
As you can quickly see in just this extremely simplified example the math does not add up in the project we *cannot* efficiently maintain all those packages and this is just *one* again *one of the problem we are faced with in the distribution just one...
If the above example is not enough to raise alarm with people nothing will.
You're making a point that I've been making a lot lately in various circles as part of my and Matthew's arguments that we need to layer Fedora. I agree wholeheartedly that this is an issue and it's part of the purpose of the product plans: through these products, we should be very clearly identifying the set of packages that we care more about and are willing to focus our attention on. Outside of those sets, we make fewer promises.
On 11/20/2013 12:55 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 05:26 PM, "Jóhann B. Guðmundsson" wrote:
On 11/19/2013 07:49 PM, Stephen Gallagher wrote:
I'm not sure that our long-term goals disagree in any meaningful way, but I suspect that the disconnect here is that you are looking for a larger change in a shorter time period than the rest of us generally feel we could soak up.
As I see it it's quite the opposite this effort here is trying to push those changes in F21 or F22 while I have stated ( in other threads ) the earliest time I see us delivering the first product would be late next year.
I think you misunderstood me. Delivering what you're asking for at any point in 2014 would be a herculean effort. What I was trying to suggest is that this looks to me like a 3+ year effort that we might try to attack in stages. I understand that you're of the opinion that we need to rip off the band-aid and do it all at once,
Yes not ripping the band-aid off will just lead to more pain.
but I suspect that this will lead to a minimum of 24 months without a release which would make it very difficult to remain relevant in the public eye.
We absolutely cannot stop the factory line of "Fedora" even for just one release cycle. If we do we would never be able to start it again and still be relevant thus we need to do this as I have always proposed on another factory line placed next to Fedora.
As I said, I'm heavily in favor of dividing up the system into manageable bits. And I agree that we need to have clear delineations of Core, Platform and Roles. The only disagreement I have here is the order of operations. I think we can accomplish a greater bang for the proverbial buck by starting at the top and working down.
I disagree here we need to work from bottom up running after the market is just madness or as Marlboro put it in Harley Davidson and the Marlboro Man, "My old man told me, before he left this shitty world, never chase buses or women, you'll always be left behind. "
If we produce useful roles, we can start dictating the platform underneath that we need to support. It's *very* hard to define from the bottom-up and be certain that the platform is going to meet the ultimate needs of the roles.
But doing bottom up we will free time as opposed to the other way around and in the end of the day the *end user* will always chose the solution that best suite *his* and currently we are to busy chasing our own tail let alone to start chasing the markets one.
The different release cycle is because bits are moving at a different speed coreOS bits are moving on a different speed then the baseOS, Gnome is faster then KDE, we want to go slower and probably every application application stack really wants to align with their corresponding upstream and different maintainers even treat their bits differently between GA releases.
We have been on a forced generic release track for all of those bits for 10 years and we have not even managed to release on schedule *once*.
I'm not opposed to the idea of maintaining different schedules for different components. I'm just not certain we need to separate the cycles *initially*. Or at least that it would be okay for a first shot to release a Core, Platform and a small set of initial roles on the same day and then consider diverging at that point.
I'm not against that approach as long if that work is being kept separately in another branch under another brand "the second factory line".
It is essential to our future ( 10+ years ) in the long run that we cross over the bridge and implement processes and ways to handle multiple release cycle
I don't think that anyone in this Working Group thinks that way. In fact, that's the impetus for this effort in the first place: the status quo isn't sufficient. There are certain things that we *are* good at, though and blindly eliminating everything we do today is going too far to the other extreme.
As I see it we are not blindly eliminating everything we do today as I see it we would be embarking upon massive cleanup both in terms of processes and packages with the long time return of investment in freeing up time for agility and innovation.
In the long term bottom up approach is a better investment then essentially investment in the tourist market which is a flaky business.
There are parts of the process that need to be discussing what is *in* Fedora vs. what is running *on* Fedora. The FOS and FOSSP proposals are pretty clearly *in* Fedora, while the roles are pretty clearly *on* Fedora. It's acceptable to me at least that these different categorizations should receive different treatment.
That does not change the prioritisation of where we need to invest time to free time.
You're making a point that I've been making a lot lately in various circles as part of my and Matthew's arguments that we need to layer Fedora. I agree wholeheartedly that this is an issue and it's part of the purpose of the product plans: through these products, we should be very clearly identifying the set of packages that we care more about and are willing to focus our attention on. Outside of those sets, we make fewer promises.
Right it's just where to prioritise the next efforts.
With my QA hat on back around fc5 and fc6 we had roughly 5000 - 7000 components little less then half the size of what we are now and we are facing the exact same issues as we did back then today just on a larger scale and I'm pretty sure Releng can say the same thing which means we are dealing with a fundamental problem in our release and overall design, our processes and our workflows and we need to attack the root cause at that level not continue to paper over it or punt and hope for the best.
JBG
On Tue, Nov 19, 2013 at 4:36 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/19/2013 03:12 PM, Simo Sorce wrote:
Configuration and management tools mostly.
What's the purpose with this effort and process then if there will be no change other then giving people the fake notion that they matter and this actually will change anything ?
Why dont those that are going to be writing those tools simply do that, package it be done with this.
What's the purpose of wasting people time with a process that's trying to be something it's not?
Many people have already written many tools, and many of them have been packaged. That has done... very little to actually improve the general situation and especially the "out-of-the-box" situation.
Choosing tools and designing the product and the processes such that the tools are actually used, easy to use, and the like - in short that they actually make a difference to users is, I think, one of the primary expected benefits of "this effort and process". Mirek
On Tue, Nov 19, 2013 at 3:56 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/19/2013 02:40 PM, Simo Sorce wrote:
Why do we need to have different bases per product ?
Because the core needs to be on different release cycle
Why exactly? To tie it with the LTS kernel? Wouldn't it then be an option to sacrifice the kernel timing dependency (and ship a 1-4 months older kernel) to achieve much simpler Fedora release and release validation mechanism? Mirek
On Tue, 2013-11-19 at 19:14 +0100, Miloslav Trmač wrote:
On Tue, Nov 19, 2013 at 3:56 PM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 11/19/2013 02:40 PM, Simo Sorce wrote:
Why do we need to have different bases per product ?
Because the core needs to be on different release cycle
Why exactly? To tie it with the LTS kernel? Wouldn't it then be an option to sacrifice the kernel timing dependency (and ship a 1-4 months older kernel) to achieve much simpler Fedora release and release validation mechanism?
I think the reason why Fedora releases new kernels frequently is to address rapid hardware enablement w/o dreadful backports nobody has the energy to make on such a vast fast moving code base. However I do not think refreshing the kernel means refreshing the rest of the 'core' tools. Kernel people try very hard not to break APIs and ABIs, the same cannot always be said by other components. And other components do not really need fast pace hardware enablement, I think for most server uses it would be sufficient to backport only security fixes or critical crash-bugs if any refresh is needed at all.
That doesn't mean a core of packages shouldn't have a sort of rolling release development process, just that the BaseWG would freeze and ship regularly all the core tools except for the kernel. And server would follow suite, perhaps retaining a frozen core even for longer.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 02:16 PM, Simo Sorce wrote:
I think the reason why Fedora releases new kernels frequently is to address rapid hardware enablement w/o dreadful backports nobody has the energy to make on such a vast fast moving code base.
If you missed it in my other email, the kernel team has a well-stated explanation of why they do releases the way they do: http://fedoraproject.org/wiki/KernelRebases
I think there's some value at least to tying our Fedora Server stable releases to one of the LTS kernels to minimize disruption.
On Tue, 2013-11-19 at 14:22 -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 02:16 PM, Simo Sorce wrote:
I think the reason why Fedora releases new kernels frequently is to address rapid hardware enablement w/o dreadful backports nobody has the energy to make on such a vast fast moving code base.
If you missed it in my other email, the kernel team has a well-stated explanation of why they do releases the way they do: http://fedoraproject.org/wiki/KernelRebases
Which I think boils down to what I said all considered (but of course their explanation is more nuanced and complete).
I think there's some value at least to tying our Fedora Server stable releases to one of the LTS kernels to minimize disruption.
I guess we can try, but then how do you deal with hardware enablement for the latest and greatest hardware ? I do agree we could keep a pinned kernel as 'the stable one', but if we go that road I think we should still make it possible for people to at least try to use a newer kernel from the core packages as they come out if they have new hardware (or nasty bugs) that is not supported (not fixed/fixable) in the "stable" kernel.
Simo.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 02:43 PM, Simo Sorce wrote:
On Tue, 2013-11-19 at 14:22 -0500, Stephen Gallagher wrote:
I think there's some value at least to tying our Fedora Server stable releases to one of the LTS kernels to minimize disruption.
I guess we can try, but then how do you deal with hardware enablement for the latest and greatest hardware ? I do agree we could keep a pinned kernel as 'the stable one', but if we go that road I think we should still make it possible for people to at least try to use a newer kernel from the core packages as they come out if they have new hardware (or nasty bugs) that is not supported (not fixed/fixable) in the "stable" kernel.
Well, in my personal opinion, that should probably fall into the category of "Here's the gun, try to only hit one of your toes". I don't think we necessarily want to spend any effort to full test and feature such kernels.
Of course, I am open to convincing arguments, but I'd like to hear them come from the kernel team, ideally.
On Tue, 2013-11-19 at 14:53 -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2013 02:43 PM, Simo Sorce wrote:
On Tue, 2013-11-19 at 14:22 -0500, Stephen Gallagher wrote:
I think there's some value at least to tying our Fedora Server stable releases to one of the LTS kernels to minimize disruption.
I guess we can try, but then how do you deal with hardware enablement for the latest and greatest hardware ? I do agree we could keep a pinned kernel as 'the stable one', but if we go that road I think we should still make it possible for people to at least try to use a newer kernel from the core packages as they come out if they have new hardware (or nasty bugs) that is not supported (not fixed/fixable) in the "stable" kernel.
Well, in my personal opinion, that should probably fall into the category of "Here's the gun, try to only hit one of your toes". I don't think we necessarily want to spend any effort to full test and feature such kernels.
Of course, I am open to convincing arguments, but I'd like to hear them come from the kernel team, ideally.
Well I hope so, given you have to sign them up for a stable release and they may simply refuse :-)
Simo.
On Tue, Nov 19, 2013 at 3:40 PM, Simo Sorce simo@redhat.com wrote:
On Mon, 2013-11-18 at 20:21 -0500, Stephen Gallagher wrote:
FOS: Analagous to "core" from traditional Fedora. Should essentially contain the absolute minimal set of functionality necessary to install the bits, get a shell and install software on a running machine. This is what he expects as output from the Base WG.
Is this what BaseWG had in mind ? I suspect they called it BaseWG because they intend to create a base, not a core image.
Yeah. Things like the Python or Ruby stack or chrony or all the dependencies of anaconda don't belong into "core" but should be shared between products.
FOSSP: Analagous to "base" from traditional Fedora. This should be the platform delivered by the Fedora Server. It should provide all of the foundational pieces necessary to support the deployment of the supported roles.
Why do we need to have different bases per product ? What do people expect to be different between the various 'bases' ?
We do kind of need a "Server shared infrastructure", though - perhaps a puppet client, monitoring agent, something providing the external API interface for the Server, and the like. These should, though, be mostly packages unique to Server (or Server+Cloud?), not different between Server and other products. Mirek
server@lists.fedoraproject.org