> I think the first step would be to describe the problem in > more concrete terms. Actual problems that could be addressed, > instead of vague generalizations that could apply to anything. > > Having concrete goals would be good, too. > > If the goals and the problem description are interesting and > deemed realistic, then I'm sure developers would join your > effort. > Here is an outline (anyone is welcome to reviewing it): Main goal: to build a portable OS platform that allows for application inter-operability and flexibility in the interchange of core indentifiable components Principles: 1) a component can be replaced without impact on other components 2) components' interoperability is defined by a contract (API) that although can be extended, it cannot change the rules established in previous baselines. Main tasks: 1) to identify the core components 2) to identify independently repleceable groups of packages 4) to isolate the core components in replaceable units 5) to influence the development of critical software libraries and components as services with a defined API that supports backwards compatibility This project requires the cooperation of the following roles: 1) OS architects 2) Packagers 3) package designers/developers TASK 1: to identify core components Key roles: all This is a task that could be carried out by everyone through a proposal/review process. The scope is to identify those components that we would like to be able to replace (either new releases of the same component or a different competing component) without impacting on the integrity of the rest of the system. Core components can be product suites, like desktop managers, vital libraries like "cairo" or applications like openoffice. An example could be: Xorg KDE GNOME cairo Openoffice Firefox Mozilla Apache Java JVM/JDK gcc glibc TASK 2: to identify independently repleceable groups of packages key roles: packagers Translating in real terms: At the base of the success of this project is the cooperation between a number of different roles that at present might not be happening. An example could be the packager that takes care of building an "rpm" but is not involved in the development and design of the packaged component. The packager in this case would see a shift of his responsibilities from passive package maker to architect and influencer, feeding specific OS requirements to the components' designers. Having that as our goal, we can start with this task that could be carried out by the packager(s) alone. The aim is to place the core components identified in TASK 1 in packages groups. Definition of package group: those packages that are dependent on each other at release level and the replacement of one of them has an impact on(requires the replacement of) one of more of the other packages in the group. We can expect that at present we will be able to identify several intersecting (overlapping) package groups. The completion of this task will add the following value: 1) to achieve a better understanding of the extent of the problem 2) to allow for an initial identification of packages in groups that if replaced at once do not have an impact on the rest of the system, thus enabling their replacement with newer or different groups. TASK 3 - to isolate the core components in replaceable units Key roles: OS architects, packagers, package analysts/developers This is the task where we make significant changes to happen, and really requires the buy in of all of the key roles. If we are serious about this project, I propose to get a wiki page/section, so that we can build and review this and more of the documentation that we will require, keeping this mailing list as the communication channel. Please let me have your comments as soon as possible. -- Mauro Mozzarelli eMail: mauro@xxxxxxxxxxxx -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
