On Wed, 11 Dec 2019 15:39:24 +0100
Stefan Hundhammer
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:
- libyui - libyui-rest-api - libyui-qt - libyui-qt-rest-api - libyui-qt-pkg - libyui-graph - libyui-ncurses - libyui-ncurses-rest-api - libyui-ncurses-pkg
...and later even the externally maintained ones:
- libyui-gtk - libyui-gtk-pkg - ... (?)
The Annoyance =============
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 in OBS.
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.
The Future ==========
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, libyui-ncurses, ...).
What do you think?
Hi, 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 libyui-bindings? 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. Josef
Kind regards
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org