FedoraOS Server Platform ( FOSSP )

[Miloslav Trmač]

On Sat, Nov 16, 2013 at 9:00 PM, "Jóhann B. Guðmundsson"
<johannbg at gmail.com> wrote:
> On 11/16/2013 02:24 PM, Simo Sorce wrote:
>> On Sat, 2013-11-16 at 13:23 +0000, "Jóhann B. Guðmundsson" wrote:
> Being an ambassador I know how much regular end user hate their desktop
> disruptions.
(Then isn't the right thing to do for our users to _avoid_
disruptions, if we could by doing some extra programming and testing?)


> This entire effort I see as an opportunity to change that from the ground up
> and I'm willing to do that work single handedly if I have to because it bugs
> me and bugs me alot how things that should not be broken are broken ( after
> all I'm only used to deal with packages in the hundred+ range ) and that's a
> work that I will be doing anyway despite how this entire WG ends up to be.
Years ago,
* I have written an UNIX-like OS kernel
* I have written a libc
* I have written 90% of a little-optimizing compiler (with the other
90% of getting it production-reliability remaining)
... all over a period of 9 years, and ended up with something overall
_vastly inferior_ to the corresponding GNU components, despite a few
nice improvements.[1]

So, I feel very confident in saying that an individual or a small
group like the Server WG won't change Fedora "from the ground up"
without cooperation of the majority of the maintainers.


> Now the only way I see to achieve that ( because of what I have seen and
> what needs to be done to fix it will break stuff for people ) without
> disrupting existing workflow for our user base is as you put it "fork the
> distribution"  which to me is just moving package a --> cleaning it up
> putting it into FedoraOS.
>
> Ones that process is over and that the entire WG effort not been proven as
> failure then we can drop old "Fedora" and rename FedoraOS as Fedora for all
> I care.

Despite best efforts of everybody working on RHL and Fedora in the
past, we have ended up in this situation where you argue that we
should start anew.  OK, but if the past work has ended up in something
that needs to be thrown away, isn't it reasonable to assume that
FedoraOS will eventually also end up in something that needs to be
thrown away?  That seems, if not inevitable, at least highly plausible
to me.

OK, so let's do something different: let's design FedoraOS so that at
the point that it will have had to be thrown away, we will also have a
mechanism to make a more graceful transition.  That would be
preferable, wouldn't it?  But how can we design such a graceful
transition mechanism for an unknown time in the future, and be
confident in having the right solution, when we can't test it at all
for many years to come?

Hence my suggestion: Design Fedora OS with a graceful transition
mechanism, and then _apply and test it on the Fedora->FedoraOS
transition_.  The best of both worlds (Fedora + FedoraOS), tested,
reliable.

There are still very many ways to do this: just continue in the
existing RPM world and mark some of them as "blessed"/"cleaned
up"/"preferred"; fork the filesystem and allow installing both kinds
of packages alongside; or something else entirely.  Some of them may
look more like the FedoraOS proposal; some of them may look completely
unlike the FedoraOS proposal.  The critical point is to avoid the user
disruption and the associated userbase loss.

>>> The only thing they can promise is best effort.
>>
>> And that is fine, nobody is asking for miracles.
>
> I'm pretty sure you dont know that the Thunderbirds maintainer pushed update
> to F18 knowingly that broke it's integration with Gnome's notification
> scheme so I dont share the same faith that you do in our maintainers and
> since the maintainership of components is heavily depend on the
> individual(s) behind it , where some do really good job of it, others to
> pretty ok job of it and some poor job of it
I think the only possible answer here is to automate whatever we can.
If there are problems known to be recurring repeatedly, let's create
tools that prohibit any checkin/build with that problem; if features
go missing, let's write tests to avoid regressions.

Maintainers are (for the most part, in some sense even those paid by
RH) volunteers, and we don't get to choose how great a job they do.
(... or how great a job some of us do, for that matter; I know I'm not
a stellar maintainer.)  Still, hundreds of well-meaning but not
perfect maintainers can do much more than a 9-person WG, even if it
were composed of perfect people.

> and some none et all it and
> knowing that as well as maintainers concerns, keeping the server roles in
> separated repo makes the most sense since it gives them the ability and
> *freedom* ( within reasonable boundaries ) to maintain what they think is to
> the best to heir ability and us in QA to somewhat test their component in
> the process.

I can't see how separation addresses any of the quality concerns.  One
could perhaps say "the $role_a repo is really well maintained" and
"the $role_b repo is constantly broken" but the same can be equally
true, and equally said about, roles living in a shared RPM repository.

> Honestly I dont know why certain people insist that having FOS/FOSSP/FOSSR
> each on a multiple different release cycle wont work.
For me, I see the complexity of managing different releases of Red Hat
products that have interdependencies.  It can be done, but it's a lot
of work and mistakes happen - work and mistakes entirely avoidable by
having a single release cycle and one product release instead of
multiple interdependent products.

> I'm pretty sure we can apply something that was in use as early as in the
> days of Aristotle is in use today and provides us with the math to calculate
> ahead of time the outcome for each release cycle to be able to organize us
> and each team ( marketing,releng,qa etc. ) accordingly but maybe I'm missing
> something...

What "something" exactly would that be?  My experience in FESCo from
the endless F18 slip is that we really don't have that much visibility
or control; we can certainly improve visibility at least, however
let's talk about specific changes (... probably separately from the
PRD discussion, later?) instead of vaguely referring to philosophers.

>>   We can achieve some
>> success only through the collaboration of a *large* group of people,
>
> True enough but are you sure that large group of people are behind the WG
> effort et all?

Giving them something they can get behind is, to a large extent, our
task.  If we fail at this, the WG will fail.
    Mirek

[1] It was extremely useful as a learning exercise, I can very much
recommend it if you have so much free time.