Compared the four solution you offered, I prefer to solution c) Thanks, Halton. On Tue, 2008-12-02 at 17:50 +1300, Laszlo (Laca) Peter wrote: > 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. This will need little change with what we do now, I choose it.
> > 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. Take projects from GNU community for example, they are actually individual, do not have same release schedule. > > 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).
