On Friday 08 January 2010 18:34:52 Ben Taylor wrote:
> On Fri, Jan 8, 2010 at 4:25 PM, Pavel Heimlich <tropikhajma at gmail.com>
wrote:
> > just to let you know the workspace switched to 4.3.90
> > (announcement http://www.kde.org/announcements/announce-4.4-rc1.php)
> >
> > It'll take some time to prune the old patches.
>
> can we start making use of the new patch infrastructure, so
> patches/kdelibs/4.3.85 and patches/kdelibs/4.3.90 exist,
> just in case we need to go back, without having to wrench
> ourselves with mercurial?
We can just use "hg tag" to mark the position. I'd really prefer not to have
tons of patches for all kinds of versions in the repo, but instead say "this
repo (at revision r) builds exactly *these* versions"; surfing through history
really isn't all that complicated in Mercurial (except I do miss SVN's "svn cp
-r" to copy an old revision into the current tree).
> IE, move current kde patches to %{src_name}/%{src_ver}, then
> replicate with the new src_ver and then symlink the new rev
> up to patches. Once the "can use relative patch directory"
> patch goes into pkgtool, we can get rid of the top level patches
> completely, and keep them with product and revision.
I don't think it makes sense to depend on totally unreleased versions of
pkgtool; if anything I'd take advantage of the 4.4.0 release to drop support
for, say, everything before pkgtool 1.3.98. Moving beyond that into privately-
patched pkgtool land doesn't seem like a good idea unless it brings really
clear advantages (well, I see one clear advantage of "these are the patches
for version V of the software" as opposed to having to hg up, check the spec
file for the version).
[ade]
