From a release engineering and ease or reproducing a specific build set option d) would be the choice.
But from an engineering standpoint IMO option a)is the obvious choice. Having just one place to go to get your spec-files has huge ease-of-use implications. option d), would require potentially loads of separate repos depending on the module set split that's defined. This would be potentially a nightmare to try and track for an engineer - they would need to checkout both stable and trunk branches for every repository. A Lot of overhead - Increaes the likelihood of duplication, trying to find a specific module spec-file and when you don't find it you could end up commiting a new one to the wrong place etc... My call would be for a) or b), even with the hacky workarounds. As to which one well depends on which is easier for RE :) cheers Matt Laszlo (Laca) Peter wrote: > 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
