Raphael Hertzog wrote: > A VCS surely allows browsing and examining patches. But when I dig in a > VCS history, it's because I have something precise to look up, I will > rarely check it ouf of curiosity. debian/patches/ on the contrary is > something that gets my attention when I unpack a source package. That's just a matter of personal preference; if I'm coming up to speed on a package, the first thing I do is check out its version control and read it. But expecting upstream do do either of these things is not going to result in a lot more upstreams seeing patches and prevent the next openssl disaster. In either case upstream will have to choose to wade through lots of changes that are not interesting to them, instead of looking at the next [PATCH] in their inbox. > Certainly patches.d.o is not meant to replace direct interaction with > upstream developers but it would be a nice service for upstream developers > when the debian maintainer sucks (and it happens...) and also for other > distributions that can benefit from our work. > > But when we give away patches, we also like to get patches from other back > so that's why I believe that if we design any patch sharing > infrastructure, we must open it from the beginning to other distributions > so that we actually benefit from it too. Well, my experience with dealing with sorting through patches from other distributions trying to find useful changes to apply to my packages, either in Debian, or as upstream, is that it's generally a net time loss. And conversely, as upstream I'm git-aming patches emailed to me every day from people from all over, including other distributions, and that works quite well. The quality of the patches is often high since they are worked up to the point to be submitted upstream. And if a patch has problems, or if I don't understand it, I can immediatly talk to the person who developed it. -- see shy jo
Attachment:
signature.asc
Description: Digital signature