Hello, so hereby I propose to switch our KDE packaging from svn to git on git://git.debian.org/git/pkg-kde/kde/$modulename.git. In other words, each official KDE module gets its own $module.git under git://git.debian.org/git/pkg-kde/kde/ with a script to clone/pull/etc. them all. 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream branch. It proved to be fine, didn''t it? Fathi, you worked most with qt4-x11.git, is there anything you would like to be changed? 2) upstream & pristine-tar branches are nice for small packages but from my experience: a) they are additional burden to manage even if `git import-orig` makes it kinda easy to import; but kde is 22 source packages so I don''t think this will scale; b) things get complicated (though manageable with some patience) when there are a few packaging branches based on different upstream versions. It might be tricky to get merging right; c) upstream branches increase repository size considerably; given that kde has 22 source packages, clone of all repos will be huge; d) last but not least, when we decide we want upstream branches, we can always add them later without any cost. 3) Packaging will be imported to git with all history. The main motivation for VCS change is upcoming situation. We will probably have to release with 4.4.5, but we will want to package KDE 4.5 as well. Merging in svn is impossible but we want to properly track changes which apply to both 4.4.5 <=> 4.5 packaging (we have lost changes in the past due to svn deficiencies). Secondary motivation is that centralized svn is ageing while git is distributed, fast, has some nice features and is the most featureful DVCS at the moment. Last but not least, KDE upstream is eventually switching to git. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100711/fde1af55/attachment.pgp>
On Sun, Jul 11, 2010 at 03:53:33PM +0300, Modestas Vainius wrote:> Hello, > > so hereby I propose to switch our KDE packaging from svn to git on > git://git.debian.org/git/pkg-kde/kde/$modulename.git. In other words, each > official KDE module gets its own $module.git under > git://git.debian.org/git/pkg-kde/kde/ with a script to clone/pull/etc. them > all. > > 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream branch. > It proved to be fine, didn''t it? Fathi, you worked most with qt4-x11.git, is > there anything you would like to be changed? > > 2) upstream & pristine-tar branches are nice for small packages but from my > experience: > a) they are additional burden to manage even if `git import-orig` makes it > kinda easy to import; but kde is 22 source packages so I don''t think this will > scale; > b) things get complicated (though manageable with some patience) when there > are a few packaging branches based on different upstream versions. It might be > tricky to get merging right; > c) upstream branches increase repository size considerably; given that kde > has 22 source packages, clone of all repos will be huge; > d) last but not least, when we decide we want upstream branches, we can > always add them later without any cost. > > 3) Packaging will be imported to git with all history. > > The main motivation for VCS change is upcoming situation. We will probably > have to release with 4.4.5, but we will want to package KDE 4.5 as well. > Merging in svn is impossible but we want to properly track changes which apply > to both 4.4.5 <=> 4.5 packaging (we have lost changes in the past due to svn > deficiencies). > > Secondary motivation is that centralized svn is ageing while git is > distributed, fast, has some nice features and is the most featureful DVCS at > the moment. >Sounds good to me. Ana
Hi,> 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream branch. > It proved to be fine, didn''t it? Fathi, you worked most with qt4-x11.git, is > there anything you would like to be changed?nothing to change, I like the workflow we have with Qt.> Secondary motivation is that centralized svn is ageing while git is > distributed, fast, has some nice features and is the most featureful DVCS at > the moment.it will save space on the harddisk ;)> Last but not least, KDE upstream is eventually switching to git.%s/eventually//g git.kde.org is set up. As you can see, I used git on most new Qt related packages. +1 to switch KDE packaging to git. It isn''t clear on your mail but the switch to git is for pkg-kde svn. IMHO, the switch should includes kde-extras and krap. For KDE Extras, it will avoid fragmentation as we have some packages in svn.d.o and some other on git.d.o. Cheers, Fathi
On Sunday 11 July 2010 22:53:33 Modestas Vainius wrote:> 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream branch. > It proved to be fine, didn''t it? Fathi, you worked most with qt4-x11.git, is > there anything you would like to be changed?My only request is that we document the workflow in something like: http://svn.debian.org/wsvn/pkg-kde/kde-extras/README This is so we can get the workflow documented and give those of us git newbies over the line. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100712/3964dcfd/attachment.pgp>
> My only request is that we document the workflow in something like: > http://svn.debian.org/wsvn/pkg-kde/kde-extras/README > > This is so we can get the workflow documented and give those of us git newbies over the line.Qt contains a README.source: http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/README.source It could be used (and improved) for the workflow documentation.
On Monday 12 July 2010 08:06:39 Fathi Boudra wrote:> Qt contains a README.source: > http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/README.sourceThks, That is what I was after.. Just had no idea where to look.. Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100712/46dd3b6a/attachment.pgp>
Hello, On sekmadienis 11 Liepa 2010 20:38:29 Fathi Boudra wrote:> It isn''t clear on your mail but the switch to git is for pkg-kde svn. > IMHO, the switch should includes kde-extras and krap. > For KDE Extras, it will avoid fragmentation as we have some packages > in svn.d.o and some other on git.d.o.Like official KDE modules, those will have to be done one by one when somebody has time. Hopefully migration process won''t have too many caveats and will be polished during migration of official KDE packaging so anybody could do it for krap/extras. qt4-x11.git migration was not very smooth hence I will need to find more reliable ways/scripts. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100712/f1ef5820/attachment.pgp>
> Like official KDE modules, those will have to be done one by one when somebody > has time. Hopefully migration process won''t have too many caveats and will be > polished during migration of official KDE packaging so anybody could do it for > krap/extras. qt4-x11.git migration was not very smooth hence I will need to > find more reliable ways/scripts.I''ll give try with svn2git tool used by KDE: http://gitorious.org/svn2git
Hello, On pirmadienis 12 Liepa 2010 09:33:18 Fathi Boudra wrote:> > Like official KDE modules, those will have to be done one by one when > > somebody has time. Hopefully migration process won''t have too many > > caveats and will be polished during migration of official KDE packaging > > so anybody could do it for krap/extras. qt4-x11.git migration was not > > very smooth hence I will need to find more reliable ways/scripts. > > I''ll give try with svn2git tool used by KDE: > http://gitorious.org/svn2gitYeah, that was my thought as well. It is packaged as svn-all-fast-export. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100712/0d6d5520/attachment.pgp>
On Sun, Jul 11, 2010 at 03:53:33PM +0300, Modestas Vainius wrote:> so hereby I propose to switch our KDE packaging from svn to git on > git://git.debian.org/git/pkg-kde/kde/$modulename.git. In other words, each+1 from me. Do we move all of kde-extras to git too? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes at jabber.org VfL Borussia! For?a Bar?a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
> Do we move all of kde-extras to git too?yes
On Sunday 11 July 2010 19:38:29 Fathi Boudra wrote:> Hi, > > > 1) We would use the same workflow as for qt4-x11.git, i.e. no upstream > > branch. It proved to be fine, didn''t it? Fathi, you worked most with > > qt4-x11.git, is there anything you would like to be changed? > > nothing to change, I like the workflow we have with Qt.I''m not sure I fully like the qt workflow. git clone... tar --magic-option-that-are-hard-to-remember xf foo.tar.gz build... Somehow, I think I woudl prefer if it was just the content of twhe debian dir that was versioned, not the directory. tar xf foo.tar.gz git clone .... debian build /Sune -- How to send to the ISA periferic? You neither should explore the display of a graphic menu on a directory of a FPU over the digital Direct3D e-mail address, nor should ever insert the icon to a 2D icon, so that therefore from Netscape 5.4.9 you should never boot a space bar for doubleclicking with the 68X PCI tool.
On Monday 12 July 2010 10:47:42 Michael Meskes wrote:> Do we move all of kde-extras to git too?I think this is up to kde-extras people. And if KDE extras people want to stay parted in svn and git, I think that should also be allowed. /Sune -- How to boot from the desktop? You must install a display in order to insert in a connector.
Hello, On pirmadienis 12 Liepa 2010 12:09:38 Sune Vuorela wrote:> git clone... > tar --magic-option-that-are-hard-to-remember xf foo.tar.gz > build...it''s --strip=1. shell aliases help.> > Somehow, I think I woudl prefer if it was just the content of twhe debian > dir that was versioned, not the directory. > > tar xf foo.tar.gz > git clone .... debianI don''t think it is a good idea unless you intend to keep `git clone`ing each new upstream release. In your scenario, removing old upstream source tree but keeping "debian" in the persistent cloned packaging directory will need some effort (more than remembering --strip=1 to tar). On the contrary, when debian dir itself is versioned, you can use `git clean -xdff` to clean up old upstream source tree without too much effort because parent packaging directory is under git control. I see where is your idea coming from. However, git is not svn and I don''t think `cp -a debian /path/to/upstream/source` is a particularly good idea mainly because git encourages "commit frequently, push rarely" and subversion gives you no other choice but to push when committing. Desyncing working tree with git state will be confusing in the long term. That''s why git won''t even allow to push to checked out repository by default. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100712/56afa34f/attachment.pgp>
On Monday 12 July 2010 08:06:39 Fathi Boudra wrote:> > My only request is that we document the workflow in something like: > > http://svn.debian.org/wsvn/pkg-kde/kde-extras/README > > > > This is so we can get the workflow documented and give those of us git newbies over the line. > > Qt contains a README.source: > http://git.debian.org/?p=pkg-kde/qt4-x11.git;a=blob;f=debian/README.source > > It could be used (and improved) for the workflow documentation.Seems like a lot of options and moving parts for the maintenance of kde-extras packages. In kde-extras we generally have new upstream releases with sometimes a handful of Debian specific patches, sometimes pulling something early from upstream. svn-buildpackage manages this use case without lots of command line foo, without manual extraction of the upstream tarball or manually extracting the tarball into the repository. Am I missing something, or is git too powerful for the use case we have with kde-extras? Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100713/9d9abc68/attachment.pgp>
Hello, On antradienis 13 Liepa 2010 01:12:03 Mark Purcell wrote:> Seems like a lot of options and moving parts for the maintenance of > kde-extras packages. > > In kde-extras we generally have new upstream releases with sometimes a > handful of Debian specific patches, sometimes pulling something early from > upstream.Well, my original mail has never been about kde-extras. Unlike qt4-x11 or KDE, kde-extras are released individually as separate rather small entities. Compare that to 400+ mb big qt4-x11 or 22 huge source packages of KDE. If I was to start packaging kde-extras app from scratch, I would definitely choose the same workflow I currently use for ktorrent/konversation, i.e. upstream + packaging with patching in quilt + pristine-tar. upstream branches are really useful when they are manageable despite some caveats with quilt patches in this workflow (the next release of dpkg-dev will make it easy to workaround them). However, this ''upstream branch'' workflow does not scale in cases like qt4-x11 (due to its size) or official KDE modules (due to the number of upstream branches to update for each new release and their cumulative size). "upstream + packaging with patching in quilt + pristine-tar" is basically what git buildpackage supports. At least, git import-orig makes it easy to import and manage upstream & pristine-tar branches. However, I do not agree with `git buildpackage` tagging conventions (e.g. that it replaces ''~'', which git does not support in tags, with ''.'', how uninformative tag annotations are etc.) so I tend to avoid it.> svn-buildpackage manages this use case without lots of command line foo, > without manual extraction of the upstream tarball or manually extracting > the tarball into the repository.> Am I missing something, or is git too powerful for the use case we have > with kde-extras?I have never used svn-buildpackage but I believe git-buildpackage is as easy to use as svn-buildpackage if you want to use a wrapper and accept all its conventions (which I don''t). That qt4-x11.git README.source was written with bare git in mind so it might be a bit verbose. -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100713/db9a0e2f/attachment.pgp>
On Tue, Jul 13, 2010 at 1:12 AM, Mark Purcell <msp at debian.org> wrote:> Seems like a lot of options and moving parts for the maintenance of kde-extras packages. > In kde-extras we generally have new upstream releases with sometimes a handful of Debian specific patches, sometimes pulling something early from upstream. > svn-buildpackage manages this use case without lots of command line foo, without manual extraction of the upstream tarball or manually extracting ?the tarball into the repository. > Am I missing something, or is git too powerful for the use case we have with kde-extras?Yes, git is powerful and you can use it using different workflow. You are familiar with svn-buildpackage, fine, use git-buildpackage. That''s the workflow used in current KDE extras package in git. This is documented here: http://wiki.debian.org/PkgKde/GitPackaging Cheers, Fathi
On Mon, Jul 12, 2010 at 12:10 PM, Sune Vuorela <sune at debian.org> wrote:> I think this is up to kde-extras people. And if KDE extras people want to stay > parted in svn and git, I think that should also be allowed.I disagree on this point. I want to reduce the workload, not increasing it. We have already some fragmentation in KDE Extras packages. Some packages are on svn, some other in git. I would like to avoid this and fix the issue once for all. I don''t want to continue to switch between vcs, use different workflow, etc... Moreover, if we have a single vcs, with common practices (KDE Extras could use git-buildpackage), contributors will find their way easily. IMHO, It''s better than saying "this KDE extras package A uses svn, this one uses git, and this package C use this workflow". Cheers, Fathi
On Tue, Jul 13, 2010 at 09:02:29AM +0300, Fathi Boudra wrote:> On Mon, Jul 12, 2010 at 12:10 PM, Sune Vuorela <sune at debian.org> wrote: > > I think this is up to kde-extras people. And if KDE extras people want to stay > > parted in svn and git, I think that should also be allowed. > > I disagree on this point. I want to reduce the workload, not increasing it.+1 again from me. It''s about time to get rid of svn completely. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes at jabber.org VfL Borussia! For?a Bar?a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Hello, so Git migration is moving forward slowly. A few notes: 1) Qt 3 / KDE 3 stuff will remain on subversion. Their subversion history is too messed up (retagging, svn externals) to be worthwhile migrating. 2) Our Git repos will not have a full graded access control like subversion did. Everyone in the alioth pkg-kde project with SCM permissions will have commit access everywhere. 3) I think we will need to add git hooks in order to enforce some rules in the repositories. To be honest, our subversion history is not in the very good shape wrt consistency (which is partly fault of svn itself). As the last step, I propose the following hierarchy of our pkg-kde Git repository tree. I plan to take care of migrating packages in kde-sc, kde-req and kde-std namespaces. Suggestions (on hierarchy, names etc.) welcome. ------------- /git/pkg-kde/ ------------- The root of the repository tree belongs to our native or otherwise distribution specific packages or tools. Maintainer - Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>. Team maintenance is encouraged, new contributors should ask people in Uploaders before committing. Currently: pkg-kde-tools.git pkg-kde-repository.git meta-kde.git kaboom.git kingston.git ---------------- /git/pkg-kde/qt/ ---------------- Packages closely related to Qt Toolkit. Maintainer - Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>. Team maintenance is encouraged, team is not willing to give these packages up under any circumstances, new contributors should ask people in Uploaders before committing. Currently: qt4-x11.git qt-assistant-compat.git qt-messaging-framework.git qtmobility.git qt-sdk.git qt-simulator.git qtwebkit.git -------------------- /git/pkg-kde/kde-sc/ -------------------- Source packages that are/used to be officially released as "KDE Software Compilation" using the same version number. Maintainer - Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>. Team maintenance is encouraged, team is not willing to give these packages up under any circumstances, new contributors should ask people in Uploaders before committing. kdeaccessibility.git kdeadmin.git kdeartwork.git kdebase.git kdebase-runtime.git kdebase-workspace.git kdebindings.git kdeedu.git kdegames.git kdegraphics.git kde-l10n.git kde4libs.git kdemultimedia.git kdenetwork.git kdepim.git kdepimlibs.git kdepim-runtime.git kdeplasma-addons.git kdesdk.git kdetoys.git kdeutils.git kdewebdev.git oxygen-icons.git --------------------- /git/pkg-kde/kde-req/ --------------------- Packages that are required (either as build or runtime dependencies) or highly recommended (for overall user experience) for KDE Software Compilation. Maintainer - Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>. Team maintenance is encouraged, team is not willing to give these packages up under any circumstances, new contributors should ask people in Uploaders before committing. Currently: akonadi.git automoc.git eigen2.git phonon.git polkit-kde-1.git polkit-qt-1.git soprano.git --------------------- /git/pkg-kde/kde-std/ --------------------- Packages that are not part of official KDE Software Compilation but have a very close association with official KDE. Maintainer - Debian Qt/KDE Maintainers <debian-qt-kde at lists.debian.org>. Team maintenance is encouraged, though individual maintenance is likely. Team maintenance is encouraged, team is not willing to give these packages up under any circumstances, new contributors should ask people in Uploaders before committing. kdevelop.git kdevplatform.git kdevelop-pg-qt.git kdevelop-php.git kdevelop-php-docs.git koffice.git koffice-l10n.git wv2.git (-> krap?) phonon-backend-vlc.git ------------------ /git/pkg-kde/krap/ ------------------ Packages of (optional) KDE Platform dependencies or libraries which team as a whole is forced to care about but would rather not to. Maintainer - Debian Krap Maintainers <debian-qt-kde at lists.debian.org>. Individual maintenance under the team umbrella is encouraged. Currently: /svn/pkg-kde/krap/* ------------------------ /git/pkg-kde/kde-extras/ ------------------------ Packages of extra/optional third party KDE (or Qt) applications. Maintainer - Debian KDE Extras Team <pkg-kde-extras at lists.alioth.debian.org>. Maintained either individually under the team umbrella (non-Uploaders should not commit changes without permission from non-MIA Uploaders) or team maintained (team members are free to commit anything). Currently: /svn/pkg-kde/kde-extras/* -- Modestas Vainius <modestas at vainius.eu> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-talk/attachments/20100718/f01037b6/attachment.pgp>
Hello, On sekmadienis 18 Liepa 2010 23:57:19 Modestas Vainius wrote:> so Git migration is moving forward slowly. A few notes: > > 1) Qt 3 / KDE 3 stuff will remain on subversion. Their subversion history > is too messed up (retagging, svn externals) to be worthwhile migrating. > > 2) Our Git repos will not have a full graded access control like subversion > did. Everyone in the alioth pkg-kde project with SCM permissions will have > commit access everywhere.so I plan to be done with Git conversion of kde-{sc,req,std},attic by tomorrow. I''ll do krap a bit later, I won''t do kde-extras. Hierarchy stays the same as described in the previous mail with addition of attic/ where the following will be moved: ''blitz'' => ''attic'', ''decibel'' => ''attic'', ''meta-kde4'' => ''attic'', ''kdelibs-experimental'' => ''attic'', ''cdbs'' => ''attic'', wv2 will be moved to krap/.> 3) I think we will need to add git hooks in order to enforce some > rules in the repositories. To be honest, our subversion history is not in > the very good shape wrt consistency (which is partly fault of svn itself).I also wrote an update hook which will enforce the following rules (as of now): Packaging tags: * tag is under debian/ namespace; * tag is annotated; * format of the tag message first line (<version> <distribution>; urgency=<urgency>); * tag message is in sync with debian/changelog; * distribution is valid and allowed (unstable, experimental); * tag commit has a merge base in the master branch; * tagged tree does not contain anything else but debian/ subdir and optionally .git* (can be disabled by hooks.pkgkdeDontRestrictTree); * a couple of more basic consistency rules; Packaging branches (master, unstable, experimental etc.): * branch update is fast-forward; * branch is not being deleted; * tree does not contain anything else but debian/ subdir and optionally .git* (can be disabled by hooks.pkgkdeDontRestrictTree); * branch is not scoped (doesn''t have /; applies to all branches) Configuration variables: * hooks.pkgkdeDontRestrictTree (bool) - do not restrict tree contents to debian subdirectory and .git*. Useful for native packages. Branches rules won''t apply to non-packaging branches (i.e. not master, unstable or experimental). Proper painless formatting of the tags may be achieved with `pkgkde-vcs tag` tool as of pkg-kde-tools 0.9.3 (just uploaded). The main rationale for rather strict tagging rules is the following: 1) avoid bogus tags in the VCS. This happened quite a number of times with svn so such a automated checking is clearly needed; 2) ensure that the tag message is informative. I do believe that having version, distro and urgency of the upload in the VCS quickly accessible (e.g. over gitweb or `git tag -n1`) is quite useful. I do plan to extend pkgkde-vcs with more functionality like mass changes/committing, (mass) cloning, mass pushing etc. -- Modestas Vainius <modestas at vainius.eu>