As you know, we currently have 2 JDS spec file repositories:
- spec-files (for GNOME-related specs and their dependencies)
- spec-files-other (for everything else)
In addition, there is the xfce spec file repo and SFE, which
is not part of the OpenSolaris project.
The original goal of spec-files-other (s-f-o) was to make it
possible to build the GNOME-related and non-GNOME-related
packages separately resulting in shorter build times and making
it possible to follow different release schedules from that
of the GNOME community.
It didn't really work: we still build them together, using
the same schedule. The only real difference is that we don't
have the gnome-2-xx branches in the s-f-o, which is more a
source of confusion than anything else.
So we have a few choices for spec file repositories going
forward, but before I go into details, I'd like to summarise
the problem that we are trying to solve:
#____________________________________________________________
#|
#| Given a [large] number of modules from different upstream
#| communities, using different schedules and which have
#| one or more active versions, we need to define spec
#| file repositories and branches that make it easy
#| to produce builds consisting of an arbitrary selection
#| of modules and versions.
#|___________________________________________________________
#
My favourite example is GNOME and firefox. They are on
different schedules but depend on each other (like a sandwich:
GNOME libs -> firefox -> GNOME apps). When GNOME reaches the
end of a development cycle firefox may not, so we want to stay
with a latest stable version of firefox, but when firefox comes
close to its release date, we want to build it on both
the latest stable GNOME and the latest development GNOME,
while still including the stable firefox in the stable GNOME.
When the new firefox passes the quality criteria, we update
the stable build to include the new firefox and stop building
the old one. So there is a transitional period when we
need 3 combinations:
| stable FF | devel FF
-----------------------------------|----------------------
stable GNOME | yes, for Nevada | yes, for testing
devel GNOME | no | yes, for development
In general, each module has a current Stable and possibly a
current Development version. In the Nevada build we always
include the latest Stable version, and the Vermillion build
mostly consist of the Development versions. When module
X is ready to promote its Development version to Stable, it
has to be built and tested in the context of the Nevada build.
So the question comes down to: how many spec file repositories,
when to create new branches and how to deal with promoting
from Development to Stable.
a) One obvious choice is 1 repository, branched when we
integrate a new GNOME release into Nevada.
The advantage is its simplicity: easy to find the location
of the spec files and identify the branch used for a given
nevada or vermillion build.
Doesn't do much to solve the problem of promoting from
Development to Stable, though. Note that currently GNOME
and firefox are in the same repo, so as far as that example
is concerned, this is the current situation. When moving
from firefox 2 to firefox 3, we worked around the problem
by adding hacky --with-ff2/--with-ff3 options into various
spec files to select with version is used.
Less than ideal...
b) A variant of a), but instead of --with/--without switches,
we can duplicate the spec files that are being promoted
and use subdirectories to separate the Development and
Stable specs.
While easier to implement, this is at least as hacky as
the previous option.
c) 2 repos: s-f and s-f-o. s-f is branched according to the
GNOME schedule, s-f-o only has a stable branch and
trunk (devel). s-f-o stable goes into Nevada.
Relatively simple and makes it easy to find specs, but
promoting s-f-o modules from trunk to stable is still
a problem. Special builds are needed that use the
stable branch of most modules in s-f-o and only a few
from trunk.
d) Create individual spec file repos for groups of modules
that are on the same release schedule (typically those
originating from the same upstream community), branch
them according to their own schedules.
This gives maximum flexibility for selecting the
branches for the builds, but makes it difficult
to find the spec that belongs to a specific build.
The contents of the builds have to be defined
explicitely (current we build *.spec from a given
branch).
Thoughts? Comments?
Thanks,
Laca
