On Fri, May 16, 2008 at 04:04:20PM -0400, 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.
The current git version of git-dch allows to automatically prefix the debian/changelog entries with git commit id's like: * [958c4b1] attach multipath.conf to bugreports * [2ac083e] make multipath-tools-boot arch all This, together with the VCS-Browser/Git fields in debian/control makes mapping the modifications to an easily reviewable patch quiet comfortable. This is only a very special case, but could certainly be done for other VCS too. -- Guido > > > stating: > > - a description of the patch and its purpose > > - the associated bug number > > - who wrote the patch > > - where it has been forwarded upstream > > - sign-off by reviewers maybe > > All stuff that you get essentially for free by committing to a VCS. > > > [2] And IMO we should go further than patches.d.o, we need to create a > > cross-distro infrastructure where we can share patches. We really have to > > show the way here... (we complained enough that ubuntu patches were > > unusable, surely we can show how to do it right when it comes to sharing > > patches with others and upstream) > > We didn't just complain that Ubuntu's patches were unusable, but that > their whole means of communication of them back to upstream, ie Debian, > was/is flawed. We [1] complained that automatically publishing patches was > not sufficient to get those patches integrated back into Debian because -- > > a) People cannot be expected to poll a directory somewhere for new > patches. > (Which Ubuntu has partially addressed, if your proposal does, it's > not clear to me specifically how.) > b) Monolithic patches that make multiple changes are near-useless. > (Which Ubuntu has not satisfactorally addressed, IMHO; I still get > automated patch mails with multiple changes in them. Your propsal > tries to address this.) > c) Patches lacked explanations of why changes were made, beyond the > changelog, and it was difficult to figure out more. > (Which Ubuntu has not particularly addressed, and I'm not sure your > proposal addresses entirely..) > d) The best way to get good code is to go out and get in communication > with upstream about it, explain the rationalle so that they can fully > understand it, and take their advice into account. > (Which Ubuntu maintainers generally still fail to do with Debian, and > which your proposal doesn't really facilitate Debian doing more than > we do now.) > > I can certianly see some good benefits to the lines that you're > thinking, but if this turns into a pile of patches on a website that > upstream has to manually go find, and rarely does, and a lot of busywork > keeping the patches up-to-date, and maintaining redundant metadata ... then > why would I want to use that when I can shoot a mail off to upstream > with a git-format-patch in it? > > -- > see shy jo > > [1] specifically, me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] _______________________________________________ vcs-pkg-discuss mailing list vcs-pkg-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
