problems with upgrade of kde

Harald Sitter apachelogger at ubuntu.com
Wed May 20 17:57:17 BST 2009


On Mittwoch, 20. Mai 2009 05:28:15 Richard JOHNSON wrote:
> On Tue, May 19, 2009 at 11:01:22PM -0400, Clay Weber wrote:
> > On Tuesday 19 May 2009 10:10:00 pm Jonathan Jesse wrote:
> > > Please test the packages further before announcing the changes on the
> > > website.  I wonder how many other people are in the same boat as I am?
> >
> > Yes
> >
> > > i want the newest goodness of KDE and yes I want a working machine.  Is
> > > that too hard to ask for?
> > >
> > > Jonathan
> >
> > I don't mean to sound rude, but the repository is called 'kubuntu
> > experimental' for a reason, and this is a beta of 4.3 as well. I am
> > assuming once we get to 4.3 final, the packages will be in the 'kubuntu
> > updates' ppa repo.
>
> Right, and Jonathan understands this part, and I am sure it is the reason
> why Network Manager is giving him issues, though the part about the
> packages being broken has nothing to do with the PPA being experimental,
> nor KDE 4.3 being a beta. We were just discussing this on IRC this evening.
> We, including me as I have been guilty in the past, need to make sure we
> are doing some regression testing and that the packages work before
> announcing them to the public. There were a lot of people on IRC
> complaining about them today, and to me for some strange reason (30 or more
> people messaged me today alone).
>
> Is everyone using the Pbuilder hooks that tests that once a package is
> completed the build it installs/upgrades cleanly? I think using this and
> doing some minor regression testing, you know making sure the packages
> install cleanly and that the apps at least start, is a good thing to do.
> This also prevents us from having about 5 unnecessary uploads for 4.3 in
> Karmic, I think we are up to 0ubuntu5 now. We need to be a bit more patient
> and not worry about Soyuz karma.

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.

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




More information about the kubuntu-devel mailing list