On Tue, 2007-10-16 at 11:25 -0400, Jesse Keating wrote: > On Tue, 16 Oct 2007 17:05:51 +0200 > Hans de Goede <j.w.r.degoede@xxxxxx> wrote: > > > So all in all: > > -calling it alpha / beta / release candidate instead of test# +1 > > -no freeze for alpha +1 > > -early branching (I would say a week for the RC) +1 > > -making builds in the release branch goto updates-testing after > > branching -1 (esp combined with early branching) > > Good, discussion! > > Here is the problem, if the build is not deemed "good" by rel-eng to be > in the release after the release candidate where does it go? Basically > the idea is that once the RC hits, "development" of the release is > done, but we want to enable developers to prepare updates to the > pending release to be able to release them out to updates-testing > shortly after the release. Having the builds from the branch be tagged > as if the release were already out helps in this regard, as they're > already in the right place to be prepared as an update within Bodhi, > and if a rel-eng request is made to bring it into the release if > rel-eng agrees it's a simple tag action to "move it", and if we say no, > no tagging action is necessary it's all set up to be prepared as an > update. > > Does that clarify why we're tagging them as potential updates at this > point? I still don't get the point. Are you talking about rel-eng forking (== CVS branching) the "release" at "RC-time" and launching "updates" at "RC-time"? Ralf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
