On Wed, Dec 11, 2019 at 03:39:24PM +0100, Stefan Hundhammer 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: > > - 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 > - ... (?)
yast2-ycp-ui-bindings defines %yui_so in the spec file which must also be updated. > 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. Would there still be several source packages with each having a tarball or would there just be one source package generating all RPMs? In the latter case people could complain about more freqently rebuilds of e.g. libyui-qt due to a new libzypp. > 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? > Does anybody have a better idea? > Or is there some killer argument against this? Not being able to update the system to work on libyui for a whole day is for me a killer argument against keeping it like it is now. ciao Arvin -- Arvin Schnell, <aschn...@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: yast-devel+unsubscr...@opensuse.org To contact the owner, e-mail: yast-devel+ow...@opensuse.org
