Jesse Keating wrote:
> Treat the origin/F-?? as the master for that release, do your long
> running not immediately ready for build work on topic branches thereof
> and only merge them when you're ready to build.
This requires us to know in advance that the work will be long running. In
my experience, this is usually only noticed once the new version has been
imported (with the intent to build it right away), or even once it made it
to testing and got massive negative karma (after all, that's what testing is
for: as the name says, stuff there needs to get tested and can fail).
One case where I had to branch off an old build: I noticed on December 14
that the September 30 kde-plasma-networkmanagement snapshot had been pushed
only to F11 updates and not to F12, breaking the upgrade path. By then, the
F-12 branch had moved on to an October 24 snapshot, but I didn't want to
rush out a newer, untested snapshot to fix the upgrade path, but instead
queue the same one as on F11. (In addition, the October 24 snapshot is
outdated too, Rawhide has a newer one, but current snapshots require Qt
4.6.) But the corresponding F12 build had already been deleted by Koji, so I
had to branch and rebuild a new one. I used the "create a branch with a name
which looks like a build tag to the tag validator" hack and branched
kde-plasma-networkmanagement-0_9-0_3_20090930svn_fc12_x, then built off that
branch.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
