FedoraOS Server Platform ( FOSSP )

Wed Nov 20 00:55:47 UTC 2013

-----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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKMCJMACgkQeiVVYja6o6M6qACgg+PV1F4SUwmJQ+Go0xo/RkJj
c2AAn09bHKCDFlj3KSAMP02yRl2SqwJ3
=eG8W
-----END PGP SIGNATURE-----