problems with upgrade of kde

[Richard JOHNSON]

On Thu, May 21, 2009 at 01:20:29AM +0200, Harald Sitter wrote:
> 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 
> ;-)

Well obviously because you shouldn't even be regression testing if you
can't install it right? I have been through the Qt labs and we recently
discussed this in KDE, it is not only unavailable in Qt at this time but
the documentation for it hasn't been updated in quite some time. Look at
the work the Canonical QA team is doing, I only wished we could do 1/100th
of it automated right now, but we can't. AT-SPI needs to badly be in both
Qt first, and then in KDE. Then at that time KDE will run there tests and
then the distros would run there tests. There is something odd right now,
because this same system I run Kubuntu 9.04 on with is much slower than me
building trunk on this same machine. The trunk build runs circles around
Kubuntu 9.04, when it isn't broken of course ;)

> 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.

I think that once we get settled into a release we would go for the
automated testing and really get into the regression testing. We should at
least make sure right now that packages build and install correctly,
because we don't need more grumpy developers, I think I am all you can
handle :p

> 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.

So we will in essence have 2 buildd's? We will push to this server which
will do some testing, and then if all goes well it will go to the PPA?

> 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

OK, so I will start blaming it all on you then :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.

If someone builds a package, even if they upload or not, they should test
it. I agree that the person uploading should test as well, but I was hoping
that at this point in the game I could ask you if all went well, and if it
did upload, especially since we aren't in a mission critical period of the
current cycle. I agree that you can't test everything, but at least a
simple test this time around would have caught all of the issues people
have been experiencing.

-- 
 Name|  Richard JOHNSON
Title|  Developer
  WWW|  http://www.ubuntu.com
Email|  nixternal at ubuntu.com
GnuPG|  9554 2BCC 3AA2 3898 0939  56E7 3EC9 A39D 2E2C 0124
 Home|  http://www.nixternal.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20090520/0b2cb23e/attachment.pgp