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. Chris BTW - kdebase 3.1.4-1 is in incoming now.
Attachment:
signature.asc
Description: Digital signature