The Problem of the Day
In the last few days we were reviewing and merging Rodion's changes to the
libyui packages for the REST API and better testability.
The Recurring Problem
We found out (again) that it's a very painful and error-prone process to get
a green build from Travis and to submit all those libyui packages; the
library SO version had to be bumped from 10 to 11 to ensure binary
compatibility, so Rodion had to touch every single one of all those libyui
packages and create pull requests for each one:
...and later even the externally maintained ones:
- ... (?)
This is error-prone and tedious; there were build problems in the in-between
stages all the time, and they are not easy to resolve, and we had one pretty
unhappy Dimstar who saw failing things all around him.
Only for the very first of those PRs there is a realistic chance for a green
Travis build; for all subsequent ones, there is only the (now outdated)
docker image that also includes those libyui packages. That image needs to be
rebuilt, but that fails because now there is a libyui with a higher SO
number, but no matching libyui-something packages.
The Pragmatic Brute-Force Fix
So the only way out is to brute-force merge despite red Travis and hope for
the best. And to do this a couple of times until it gets green in Jenkins and
This is a mess. There must be a better way; a way without very unhappy
release managers that are confronted with half-ready UI stuff that breaks all
kinds of other packages.
So, what can we do?
Is it really a wise idea to have all those UI packages fragmented into so
many different source repositories?
Unify the Fragments?
Would it be better to have one large libyui repo that contains the base
libyui, and also most of the others (except libyui-gtk* ?) and create all the
binary packages that we have now from that single source repo?
That would give us a chance to do atomic changes; a transaction with a
well-defined "before" and "after" state and no in-between mess.
We'd have ONE pull request for all the different subpackages. We could review
that as a whole and not get into a PR frenzy when things need to happen
quickly to avoid undefined in-between states.
Of course we could still work separately in the different UI parts (Qt,
NCurses) with different people. We could still do PRs for those parts
separately if we want to.
But we could (and should) have one central place where things like the UI so
number is defined. Not sure, but maybe we should also have one single
consistent package version number for all the subpackages (libyui, libyui-qt,
What do you think?
Does anybody have a better idea?
Or is there some killer argument against this?
Stefan Hundhammer <shundhammer(a)suse.de>
SUSE Software Solutions Germany GmbH
Geschäftsführer: Felix Imendörffer HRB 36809 (AG Nürnberg)
Maxfeldstr. 5, 90409 Nürnberg, Germany
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org