We have a known defect exists in Staging Project process, according to the staging project design(in-ring/non-ring), the requests of a application stack can be dispatched to letter staging and adi staging both, in case the request staged in adi staging relies the request staged in letter staging which may causes sometimes the request in adi staging will not be checked-in at the same round, this leads that application stack have different version in TW and those package had request left in adi staging may does not work well as version unmatched to other library. We see this issue happened on Qt5 stack; KDE Applications, etc. For example: a Qt5 stack update, libqt5-qtbase will be staged in a letter staging however libqt5-qtwebview will be staged in a adi staging, once libqt5-qtbase be accepted that libqt5-qtwebview won't be accept in the same round due to it can not be built before libqt5-qtbase merged to Factory but after - 2-phase update. Therefore we need a way to handle those cases to reduce the gap between Letter staging and ADI staging.

Many of the Uyuni / SUSE Manager web UIs are still based on the no longer maintained Struts framework (version 1.2!) and implemented as JSP pages, while we added newer features based on the Spark framework and React. For me there is a vision of using only one technology stack (especially just one web framework, frontend framework and template engine) eventually, so it is about time to get rid of the old stack. While this is surely a huge effort, why not start with a new login page and then go from there rewriting other pages one by one?

Description

I would like to measure how various services and their software updates in openSUSE TW impact the power consumption of a PC

Project Description