Rune, thank you. I think that Foresight needs to focus on what is unique to an Open Source Conary-based distribution. We don't have the resources to re-invent lots of wheels.
Foresight flourished most when it was constructed on top of on an actively maintained base distribution (rPL). We don't have the focus on updating everything in the distribution. The things that we do update, we do a good job with, but we lag in others. My work on the Conary build side was about automation. Automating making use of work others had already done, like recognizing patterns from using auto* tools and determining build requirements, and like creating Conary's policy engine that automates many build tasks. If (as is currently clearly true) we don't have the resources to keep all the facets of the distribution up to date, I want to focus on automating importing external work (standing on the shoulders of giants) for the things that we don't want to change, freeing us to work explicitly on the things that we do want to change. I think that the most promising way to achieve that is to take one or more upstream distributions, and automate building subsets of them from source into primarily automatically-maintained Conary-package distributions. Then build Foresight relative to that upstream. This way, we would consume updates (and report bugs) relative to updates from a maintained upstream for the bits we do not touch, and do updates ourselves for the bits we do touch and care about. My Red Hat history will show in my bias to prefer using various distributions maintained in part or in whole by Red Hat as a base to work on (and contribute back to where appropriate!) but it's not just my bias, it would also be easier because we already use Red Hat conventions for the most part (if only because of our rPL history). That said, if someone wanted to take ownership of (say) the work required to build a base subset from Arch I would think that would be an appropriate project also to be under the Foresight umbrella... That feels to me like an extension of the automation work I've done already. For building native Conary packages more directly from srpms, it feels to me like using RPM like autotools... That seems to me to be at least worth discussion. Opinions? On Sun, Apr 14, 2013 at 01:36:41AM +0200, Rune Morling wrote: > So, > > Roelof's recent cry for help re. porting Cinnamon strikes me as yet another > data point in the mounting evidence pointing to the fact that we clearly do > need to come together -- sooner rather than later -- in the name of > focusing our efforts on assembling an easier to maintain base system (the > so-far-mostly-mythical FL3). > > I personally suspect that, in the course of doing so, we would do well to > take a long, hard look at what we are and come to a sensible, sustainable > decision about what we want to be, where we want to go, where we want to > provide value and where we simply want to be e.g. a co-operative and > pragmatic derivative of another distribution. > > As far as target audience goes, I could see us catering to someone who > wants a reasonably sane base from which to build custom re-spins which > again take advantage of the capabilities that Conary offers in terms of > software life-cycle management -- especially now that Conary is being/has > been re-licensed under a business-friendly, permissive license. I also > don't see us competing with neither Ubuntu nor Fedora and their ilk and I > think we would do well to flat out admit that we don't have the resources > to keep chasing that particular pipe dream. > > In my view, what we need to focus on is the niche where the "intelligent > developer" roams, the developer who needs to manage many machines with few > resources and is thus essentially forced to work smarter than what is > possible with the tools offered by existing distributions. In that niche, > Conary is a strong selling point, as is a high degree of similarity to a > well known and widely used distribution such as fedora. > > Michael recently made some edits to the Foresight Linux Development page on > the wiki[1], which are IMHO very much in step with the reality of what FL > is and has been for the past couple of years. Prior to Michael's edit, the > wording in the Goals section on that page was something I originally > adapted from what is probably best described as "grand visions from the > past". And my wording was a *very* conservative version of that grand > vision. > > So, in summary, scaling back our ambitions and aggressively honing our > focus on our core mission might just be what the doctor ordered for FL to > thrive in its niche-within-a-niche going forward. > > Or in the timeless words of Antoine de Saint-Exupéry: > > "Perfection is Achieved Not When There Is Nothing More to Add, But When > There Is Nothing Left to Take Away" > > > -Rune > > [1]: > http://wiki.foresightlinux.org/wiki/display/DEV/Foresight+Linux+Development > > _______________________________________________ > Foresight-devel mailing list > [email protected] > https://lists.foresightlinux.org/mailman/listinfo/foresight-devel _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
