On 21 September 2016 at 11:32, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> On 09/13/2016 03:02 PM, Stephen John Smoogen wrote:
>> On 13 September 2016 at 14:41, Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
>>> On Tue, Sep 13, 2016 at 06:21:46PM +0200, 'Dominik Perpeet' wrote:
>>>> Summary: It is easy to download, configure and install Fedora Server for
>>>> [insert list of standard use cases here, e.g. LAMP, container image
>>>> registry].
>>>
>>> What about phrasing this as an output (or set of outputs, even -- the
>>> media, docs, webpage, tools), and having "1000 new Fedora Server
>>> installations using our standard use cases by 2018" as the outcome? (Or
>>> some other number -- I picked that out of a hat. Measure by survey of
>>> users or by opt-in data gathering?)
>>
>> This is where I feel a cycle from left to right is needed to get to
>> the rigth to left. We could put up multiple outcomes which could be
>> 'measured' but only if we discuss and agree to how we are going to
>> measure them.
>>
>> I mean to meet the 1000 new Fedora server.. or some other number will
>> take that we have some sort of census program which is run or a string
>> in the dnf update which says which product the os was installed with.
>> Both of those are considered by various people as overly invasive and
>> will argue that they should only be opt-in etc etc.
>
>
> First of all, thank you very much for running the Server SIG meeting yesterday,
> Robyn!
>
>
> I'm reading through the transcript and I *think* there was a little confusion
> about what is an Outcome vs. what is an Output. An Outcome is still an indirect
> result of our efforts, but one that is theoretically measurable (not necessarily
> with existing tools and metrics). An Output is a concrete deliverable or
> artifact that we produce.
>
> So "It is easy to download, configure and install Fedora Server for [role, e.g.
> setting up a fileserver]" is *close*, but how do we measure "ease"?
>
> So let's take that fileserver example. An Outcome we may want is: "Users of
> Fedora Server Edition can share files with clients of multiple popular operating
> systems." The associated Output for that could then be one or more of
"Samba
> Server Role", "NFS Server Role", "AFS Server Role", etc.
>
> From there downwards, we'd have Activities which could be "Produce a role
> definition for a Samba server" and "Produce a Cockpit plugin to manage a
Samba
> server". Similar activities could be created for each desired role.
>
> I have a work-in-progress Kellogg Logic Model for this now available at
>
http://kolinahr.herokuapp.com/edit/57d05a6984338834000515c9 (and I'm attaching a
> screenshot of my current state). This is just a prototype of the Kolinahr app
> that a friend of mine is writing for Fedora to use and it's hosted on the free
> tier of Heroku at the moment, so please be patient if it's slow. At the moment
> it requires a Google Account to sign in and view models; I'm working on finding
> it a permanent home in Fedora Infra and it will be hooked to FAS instead at that
> point.
>
I have to say this makes it a lot easier to see what we are trying to
accomplish. I am not sure what can add to it though as it looks pretty
complete and easy to comprehend.
I can add a "Holy Cookies. Good Job"
> Please offer feedback on the current state, particularly additional content in
> the same style. (If you log in to the Kolinahr instance, I think you should be
> able to just edit it directly, so feel free to make new additions at will, but
> please don't delete anything without first discussing it on the list).
>
OK, so is what we have on Kolinahr right now
* Enough work for one year?
* Too much work for one year?
Followed by:
* Who is going to work on which pieces?
* Who is going to write the new PRD?
Also, while this covers the end-user features we want to support, it doesn't
necessarily cover any changes we want to make to the OS itself.
I'd like to suggest the following to the Outcomes:
"Users of Fedora Server Edition have a very limited attack surface in the
default installation".
Which would come from the following outputs:
* Minimal viable install set content
* Highly-restrictive firewall defaults
And activities:
* Define a minimal package set for install media
* Research the optimum firewall state
Beyond that, we also probably want to have another Outcome:
"Users of Fedora Server Edition have a reliable update mechanism"
Outputs:
* ostree-based installation type
Activities
* Create ostree repository for Server Edition
* Establish hosting for ostree repository
Another Outcome:
"Users of Fedora Server Edition can install it on most hardware and popular
cloud providers"
Outputs:
* Install media for hardware - traditional
* Install media for hardware - ostree
* AMI image (Consider only one or the other for this...)
* OpenStack-compatible image
Yet another:
"Users can deploy Fedora Server automatically"
Outputs:
* Deployment Role (built atop PXE, DHCP, tftp; maybe cobbler)
Hit me with some more ideas! I'll add these to the Kolinahr page for now; we can
do prioritization later.