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. > 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
signature.asc
Description: Digital signature
