Lucid Packaging and QA
 

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
WWW| http://www.ubuntu.com
Email| nixternal@ubuntu.com
GnuPG| 3578 0981 A21D D662 2A96 7623 F4C1 838C D8C4 4738
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Lucid Packaging and QA
 

Am Montag, 11. Januar 2010 00:26:39 schrieb Richard JOHNSON:
> 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.

Most of the time you do not know which bugs might be fixed by just looking at
their subject, so you need to digg in and check (which in case of say kdebase-
workspace will take at least a day).
So I think in order to carry that out first strong bug triage must be
established so that the triagers have time to care about stuff like making the
subject reflect a bug's actual root.

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

We could always start off with triage-only I suppose?

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

If I had server resources and what not I would have dropped a QA suite months
ago, epsecially the list-missing stuff is pretty easy.

--
Harald Sitter
Kubuntu Core Developer
http://www.kubuntu.org
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel