FedoraOS Server Platform ( FOSSP )

["Jóhann B. Guðmundsson"]

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