On 11/19/2013 07:49 PM, Stephen Gallagher wrote:
I'm not sure that our long-term goals disagree in any meaningful
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
It sounds to me like your complete goal here really amounts to
developing an entirely new Linux-based operating system under the
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
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.