FedoraOS Server Platform ( FOSSP )

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

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