Page Operations
Browse SpaceForesight Linux 2.0 Development Overview
Foresight 1.x Review
Developing and packaging for Foresight Linux 1.x, including contributing to the labels fl:1, fl:1-devel and fl:1-contrib, is a simple process. These labels are the active or "close to production" branches of Foresight. Packaging for Foresight 2.x is an ongoing process, more of which is covered below.
Continuing with Foresight 1.x for the moment, the labels break down as:
- fl:1 - strict production
- fl:1-devel - Staging and development of new packages
- fl:1-contrib - Both production and devleopment, and in hindsight, probably not the best idea. In theory, fl:1-contrib are packages not in fl:1 or fl:1-devel, and not a dependency of packages in fl:1 or fl:1-devel.
Foresight 1.x Development Issues
Issues within Foresight 1.x derive from the fact that rpl:1 was created to help users create and manage appliances, and not a desktop distribution. Due to the strength of Conary, Foresight is a bit of a miracle, as it has been built using a mixture of rpl:devel, a deviating Xorg, and a partly different toolchain.
Foresight Linux 2
Current State
Creating and managing packages for Foresight 2.x is more elaborate. Today we have two labels, fl:devel and fl:2-devel, and we will be adding fl:2-qa and fl:2. fl:devel is used as a root containing only the :source of all packages in the 2.x. Once the :source is committed, packages are shadowed (cvc shadow) to fl:2-devel and then packaged using rMake.
Future state
With the greater need for quality assurance, and the creation of the fl:2-qa label, packages will flow from fl:2-devel to fl:2-qa for testing, and once tested, to fl:2. This process needs to finalized, as a couple different options exist, including:
- Should we promote to fl:devel, and from there shadow to fl:2-qa?
- Or, should we go straight from fl:2-devel to fl:2-qa
The newly constituted QA team needs to work with the Development team and finalize this process as packages are ported form fl:1 to fl:2.
Foresight 2.x gains much needed freedom and flexibility due to rpl:2's more modular and fine grained approach, but it comes at a price. Creating the initial modular layout, of all subsystems, will make Foresight 2.x future proof, but requires heavy lifting up front. The average packager will find this uninteresting, but until this work is complete by the core development team, the repository just isn't ready for the averager packager, which is our current status.
Current Issues developing for Foresight 2
The organic issues with 2-devel are two fold:
- The Foresight 1.x tree needs to be maintained
- fl:2-devel is more complex for packagers, because of requiring everything to work in both x86_64 and x86, and also to be rMake ready. Additionally, the different editions, including GNOME, KDE and XFCE also creates complexity.
Most importantly though, the current focus through the alpha and beta process is not necessarily to have the most packages (though Conary makes adding packages easy and quickly), but to make sure the underlying framework of 2.x is scalable and stable.
Porting from 1.x to 2.0
Almost all :source files from 1.x should cook out of the box in 2.x. The core developers have tried hard to change the naming conventions in 2.0. File system layout has changed minimally, but only in some key areas. Because of the combindation of rpl:devel evolving, and Foresight's adherence to freedesktop.org standards, and Foresight 2.x doing away with some awkward decisions made with Foresight 1.x (such as closed graphic driver flavors), packaging in Foresight 2.x will be even easier than 1.x
Current developement of the 2.x alpha is to continue to work on the core modules, including xorg, udev, hal, dbus, etc. As this work continues, developers are encouraged to continue adding and porting software from 1.x to 2.0, especially considering the relative maturity and stability of the first alpha so far.
Development Next Steps
- Virtualbox will soon be added to the repositories making it easy for developers to actively maintain 1.x and 2.x side by side. This will also help users test the 2.0 alpha without having to wipe their hard drive and install.
- rPath will be moving the rBuilder repository to a dedicated server that includes Conary 2.0. Having a dedicated repository should offer additional stability, speed and performance. This will offer better access control, including limiting what labels developers can committ to.
- The Marketing team is also currently reviewing the process in becoming a Foresight user and developer. Once this process is finalized and published, Foresight's leadership will be reviewing all developers on Foresight's rBuilder repository, and editing which developers have commit access.
- As Foresight expands with GNOME, KDE and XFCE editions, developers will need to think more broadly of Foresight as a distribution and platform when building packages. One of Foresight's goals is strong GNOME, KDE and XFCE integration.
- Foresight is in need of greater, and more detailed, developer documentation. Specifically, documentation needs to be written on Foresight's stack, layout, design and integration. It is our goal that developers understand Foresight's core philosophies to avoid reinvinting the wheel, in addition to understanding how other distributions are configured. This will help in understanding best practices, and should be an area of continued focus.
- We should continue to develop a mentoring process for packagers, including how to port packages from 1.x to 2.0 or for those who are new to Foresight and wish to learn how to package. This can be done through mentor / mentee programs or scheduled sessions in IRC. The Development and / or QA teams should finalize this process.
It is an exciting time for Foresight, as we take the next step in developing Foresight's core platform, adding KDE and XFCE to our already existing GNOME edition, and attract more users and developers. If you have questions about this document or developing for Foresight, please stop visit the #foresight-devel channel on Freenode IRC.
Antonio Meireles
Ken VanDine
Paul Cutler
December 1, 2007
we should focus only in gnome desktop, foresight is a gnome distro, not a kde or xfce distro
Posted by Anonymous at Jan 24, 2008 17:20
|
i'm sorry not us,you(developers,because i'm just a user...(I'm the guy that wrote the last comment)
Posted by Anonymous at Jan 24, 2008 17:22
|
Sorry I cant agree. You havent brougth up a single argument why you think this should be that way. On the other hand I would say Foresight is not only a GNOME distro but also the only real Conary based desktop distribution. Conary itself is interesting for every desktop. But before we wait for others to create redundant work when it comes to boot mechanisms, kernel, hardware support, Xorg and many more it was decided to create variants of Foresight. This indeed is soemthing that Conary itself encourages by its architecture. Also if we are able to get developers that just dont work on GNOME but use any other desktop this brings additiona eyes and hands to the core which is shared alongside all variants. Whioch then again means that support for other desktops in long term means that Foresight GNOME will become better. I dont see any benefit in focusing on GNOME as long as the variants are seperated. What Foresight needs now is more developers, so that the quality of packages gets better. And more eyes can see more issues and fix more issues. In the end the variants are then more about the GUI frontend and a package selection that works best for the one or the other. Also take into account that users tend to run a mixed environment like with GIMP and Koffice. So just to say we dont provide andy KDE package will also turn away GNOME users who like to use some packages from KDE.
I agree with Thilo...there are so many more reasons to do multiple GUIs. Though gnome is nice, only some computers can run it. What about the older boxes, who want gnome, but can't fulfill the requirements of a gnome desktop, but like the lightweight footprint of Xfce? What about those that like KDE 4's spanking new interface, and want to mix it with the abilities of a Conary-based packaging system? As he said, by attracting more people through GUIs, we get more involvement and dedication to Foresight. Also, different GUIs that support different platforms = Foresight on compatibility with more computer systems. This also leads to the same goal - more machines using foresight, and a much better developed desktop distro based off of RPath.
-Jamesha Fisher
Posted by Anonymous at Apr 06, 2008 02:57
|
I saw somewhere a proposal for using different branches for gnome/kde/xfce in relation with the main foresight branch. I think it's a pretty good idea.