On Fri, May 16, 2008 at 05:13:24PM -0500, Manoj Srivastava wrote: > On Fri, 16 May 2008 23:27:03 +0300, George Danchev <[EMAIL PROTECTED]> said: > > > On Friday 16 May 2008, Joey Hess wrote: > >> Raphael Hertzog wrote: > >> > I totally agree that we need to make our changes more visible. In > >> > the openssl case, the patch in question is inside the .diff.gz and > >> > you don't notice it in the unpacked source package. I tend to give > >> > a look to what's in debian/patches/ when I rebuild a package but > >> > not to what's in .diff.gz only. > >> > > >> > To me this one proof more than even when VCS are used to maintain > >> > packages, our source packages must clearly identify the Debian > >> > patches that are applied. > >> > >> You're insinuatiog that a VCS does not allow easily browsing and > >> examining patches, and I just don't buy it. > > > This is true, but not always handy. What you might buy is that the > > upstream or resp. debian user is not supposed to know for your kind of > > VCS (having it installed, etc) and where to find your VCS repo -- a > > I find this to be true for quilt too. How does one extract what > the 057th patch does, without examining all the leading patches up to > that point? Linearizing features and intermixing integration changes > along with feature-sets is something I have always found confusing. > > > ftp'ing of diff.gz or apt-get source pkg should be enough to get the > > *clearly identified patches* to the upstream source tree. > > I find a quilt series to not fit the bill very well. On the > other hand, creating ./debian/topics/foo/ with a git-format-patch > series for each branch in there might be doable -- but then, these > individual patches might not apply cleanly over each other.
Having to merge 30 topic branches is not a workable solution either. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
