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).

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to