I'd like to make a few points clearer based on off-list discussions. I'm not saying that the work that António is doing on an import fully built from source has no value. I'm merely saying that it is not clear to me that it has value over a binary import, and I want to make it clear that there is an option here that it is not clear to me has been considered, because it's not clear to me that the Foresight development community is even aware that it is an option.
If the from-source rebuild is the easiest to maintain and provides clear value that furthers Foresight's core differentiation, great. When António returns, I'd be interested in hearing his opinions on what specific value the from-source rebuild provides beyond a binary import. Finally, it doesn't have to be all-or-nothing -- another way of reading and understanding my proposal is that importing Fedora binaries *where it makes sense* is OK. If *where it makes sense* for Foresight is nowhere, that's fine. There might still be utility to Foresight in having a binary import of Fedora if only for comparison purposes -- "Did the Foresight rebuild introduce this bug? Well, try "conary update randompackage=fedora.rpath....@fedora:15 and see if it goes away." On Fri, Aug 14, 2009 at 09:23:28PM -0400, Michael K. Johnson wrote: > Rune asked me to share some comments from a discussion we had. He > noted that things have seemed slow in Foresight lately, and I think > it's obvious to everyone why -- despite having several people who > are formally recognized as Foresight developers, a lot of the core > has remained a one-man operation. Ken and António both have shown > nearly boundless energy and commitment as core developers, and are > responsible for a lot of Foresight's success, such as it has been. > A few somewhat more specialized contributors have made truly > major ongoing contributions -- one of the easy examples to cite is > Pavel's ongoing OpenOffice.org work. For several years, Justin > provided excellent kernel support. And so on. Most of the existing > Foresight developers fit into this second category. I've been rather > on the fringe, honestly. Perhaps that gives me more perspective. > > What Foresight doesn't have is pure OS distro specialists. This is > showing a lot right now, when nothing has shown up in a released > group on fl:2 for months. António has made up for many manpower > deficiencies in the past by burning the candle at all five ends, > but that is not sustainable. > > I'd like to propose a radical return to what Foresight has been > good at in the past, which necessarily implies deciding to walk > away from some of the things that the Foresight development > community has desired to become (sometimes with more success, > sometimes with less). > > Originally, Foresight was about getting the latest versions of > cool new software to users quicker. Since the point of the latest > versions is that they are changing rapidly, this necessarily implies > that the target users are those who accept and relish this change. > The technology that enabled Foresight was Conary: with Conary, > Foresight could be built on top of another distribution. rPath > Linux provided that base on top of which Foresight could focus on > the new bits. > > However, the fact that Foresight is rolling to new versions at > any time and rPath Linux is maintained as a classic stable > distribution, and that rPath has not found strategic value in > maintaining a constant stream of development updates for a set > of rapid releases of new versions of rPath Linux, has created > an immense amount of duplicated work in Foresight, outside of > the core competence and purpose of Foresight. We saw this with > fl:1; it got better when fl:2 was closely based on rpl:2, and > now that fl:2 is barely related to rpl:2 we're back to progress > being very hard to attain. > > I think it's time to propose a change. > > Because I'm rPath's Director of Operating Systems, in charge of > rPath Linux, this may come as a big shock, but perhaps I'm the one > in the best place to say this: rPath Linux is not the right base > OS for Foresight. rPath Linux is a great OS for the purpose for > which it was built, and delivers great value to rPath's customers > for building server-oriented application stacks that include a > versioned operating system -- in fact, it is based on demand from > those customers that rPath has concentrated on doing incremental > improvements to a stable OS base rather than new OS versions. > The development model of rPath Linux is too divergent from the > development model of Foresight to make it an appropriate long-term > base for Foresight. > > Most of you know that rPath now provides multiple OS bases > by importing existing OSes built with other technology into a > Conary repository. We have automatically-updated imports of SLES > 10 and SLES 11 (both available by subscription only), CentOS 5, > and Scientific Linux 5. We have imported a version of Ubuntu > Hardy as a functional proof of concept that we can improve based > on customer demand. We have done some work on importing a few > other OS variants, too. We do this with a tool that we can make > available as Open Source so that Foresight is not dependent on > rPath to maintain the import of another more frequently-updated > OS as a base. > > I think that Foresight needs to be based on an upstream distro that > is regularly fully updated and refreshed, and that is maintained by > distro specialists with experience and expertise that is just plain > missing within the Foresight development community. That distro > needs to be imported into a Conary repository; that will allow > Foresight to continue to use Conary to manage the process of building > a set of consistent modifications relative to that upstream distro, > providing a true rolling release. That would allow Foresight > developers to concentrate on only the problems inherent in > integrating the very latest development source against a recent > base that is relatively close to the basis on which the software > is maintained. > > If I were to make the decision of which distro to use as a base, I > would choose Fedora, not because I was the original Fedora leader, > but because rPath Linux has followed many Red Hat conventions, and > therefore the change would cause less turmoil on installed systems > and would require less ancillary work (for example, fewer changes > would be required to anaconda for installable ISO images). However, > it's not infeasible to choose another distro that is rapidly updated, > such as Ubuntu; it would just take more work (*lots* of anaconda > development, a good bit of development on the OS importer tool; and > I don't know who has the time to step up to do that work). For the > purposes of this proposal, I'll just say "Fedora" as a reasonable > proxy for whatever upstream the Foresight developers might choose. > > I want to be clear that part of what I'm proposing is that Foresight > be built on a *binary import* of Fedora into a Conary repository, > updated with all security updates that are released for Fedora, with > only things that are clearly important for Foresight's unique vision > built separately for Foresight. I suggest that to accomplish that, > the Fedora import should stand alone -- it should be useful per se. > That would mean that a user could install a Conary-managed Fedora > system, migrate to Foresight based on the same Fedora version, > migrate back to Fedora, and so on. That would make Foresight's > differentiating value clearer, and it would be very easy to > understand what's different between Fedora and Foresight. > > It would also mean that Foresight would be *rebased* to every > new Fedora version. It wouldn't have to happen immediately on > the release of a new Fedora version, but when deciding whether to > deviate from upstream Fedora in Foresight, a specific Foresight > developer would either have to successfully argue that the deviation > is required only for a single upstream Fedora version, or explicitly > volunteer to maintain the deviation indefinitely. > > In the Fedora-based Foresight universe I imagine, there would be > at least four sources for binaries that are included on a Foresight > system: > 1) Packages included in a stable release of the base Fedora OS > 2) Specific rawhide packages, either imported as binaries or rebuilt > 3) Specific packages from third party repositories built for Fedora > that are useful for Foresight but for whatever reason are not > acceptable for inclusion in Fedora > 4) Specific Conary packages that are newer versions of packages from > Fedora or are unique to Foresight for whatever reason > > I'd love this to be worked as a cooperative relationship with the > upstream project. I see this as symbiotic, not parasitic -- the sort > of thing I would have wanted to encourage when I was the Fedora lead. > > Am I crazy? > _______________________________________________ > Foresight-devel mailing list > Foresight-devel@lists.rpath.org > http://lists.rpath.org/mailman/listinfo/foresight-devel _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
