On 11/20/2013 12:55 AM, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
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
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
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