Hi, Laca. I still prefer Option A.
Option C, it still can not bypass the build problem we face. but it brings inconvience. I think that it is developer's reponsibility to make sure his package can build with Nevada and Vermillion . Most of our applications are gnome based, they require gnome libs. firefox is a special case, should be hanled seperately. so let dev team to decide version number in Nevada or Vermillion for firefox. > 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 > > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org >
