Using Red Hat, with 3.000+ employes, as a base seems like a good idea.
Personally I always prefer rock solid stability over bleeding edge, but
for Foresight as a distro I believe the challenge is finding a balance
with regards to programs exposed to the scary place we call the
Internet. I probably don't need the latest version of LibreOffice (at
least not right away), but I do need the latest version of Firefox and
so on. Just as long as a paranoid user, like myself, feel safe there
really isn't any good reason using another distro than Foresight.
// Roger
2013-04-14 14:04, Michael K. Johnson skrev:
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
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
