On Fri, 16 May 2008, Joey Hess wrote: > Raphael Hertzog wrote: > > 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.
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. The other part of the problem depends on the workflow used within your VCS. As Russ explained, if you use topic branch to keep logical changes, then you have several relevant commits spread in the middle of multiple upstream commits and you don't have a single description of the branch itself. But don't get me wrong, I'm not opposed to using VCS for package maintainance (I do it!), I just think that we haven't found the perfect workflow yet. Ideally, I'd like something where I maintain my upstream changes in topic branches and the Debian branch would be another topic branch that just adds the debian directory (without debian/patches) and debian/patches/ is auto-generated from the set of topic branches. For this, we probably need to give some hints to the tool that will create the source package. Those hints could be in a file debian/source/patch-generation and would contain the (ordered) list of topic branches with its description and any other required meta-information. I know that it will not always work if we have strong dependencies between the topic branches but I'm not sure we have to optimize for that case as it shouldn't happen to often, and I prefer such a tool that work in 80% of the cases than no tool at all and continue with a package that consist of a giant patch mixing multiple stuff. (Or maybe we'll find a way to make it work in all cases, that would be even better... maybe we have to define and respect some relationship betwen the topic branches, have topic branch B be always based on A, and C on B, etc. so that diff between A-B, and B-C always end up being applicable one after the other) > > 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. If that's the case, you can auto-generate that information at the same time when you generate the patches corresponding to your various branches. It's great! > 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? 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. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
