[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: dist-git proof of concept phase 2 ready for testing



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]