[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian KDE maintenance

On Thu, Dec 18, 2003 at 03:13:57PM +0100, Dominique Devriese wrote:
> Hi,
> I have some questions about how development occurs on the KDE Debian
> packages:
> 1.  Exactly what is the role of the alioth pkg-kde project ?  AFAICT
>     from the website, there is no activity there, even the CVS
>     repository is empty.

The primary role of the alioth pkg-kde project is likely to be for svn
access to the pkg-kde repo. It will be accessible to anyone who wants to
join the group, although it will probably be primarily maintained by the
current maintainers of the respective packages. Using svn or a rcs in
general outside of the KDE repo allows for maintaining debian dirs for
particular KDE releases easier. For example, it makes it easier to fixup
a debian dir for KDE 3.2b2. Also since we are using svn its easier to
move files and dirs around and change permissions if needed. I intend to
keep i18n translations in KDE cvs though, since they seem to be updated by
the KDE i18n team, which is in much better shape than the Debian i18n team.

> 2.  Where does active development occur on the packages ?  KDE CVS or
>     the repository on alioth ?  If on KDE CVS, then in what branch do
>     you work ?  3_1 or HEAD ?  When will you move to the new 3_2
>     branch ?  

So far I am still trying to clean up KDE_3_1_BRANCH for sarge. I think I
will wait to try the pkg-kde svn for KDE 3.2. I will be moving to 3.2
once I have the rest of KDE built with the new patch system.

> 3.  How do you handle the upstream releases ?  Do you take an official
>     tarball as prepared by the KDE release dude, or do you pull your
>     own copy from CVS at a time that suits you ?  What happens if you
>     then need to make some modifications to the debian-specific stuff
>     and release a new package, but still based on the same upstream
>     release ?

I have decided to do the following:

cvs export KDE_3_1_4_RELEASE
cvs export KDE_3_1_BRANCH

run make -f admin/Makefile.common in foo-3.1.4 and then create the tarball.
run diff -Nrua foo-3.1.4 foo-branch > 01_foo_branch.diff
run uuencode 01_foo_branch.diff 01_foo_branch.diff > 01_foo_branch.diff.uu

This lets us not have the CVS related stuff in the tarball. Apparently
upstream keeps the CVS dirs in the tarball due to how fucked up their
source is, if you want details feel free to ask.

Then I put all the debian specific changes into debian/patches along
with the 01_foo_branch.diff.uu. The reason that the branch diff is
uuencoded is to allow easy inclusion of binary updates, which debian
tools do not allow in the packages diff.gz directly. It may be a good
idea in the future to also uuencode Debian specific binary files that
are under the debian dir, so they can be changed in between upstream
releases. Never make any changes outside of the debian dir that aren't
done via patches, that way leads to insanity. If you modify the build
system make sure to run make -f admin/Makefile.common again (and
remember to make sure the patches have been applied before doing this)
since we're using AM_MAINTAINER_MODE this will force update the
autotools file such as Makefile.in and the changes will be in the
packages diff.gz.

The above sounds complicated but once you've done it a few times its
easy to remember.

> 4.  Is there an irc channel where you discuss the debian kde package
>     development ?

There are two channels on freenode #debian-kde and #debian-qt-kde. I
intended #debian-qt-kde to be the developer channel but no one seems to
be in there except for me. Either is fine to discuss issues.

> 5.  Is there some kind of procedure on committing changes to the
>     debian/ stuff ?  I suppose trivial patches can be applied without
>     a problem ?  Where does discussion occur on more intrusive patches
>     ?

If you need to change things and they are minor just commit them or file
a bug with a patch. If something major needs to change then email the
maintainer of the package and/or send an email to this list.

> 6.  What is the status of the group maintainership ?  

Anyone can join, we need people that can triage bugs (forward, close,
etc) like what you currently do, and others that can help with
packaging issues. There is also some new Debian work being done upstream
in kdenonbeta which would be useful to help with. I think they are
working on a debconf frontend and a few other projects. If you are
interested in the upstream debian projects join the kde-debian list that
is on lists.kde.org.


BTW - kdebase 3.1.4-1 is in incoming now.

Attachment: signature.asc
Description: Digital signature

Reply to: