the end-goal of any (product) development model is to get discipline,
accountability, predictability, scalability in order to get stability
and quality on the goods deliverable. Everything else is subsidiary to this.
As i've written before, conary is 'just' a packaging/configuration
management technology, the best one, but still just that. And, that kind
of technology, per definition, as good or evolved as it may be, will
never be a substitute to understand what is being handled in concrete,
and it's role in the environment it runs. Also, no one, on sane
grounds, should expect anyone to be fluent on all packages, all stacks,
all levels. More, the core basis of the whole open source development
model, what really makes it scale, is openness and collaboration. We do
not have the resources, the people, the money, nor we should have the
ego, to try, even pretend to, reinvent the wheel. If something is well
done/maintained elsewhere, and it works and suits our needs, and we can
legally leverage it, we should just use it, and move ahead. We should
just invest our time, which is our most precious resource, in places
where we can add value and make a difference, for the better. Being just
different will not bring us any good, being better will.
With this lines draw clearly draw in the wall, here's what i envision
for foresight3, and beyond...
... on package naming and package Specing
Foresight will be a from the ground, up from the source (:recipe)
full distribution. We will just follow Fedora's package
naming/splitting conventions, wherever they are sane or not. We need
this in order to leverage the works that will come from 'boots'.
Please do note that we will have to follow rigidly fedora at their
naming conventions at binary package level, at recipe level, we have
more flexibility, anyway, for consistence, we will use _not_ cheaply
that flexibility, and if and when we do, we should document properly
why we did it, for future memory. In order to get lightweight on
size we will need more granularity in the way we deliver binaries.
This implies more fine grained pkgSpecing. Again we will follow
fedora on this. A tool will be provided that for any given package,
will give us the fedora spec rpm name of it, and all the different
binary packages it will produce.
... on file layout
We will follow exactly RHs/Fedora file layout conventions, for
compatibility and convenience. Exception, will be hooks, to preserve
existing behavior, or to assure migration paths. If, and when, we
deviate, it should be properly documented why, and the benefits we
get from that.
... on package versions, and patchsets
For all the packages, to which we do not have proper know-how, or
which are not core to the value we intend to deliver, we will use
strictly Fedora as our upstream. When we do not, it should be clear
on our side why, and who is responsible to handle those packages.
The major goal, is to have just two kinds of bugs - either upstream
ones (Fedora) or ones for which we have people savvy enough to
tackle them. Please do note that there are at any given times two
Fedora trees that matter to us - shipped one (N), and rawhide (that
will turn into N+1). Our immediate goal, is to match feature wise a
given stable Fedora release, and then, start leveraging the work
they do in N + 1, as our tools allow that. With that said, we will
not be blindly bleeding edge, and things only should get in
production after it is clear that there's is really added value
there. Again, remember "" At any given time, not try to provide
the "best new technology of tomorrow", but the best "*working*
technology of today" """.
Exceptions are support for 'legacy/corner' technologies like selinux
and gcj support. Regarding selinux. which is largely irrelevant for
our use cases, we have two options either _actively_ ignoring it,
dropping all patches related to it, and all configs selinux related,
or simply have it around, and still ignoring it, as it will be
always off by default. Which one we choose is a matter of what
gets cheaper resource-wise for us. Regarding gcj & associates, which
is largely superseded by the icedtea/openjdk stuff, is adds an
overhead that we can clearly stay without, so we will pretend it
does not exist.
Again, anytime we deviate from fedora, we should document properly .
At higher levels we can, and should, track the goodies elsewhere,
but always in a consistent and documented manner. Picking random
patches from random places is not the way to go.
... on package maintenance
Packaging is not the hardest part. Maintaining a package is. A
logical result of everything said above, is that we should only have
to worry with the stuff we feel confortable with. all else we follow
upstream decisions. When not, we should document.
... on metadata
Albeit conary has good support for metadata (it swallows happily
rpm's and deb's one), we, at foresight, are not actively, yet,
leveraging it. We will, from now. In order to ease maintainability,
scalability, scriptability and integration with 3rd party tools,
metadata for each :source package will start to get stored
separately, say in a INFO file. the goal is to make it easily
parsable. a prototype skeleton bellow
-- x--
[packageName] < -- needs to match recipeName
summary ...
description ...
URL
arch x86 x86_64 # or x86 or x86_64 or noarch
[[license]]
< -- we should have a canonical list of licenses to accept, and if
fetching
something new one, force us to add it to list. also, we may need to to
support packagings with multiple licenses and
comments see bellow
GPLv3
CC # for documentation
[[patches]]
patchName patchOrigin - Fxx/rpath/foresight/add otherSources here))
patchPristiness(optional field only used for non
foresight patches, either does not exist or says modified)
this last field is to warn against too fast patch application if they
have to be modded first. also this will allow to track patch lifetime
'upstream', with info bellow in tracks
[tracks] <-- what we are tracking/following
Fxx (optionalAliasIfRhNamingDifferentFromOurs)
srpm/tarball/whatever.version.XX.f1Y
[sets]
# this will be used in future for dynamic group creation.
# syntax to be refined.
gnome
gnome-lite
[[subpackage and or :component]]
summary
description
[sets]
--x--
the fields to be populated above have two main purposes, to get
plain metadata (descriptions, etc) fetched by our conary policies at
build time (to be consumed by packageKit, etc) and to help on
maintenace (more on this later). For economy, we will reuse,
whenever is possible Fedora's work on metadata (package descriptions
et al, as, again, we have no point in reinventing the wheel.
... on management tools.
mirrorball (http://hg.rpath.com/mirrorball) has already some nice
hooks to compare what is in a rpm repository and what got already in
a conary one. Right now it cares most about binary packages. We will
extend it to introspect source rpms and debs too, and cross the data
we get from that to the data we are putting in the meta-data, as
described above. This way, we will get close to real time reports,
on how we are re: the alternatives, etc. This new tool, whose
development will be lead by Scott Parkerson, who kindly volunteered,
will be the center of all our development activities and will
integrate closely with our issue tracker, and upstream ones. This is
absolutely key to keep us focused and disciplined, and ultimately
for us to scale. The extensions we provide for mirrorball
funtionality will naturally will be provided back to upstream,
rather than being a fork.
... on editions / profiles
Gnome, XFCE, KDE, as we already have people who understand these
well. Would like to have moblin too in the future, allelse we get
commited people too.
... on priorities
get feature parity with the parts we care of F12, at time of F12
release, and go from there. If not possible, F13.
... on groups
Groups are way too complicated right now. We will have a base group,
roughly equivalent to the rPL's appliance one, a minimal GUI one,
with X and the libs/services we want common to all variations, and
all else edition specific (or devel groups). One single top level
group will assure dep closure, per arch.
... on community
our (marketing) focus strategy wise, short term, should be not to
try, 'too hard' to recruit new plain end users, whose will better
served by 'boots', but to make dead easy for power users, and
existing and wannabe developers elsewhere, to integrate in our
community. We really need to cut down on the Signal/Noise ratio we
wave right now, if we ever want to get things to scale.
Why would ogthers come to join us ? - one single reason, not to
think different but to act differently and helping to shape how
things should really become. The fact that we are a small, friendly,
community needs to get leveraged right versus the too big, too gray,
too bureaucratic ones, that exist elsewhere.
-- to be continued
All the best,
António
P.S. This paper does not pretend to be the perfect or definitive answer
to anything. It must be seen as a small part of an ongoing effort to
help us separate what is for us, core, and what isn't, what is
essential, and what is accessory.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel
