On Sat, Mar 10, 2018 at 04:09:41AM +0100, Kevin Kofler wrote: > Kevin Fenzi wrote: > > yeah, but you would have even better workflow with a side tag. > > The problem with a workflow relying entirely on side tags is that it is > going to increase the risk of conflicts with concurrent changes (a > phenomenon already somewhat present where side tags are used, but using side > tags for everything is going to make it worse). > > If my package depends on liba and libb, and if we have side tags f29-liba > and f29-libb at the same time, when they are merged, the rebuild merged > later will replace the one merged earlier and we will still end up with a > half-broken package, or if we're lucky, the gating will fail the second > merge (but only if the gated merges are serialized, otherwise there is a > possible race condition there too). Do note that the uniqueness constraint that koji has will mitigate things there. For a package to be built for -liba and then -libb, the package will need to have its release field bumped twice. I figure it wouldn't be too hard to check when we merge a side-tag if there is a newer build of a package already available and if so block the merge (I guess that would be very similar to the upgrade path checks between releases, but here it would be between koji tags). Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
