2016-06-23 9:14 GMT+02:00 Javier Pena <javier.pena(a)redhat.com&gt;: > Hi all, > > RDO Trunk repos are meant to package the latest upstream commits, but in > some rare cases we may need to pin a specific package to a non-latest > commit to temporarily fix a breakage. > > This week, we had one of those cases with keystonemiddleware, but the > procedure used to do it caused some disruption because some commits were > rebuilt, breaking the current-passed-ci and current-tripleo repos for > centos-master. > > Looking for alternatives, my first idea was the following: > > - Temporarily take that package out of rdoinfo using a specific tag (e.g. > tag: to-fix) if possible, I'd like DLRN to keep building these to keep track of their statuses and allow running CI jobs so that they don't get left out. It'd mean adding logic so that DLRN skip regenerating repo snapshot and put them in a separate staging repo. Considering the low number of pinned packages, I'm +0 about it.

> - And add a working package to an "overrides" repo, included as part of > delorean-deps.repo +1 > > This avoids any DLRN db hacks, but stops processing updates for the package > until the breakage is fixed. > > What do you think? Any alternative ideas? > > Thanks, > Javier > This is likely the best path. H. _______________________________________________ rdo-list mailing list rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com

----- Original Message ----- > 2016-06-23 9:14 GMT+02:00 Javier Pena <javier.pena(a)redhat.com&gt;: > > Hi all, > > > > RDO Trunk repos are meant to package the latest upstream commits, but in > > some rare cases we may need to pin a specific package to a non-latest > > commit to temporarily fix a breakage. > > > > This week, we had one of those cases with keystonemiddleware, but the > > procedure used to do it caused some disruption because some commits were > > rebuilt, breaking the current-passed-ci and current-tripleo repos for > > centos-master. > > > > Looking for alternatives, my first idea was the following: > > > > - Temporarily take that package out of rdoinfo using a specific tag (e.g. > > tag: to-fix) > > if possible, I'd like DLRN to keep building these to keep track of > their statuses and allow running CI jobs so that they don't get left > out. > It'd mean adding logic so that DLRN skip regenerating repo snapshot > and put them in a separate staging repo. > > Considering the low number of pinned packages, I'm +0 about it. Would it work if we just added the package to the overrides repo, making sure it has a higher version number (or epoch)? The only issue I can think of is upgrades.

> > > - And add a working package to an "overrides" repo, included as part of > > delorean-deps.repo > > +1 > > > > > This avoids any DLRN db hacks, but stops processing updates for the package > > until the breakage is fixed. > > > > What do you think? Any alternative ideas? > > > > Thanks, > > Javier > > > > This is likely the best path. > > H. > > _______________________________________________ > rdo-list mailing list > rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com >