also sprach Stefano Zacchiroli <[EMAIL PROTECTED]> [2008.11.30.1832 +0000]: > Now, assuming there is a sane way of storing the information > needed to address both targets, what about providing patches for > both targets?
The only sane way I see is by dumping the DAG itself in a way that would allow it to be imported into a DVCS and processed from there. I have not found a viable way to actually do this. > However, this can open a can of worms, because it implicitly > assumes that single patches are picked from the patch set. If more > than one patches are desired, conflicts between them will be need > to be solved by the picker. One way would be to store topic patches and recorded conflict resolution, but I know of no way to do that, especially no portable way. Also, conflict resolution would have to be created and stored for each permutation of topic branches, which is surely asking a bit too much, given that this cannot be automated. I like the thought of providing debian/patches as a series of changes, primarily useful for people to research differences between upstream and my package, and as useful references in discussions with upstream. For instance, when I raised a bug with Postfix and IPv6 on the postfix-users mailing list, I was able to point out that Debian does not modify the IPv6 code at all by pointing at http://patches.debian.net, knowing that those patches are actually applied during the Debian build. 0. Title "permit_mx_backup_networks does not accept IPv6 addresses" against postfix, I am offline, so I cannot provide a number. Submitted with <[EMAIL PROTECTED]>. 1. <[EMAIL PROTECTED]> In the postfix case, it didn't really matter that a given patch D only applies to postfix in the context of patches A,B,C because the consumer (a human, or group of humans) are more intelligent than /usr/bin/patch and could extract the necessary information without troubles. On the other hand, if you combine features on the integration branch and export them to debian/topics as well, there is no guarantee that the sets of branches integrated is equivalent to the set of branches exported. In addition, the patch series allows me to distribute upstream and Debian's modifications separately from each other, without mashing them together into a monolithic diff. I think this is the use-case I want to support, and that anyone who is actually interested in one of my features independently of the others should use the VCS directly. There is of course the argument of the person working wanting to work with my code without connectivity, and I don't want to discard that. However, this person *can* get the feature branch from the series. In the rare (?) case that the feature overlaps with another, then s/he will have to work a bit more, e.g. applying A..D and then reverse-applying C..A, while resolving conflicts in favour of D. I don't think that's too much to ask. In the end, I am primarily packaging, not primarily distributing source code. Thus I want my tools and workflows geared at that, not to try to jump through hoops to build a package from a bundle that's more optimised for distribution of the source and modifications. -- .''`. martin f. krafft <[EMAIL PROTECTED]> Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "arrogance on the part of the meritorious is even more offensive to us than the arrogance of those without merit: for merit itself is offensive." -- friedrich nietzsche
Description: Digital signature (see http://martin-krafft.net/gpg/)
_______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss