Richard Hughes wrote:
> Not true for the majority of GNOME and KDE packages. You can't test
> gnome-control-center 3.9.1 without installing gnome-settings-daemon
> 3.9.1 as well. Not because of any library interface issue, but because
> g-s-d provides the D-Bus API used by g-c-c. The desktop, like it or
> not, is getting more monolithic, not less. FWIW, that's a totally good
> thing.
Speaking of KDE because that's what I'm familiar with:
* The KDE version upgrades are already being pushed as groups. All the
4.10.2 packages are in a single update in Bodhi. That makes a lot of sense
because upstream releases them together at the same time. So doing monthly
batching in Fedora will only mean we'll be out of sync with upstream, it
would not provide any grouping that is not already being done.
* In KDE land, you can actually use old kde* on new kdelibs (at least you
should be able to; it's not really tested or supported for the core KDE
packages because they are updated at the same time as kdelibs and thus
expected to be used together), but not new kde* on old kdelibs. So it would
be possible to test the updated packages separately in reverse dependency
order. It's just neither practical (time-wise) nor necessary. The monthly
grouping is already done by upstream there.
* KDE is getting less monolithic, not more. KDE Frameworks 5 will even be
taking the splitting to extreme levels.
Basically, where upstream releases a large set of version updates
simultaneously (e.g. KDE coordinated releases), we are already pushing them
as one group and downstream batching would bring no benefits whatsoever,
whereas for small leaf packages (e.g. colord-kde), the updates can easily be
tested in isolation (even much better than when mixed with a huge batch of
mostly unrelated changes; if, say, a batch of colord + kdelibs + colord-kde
breaks colord-kde, how do we know which updated package broke it?).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
