On Wed, 11 Dec 2019 15:39:24 +0100
Stefan Hundhammer <shundhammer(a)suse.de> wrote:
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?
my question is how other projects do it? I really believe we are not only library with
consumers. And I also believe that they do not put everything to one place.
Does anybody have a better idea?
I definitively would like to not reinvent wheel, but I think at least small research how
other libraries with plugins do it would be good ( at least we can document why we do not
do it same way ). I think in linux/FOSS worls is definitively bigger projects then libyui
that have to deal with similar challenges and we can at least inspire how they handle it.
Or is there some killer argument against this?
I do not have any "killer" one, but how it will then go with gtk one? and I
agree with stasiek that having separated pkg makes also some sense for me. And what to do
with another plugins like qt-graph? And another code that we maybe use like
Also another potential issue is that if we have everything in one repo, that travis,
jenkins, etc will take much longer to build. Also risk of collisions is bigger. I am also
not sure how other users distro use libyui. If they take tarball from github as upstream
release, then I am not sure how it will work when we have everything in one repo.
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org