No edit summary |
|||
Line 66: | Line 66: | ||
=== Environments and Stacks === | === Environments and Stacks === | ||
==== General ==== | |||
The target audience are members of the Fedora community who develop, test, package and deploy software for or on Fedora. This includes deploying and running a number of applications written in different languages, application development using different language stacks and their versions, building, and language-specific and distribution-specific packaging. | |||
==== Personas ==== | ==== Personas ==== |
Revision as of 17:23, 2 March 2015
Personas
The following section is about personas; use cases and user stories to target documentation on.
General
For every Fedora flavor there are some general personas that can be used in all categories:
Case 1: Technical Tony In this case, Tony is a certified IT professional who has much experience as well as knowledge. He will be using Fedora for either work or home and will appreciate getting solutions that provide a greater depth of knowlege.
Case 2: Novice Ned Ned is not so experienced. This may be his first installation. Ned will require step by step instructions so he does not get frustrated. Ned will not be interested in VMs unless he is also Converted Carl
Case 3: Converted Carl Converted Carl is either trying or has moved to Linux from Windows or is going to be installing a Fedora VM on his windows machine. Carl may need some translation of terminology. Carl may be either Novice Ned or Technical Tony, but he is unfamiliar with Linux terminolgy and commands.
Workstation
(cut n paste from [1])
Target Audience
General:
Programming Environment: web languages and tools, open source databases, IDE, Compilers, debug tools, performance monitoring
Desktop apps should be sufficient to make this system the user's only computer.
Case 1: Student
Engineering/CS student who needs a personal system for software classwork and personal projects. Software class work may require particular tool chain versions. Tries out new versions of open source applications when released. Uses computer to play games. Ability to play 3D games from commercial publishers distributing games for Linux. Multiple developer environments i.e. school standard for class work, latest tools for personal use.
Case 2: Independent Developer
Personal development system for an independent software developer doing contract work or developing apps for a new opportunity.
Desktop Apps: Up to date desktop with email client, browser, productivity suite, messaging, and a complete set of desktop apps and utilities. Desktop apps should be sufficient to make this system the developer's only computer.
Generally a single development environment with the latest web development tools.
Easy to configure Virtual Machines for testing software.
Case 3: Small Company Developer
Software developer working on an individual project or coordinated small team. DevOps.
Generally a single development environment with the latest web development tools. Easy to configure Virtual Machines for testing software.
Testing in local VMs and on dedicated testing systems.
Case 4: Developer in a Large Organization
Software developer working on a large, coordinated project in a large organization.
Support for enterprise login. Multiple developer environments i.e. current project and maintenance work on older projects. Testing typically on a target system in a testing lab.
Other users
While the developer workstation is the main target of this system and what we try to design this for, we do of course also welcome other users to the Fedora Workstation. In fact, many of the changes and improvements we expect to implement for developers will be equally beneficial to other user segments. For instance our plans around multi-screen handling and improved terminal functionality should also be highly beneficial to a system administrator. Or the work we are doing to provide a high performance graphics workstation would be useful to people who want a Linux gaming PC. Or a student who just wants a system with a productivity suite to write papers will of course get benefit from the fact that we do ship a good productivity suite. We will welcome feedback and requests from all our users and try to accommodate it, as long as it doesn't negatively impact our developer target group and we have people available who have the time and ability to work on the requests.
Server
Cloud
Environments and Stacks
General
The target audience are members of the Fedora community who develop, test, package and deploy software for or on Fedora. This includes deploying and running a number of applications written in different languages, application development using different language stacks and their versions, building, and language-specific and distribution-specific packaging.
Personas
(cut n paste from [2])
Persona #1: Alan the Big Data analyst Alan is a Big Data analyst and member of the Fedora Big Data SIG. He uses a number of applications written in different languages to perform the data analysis. He wants to focus his time and effort in the application and the actual data analysis. He want to minimize the time and hassle spent obtaining, compiling, packaging and maintaining the applications that he needs. The form of packaging (rpm, deb, npm, other) isn't as important to him.
Problem statement: Currently, there is a lot of hassle and pain in dealing with non-primary (i.e. C/C++, Python, Perl) language stacks in Fedora. Although Alan wants to focus his time in the application and the actual data analysis, he too often finds himself spending time managing the language-specific toolchain needed by the application.
Cause #1: The upstream application authors usually assume that any developer would just be using the language-specific packaging ecosystem rather that also taking into account the downstream distribution-based packaging and dependency management systems. This is a problem since there are many differences between language-specific packaging ecosystems and the Fedora way of packaging software.
Cause #2: Many upstream applications use very brittle versioning. In other words, each application expects the user will be able to have its particular versions of the runtime, compiler and libraries available.
Example #1: Applications written in Scala require different versions of Scala, some need v2.9 and some need v2.10. Although Fedora could provide both versions in the same release (via SCLs or by manually maintaining two Scala packages), they would both need to be resolvable via Apache Ivy, rather than just providing both binaries, "scalac29" and "scalac210".
Example #2: The version of Jetty in Fedora does not work with Java 6 and the Apache Hadoop upstream isn't ready to abandon Java 6 yet. So the Big Data SIG ends up maintaining a patch to Apache Hadoop for Jetty 9 that will live purely in Fedora for quite a while to come. Although this could be worked-around by using compat packages for Jetty for a couple of Fedora releases, it just hides the fact that there is a mismatch in expectations between Fedora and upstream application authors.
Example #3: Node.js has its package/dep management tool available in Fedora, but very little of the language ecosystem / base libraries are packaged and available in Fedora.
Possible solution: Fedora would need a way to provide language-specific ecosystems in a way that aligns with how these language itself are used and applications written in them are developed and distributed.
Persona #2: Student or Corporate developer needing multiple development environments Billy is a CS student with multiple assignments that need different development environments/stacks to build. Bob is a corporate enterprise developer who is both developing new applications using the latest technology stacks while also maintaining older software releases that use older libraries and tool chains.
Problem statement: While they can setup different OS's or environments in separate virtual machines, it is a lot of work and wastes a lot of disk space and time. Being able to install multiple environments or versions of stacks in the same Fedora instance and switching between them on a per-project basis would be much easier and more efficient.