[rdo-list] Proposition to get more CI promotions

[Alfredo Moralejo Alonso]

On Sat, Aug 13, 2016 at 11:21 AM, Frédéric Lepied
<frederic.lepied at redhat.com> wrote:
> Hi,
>
> Our CI promotion system is as if we were running downhill: we cannot
> stop and the only way to fix issues is to move forward by getting new
> fixed packages. And it usually takes days before we can get the fixes
> and by the time we get them we can have other issues appearing and so
> never being able to have a promotion.
>
> I would like to propose an improved way of working to get more CI
> promotions. When we have failures in our tests, we do like we do
> today: debug the issues and find the commits that are causing the
> regression and working with upstream or fixing packaging issues to
> solve the regression.
>
> The proposed improvement to get more CI promotions is, while we wait
> for the fixes to be ready, to get the oldest commit that is currently
> causing an issue from the current analysis and to try the previous
> commits in reverse order to promote before the issues appear. With the
> database of DLRN we have all the information to be able to implement
> this backward tries and have more chances to promote.
>
> I'm in holidays next week but I wanted to bring this idea before been
> completely off. WDYT?

In the past we already applied this approach a couple of times for
upstream issues that took longer that desired to be fixed (these cases
lead us to move to the current u-c pinning for libraries). IMO, this
has some drawbacks:
- Breaks the consistency principle we try to enforce among packages in
RDO repos.
- Requires manual definition of the versions or commits for each package.
- When a package is pinned to a specific commit or version, we stop
packaging and testing any new commit, so we are delaying and piling
the detection of new issues that may appear in the package.
- Currently, DLRN doesn't manage properly moving back to a previous
commit whenever a new one has been built. It requires manual
error-prone tasks to be performed on the dlrn instance (anyway it'd be
probably a good idea to implement this us.

IMO, we shouldn't use this as a systematic approach for managing
versions in our repos to enforce promotions but only as last resort
for exceptional cases. Anyway, it's probably a good idea to improve
dlrn to implement this use case in a easier and cleaner way.


> --
> Fred - May the Source be with you
>
>
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com