openSUSE Lizards

Authors
Adrian Schröter (5)
Agustin Chavarria (1)
Akhil Laddha
Alexander Naumov
Alexander Orlovskyy (3)
Alexey Eromenko
Alin M Elena (4)
Andrea Florio (14)
Andreas Jaeger (44)
Andreas Stieger (1)
Andreas van dem Helge
Andrej Semen
Andrew Wafaa (25)
Arvin Schnell (6)
Beineri2
Bharath Acharya
Bonnie Kurniawan
Brian G. Merrell
Carl Fletcher
Casual Programmer
Christoph Thiel
Christopher Hobbs (15)
Ciaran Farrell (2)
Coly Li
Cristian Rodríguez
Daniel Bornkessel
David C. Rankin
Dean Hilkewich
Dinar Valeev (5)
Dirk Müller (1)
Dmitry Serpokryl (7)
Duncan Mac-Vicar
Enrique Herrera Noya
Eugene Pivnev
FabioMux (1)
Federico Lucifredi
Frank Lee
Gabriele Mohr
Gerrit Beine
Helman Rene Taleno Martinez
Helmut Schaa
Henne (6)
Herbert Graeber
Holgi (2)
Hubert Mantel (1)
Ioan Vancea
J. Daniel Schmidt (1)
Jaime Andrés Vélez Osorio
James Tremblay (7)
Jan Blunck (4)
Jan Madsen (1)
Jan Nieuwenhuizen
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (19)
Javier Llorente (2)
Jigish Gohil (22)
Jiri Srain (1)
Jiří Suchomel (1)
jloeser (1)
Johan Kotze (5)
John Terpstra
Joop Boonen
Josef Reidinger (7)
Juergen Weigert (1)
Julio Vannini (7)
Justin Haygood
Kálmán Kéménczy
Kevin Yeaux (10)
Klaas Freitag (20)
Klara Cihlarova
Klaus Kämpf
Klaus Singvogel
kl_eisbaer (10)
Lars Marowsky-Bree
Li Bin
Ludwig Nussel (6)
M. Edwin Zakaria
Manuel Trujillo
Marcus Hüwe (8)
Marcus Meissner (1)
Marcus Moeller (1)
Marcus Schaefer (3)
Martin Lasarsch (8)
Martin Mohring (8)
Martin Schmidkunz
Masim "Vavai" Sugianto (20)
Matt Sealey
Mauro Parra-Miranda
Michael Andres (1)
Michael Löffler (3)
Michael Skiba
Michal Marek (3)
Michal Vyskocil (8)
Michal Zugec
mrdocs
Nikanth Karthikesan (2)
Oprea Lucian
Oswin Zulu
Peter Nixon
Peter Pöml (4)
Petr Mladek (30)
Petr Uzel (2)
Philipp Thomas
Pragnesh Radadiya
Ray Chen
Ray Wang (1)
Ricardo Varas Santana (6)
Richard Bos (4)
Robert Lihm
Roland Haidl
Roman Drahtmueller
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (45)
Sebastian Schöbinger (4)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (3)
Steffen Winterfeldt (4)
Stephan Kulow (10)
Suman Manjunath
Suresh Jayaraman (1)
Susanne Oberhauser (2)
Syamsul Qamar Ngabito
Thomas Göttlicher (4)
Thomas Schraitle (14)
Thruth Wang
Tuukka (11)
Ulrich Hecht
Wilken Gottwalt
Will Stephenson (1)
Xin Wei Hu





 

Fate Internal, Up- and Downstream

1 Star2 Stars3 Stars4 Stars5 Stars (11 votes, average: 5.00 out of 5)
Loading ... Loading ...
Tuesday, December 16th, 2008 by Klaas Freitag Digg!

motivated by Aaron’s blog post More downstream fun I was thinking about how Fate could be a more important part of infrastructure in the Linux landscape. Fate is now an important part of the Novell/SUSE infrastructure and we are currently in the process to open it up for the openSUSE community. But could Fate also be useful for upstream integration? To let you participate in the discussion I think I should start with some explanations what Fate is and in which environment we are with it.

Fate is a system developed at SUSE over the last few years to track features and requirements for Novell Linux products.  The term “feature” is already is a topic for scientific papers, but how we understand a feature is a functionality  that is not yet in the product but required or wanted. It references future products, in most cases more than one such as SLE and openSUSE.

Fate Feature Tracking EnvironmentThe little sketch illustrates the dilemma in which we are when it comes to product planning. Basically it is all about one  thing: decision taking. Decisions have to be taken about the new functionality  that goes into a product and the tasks internal people work on. This is based on the decision how the product should look alike from a high level point of view. To make a solid decision about the high level product it needs to be clear what we are actually able to put into the product at a given time. That is only a part of what is really going on but let’s leave it with that for simplicity.

You see that lots of the base information which is needed to make
good decisions comes from different people: Product managers have a strong idea of how products should be, the technical project manager knows about dates and technical possibilities and can plan with the engineering managers how that can be achieved with the given amount of people in a given time frame. Technical feasibility is worked out with the developers as they’re the experts. The colored arrows try to visualize the communication ways, different colors mark different topics.

Since we work with the communities we have more input of information: The user community tells what is needed and the upstream communities announce what they plan to do by when.

The part with the internal decision taking is very much based on Fate in the Linux part of Novell and that is working fine. Features come in by a requester and all involved parts can give their thoughts in  a discussion forum. The key functionalities add their priority for the feature and finally PM and TPM come to a decision. Features with a high priority have to make it into the product. Engineering managers can assign developers and they can mark features as finished. All the processes are covered by a set of configurable rules. The Fate system is integrated into other infrastructure parts. There are several clients for different needs, the most mature is the KDE fat client.

What is not yet optimal are two things: There is no good way yet for the user community to community their wishes for upcoming products. We are facing that with opening up a new web based openSUSE Fate client soon. That will involve the user community not only in testing and using the product but already in its planing in a defined way.

A more tricky part is how to involve the upstream communities. It would be great for a Product Manager of a Linux distribution to see the feature plans for upcoming releases of big upstream projects, maybe somehow integrated into the Fate for his product. Would the Fate model as described here in a nutshell suitable for upstream projects?

For example, could KDE or GNOME make use of parts of the process for them internally and provide a structured interface to the downstream parties? If so, that could add a lot of transparency. Transparency is the precondition for flexibility and trust and as a result for better collaboration which would benefit all.

I hope that helps for a basic understanding and would love to hear your opinion. I promise to come up with more information about the Fate system and improve my drawing skills ;-)


Comments

No comments yet.

Sorry, the comment form is closed at this time.