problems with upgrade of kde

[Harald Sitter]

On Donnerstag, 21. Mai 2009 01:00:19 Richard JOHNSON wrote:
> On Wed, May 20, 2009 at 06:57:17PM +0200, Harald Sitter wrote:
> > Neversfelde was kind enough to provide us server capacity. Soon (i.e. as
> > soon as I am able to master up the code for that) we will direct all
> > Ninja Release Packaging through said server which should speed up the
> > review process (since the whole coordinator dude position gets eliminated
> > so that any core-dev can review the changes and upload at will) as well
> > as help us do automated QA. Because really, the fact that I spent at
> > least one day for every release on basic regression testing (e.g. file
> > clashes) is simply ridiculous.
>
> How is this automated QA to be completed? There is no AT-SPI support in
> Qt/KDE yet.

QA done on package level. The app can have 0 regressions, but it won't be of 
of much use if the package fails to install ;-) Still, I have been told there 
is some AT-SPI stuff for Qt, I just didn't really get any further information 
;-)
Also, that kind of stuff should probably be done over at KDE, Kubuntu, at 
most, can do a second run every once in a while to ensure that Kubuntu 
specific patches don't cause regressions.

> > So in the future, file clashes should be detected by comparing the
> > packages' file lists. However, I'd like to note that with more resources
> > we could do a lot more (I am thinking real upgrade scenarios in chroots
> > for example ;-)).
>
> Will this be done by the pbuilder hooks I am assuming? Even these don't
> catch them all of the time, because the docs packages did fine with the
> pbuilder hooks, but after uploading, there were issues with the install
> that pbuilder didn't catch. I still prefer manually doing some regression
> testing, and think everyone in the entire community needs to do this as
> well for packages they work on, if they don't already.

Nope, this will be done based on debs built in $PPA (or eventually as provided 
by the developer). In any case the server will also do automatic uploading of 
packages if a new revision was pushed, so it probably makes sense to just 
check for newly built debs and compare it's content to an established database 
of previous versions.

I agree that we need to do manual testing though. I think that everyone is 
just spoiled because I was doing it all the time :P

But really, the least that should happen is that whoever wants to publish the 
packages from the ninjas PPA to any public one should ensure that an upgrade 
from latest stable version works flawless. Without automated testing, there is 
always the possibilty an upgrade path breaks on one or maybe two packages 
(there are just too many upgrade paths, especially when a new Kubuntu release 
is close), but at least the most prominent one should be working as expected.