Im really dont like the idea for use a fedora like base of Foresight ... But im want hear doniphons opinion always change my point of view.
So yes we need a system of delegate responsabilitys for small teams. On Fri, Aug 14, 2009 at 8:23 PM, Michael K. Johnson <johns...@rpath.com>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
