Lucid Packaging and QA

Richard JOHNSON nixternal at
Sun Jan 10 23:26:39 GMT 2010

Hey everyone!

First off, great job on all of your hard work for what is adding up to be
an amazing release cycle. We have began a little work on the timelord
project and that has started a bit of buzz. It would be nice if we could
find some time in the next week or so to work out the kinks in the project
and get it rolling 110%. I know there has been some buzz from people on the
Internet who would like to get involved with Project Timelord, but they are
saying it is just vaporware at this time. Lets change that!

On to packaging. I was attempting to work on some packages for Lucid and
was going through our exhausting list of branches in ~kubuntu-members.
Maybe something we can think about is trying to figure out how to clean
this up and make it easier to view. It would be great if we had just the
core KDE packages listed somewhere else, possibly ~kubuntu-dev, because
under ~kubuntu-members, there are more than just the core packages, which
helps with the confusion a bit.

With the packaging I was working on, one thing I come across was branches
marked as UNRELEASED. I think this is fine if you just do a few changes or
some minor changes, but if you are doing a large amount of changes, or
changes that are non-trivial, I think you should release it. KOffice is
one. I was looking at the package and the one thing I noticed is the large
difference between the package that is in the repositories and the files in
the bzr branch. There are changes in the repo packages that aren't in the
bzr branch. With the next release of 2.1.1 happening within the next couple
of days by upstream, there are more changes that need to be made as well,
and right now, unless you have a bit of time on your hand and a lot of
patience, it is a fairly large task.

QA. Everyone's favorite topic, but a topic that hasn't been carried through
with in some time. I was going through some bug reports messing around with
a script or 2 from Brian Murray and friends, and something I noticed was
prior uploads/releases should have closed out reports. I would greatly
appreciate it, and I am sure everyone else would as well, if you could go
through the bugs for the package you are uploading, and see if it fixes any
of the open issues. If it does, close the bug via the Debian changelog.
Granted this will take a little more time, but I don't see why we are
constantly rushing to get packages uploaded.

Speaking of bug reports, we have a ton, and then another ton that seem
stale/outdated/no longer an issue. Seeing as we do have a small developer
team, maybe it is time we start doing some Hug Days and trying to get
people involved. It is working quite well with KDE, and typically the group
that shows up isn't always the largest, but they are all working together
and cleaning up the bug lists. We need this badly, and I would be wicked
happy to help out however I can. With that said, I know I need to put up or
shut up, and would be happy helping lead a Hug Day and what not. With out
current development configuration with bzr and all of that, I find it a bit
of a pain to really do work that is as efficient as possible. I am trying
to get a good workflow going, and that will help me with working on bug
reports and fixing stuff at the same time.

Another thing I am finding difficult is trying to work on a bug, checking
out the source, only for it to change while working on fixes. This kind of
goes hand-in-hand with trying to push packages a bit to fast and without
much of any QA going on in that process. I found myself rushing a package
recently and uploaded it without even looking at the copyright file, which
means the copyright file was never touched after doing a dh_make. One thing
I have noticed is it seems we have gotten better of not uploading packages
that are trying to overwrite another one, but on some things I worked on
recently, there was an exhaustive list of list-missing items that should
have either a) been included or b) documented in a not-installed file.

So, with that said, maybe we should schedule a meeting where we can start
hashing out some ideas and plans. Meetings talking about is this going to
be default or is that going to be the wallpaper is great, but we really
need to start concentrating on some QA work, especially since 4.4 is
closing in on its final release.

If you have any more ideas, questions, or whatever you feel like replying
to, go ahead. If you aren't currently contributing to Kubuntu, but thought
about it, now is your chance to follow along and see where you might be
able to fit in. Thanks!

 Name|  Richard JOHNSON
Title|  Developer
Email|  nixternal at
GnuPG|  3578 0981 A21D D662 2A96  7623 F4C1 838C D8C4 4738
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : 

More information about the kubuntu-devel mailing list