On Mon, Sep 29 2008, Stefano Zacchiroli wrote: > On Mon, Sep 29, 2008 at 12:44:57PM -0500, Manoj Srivastava wrote: >> Arguably, we should all use debhelper and use quilt+subversion, >> to make it easier for more people to follow the package. And, really, >> we should all be using rpm or tar.gz. (More people use subversion than >> do understand git). > > Eh :) > >> At some point we draw a line at popularity, and making things >> easier for everyone else part from the ones currently doing the work). >> I have a line where my productivity and motivation are sufficiently >> negatively impacted that changing to goals to make things easy for >> (potential) contributors at the expense of my workflow results in a >> regression. > > It looks to me you are implicitly assuming that there is an exclusive > choice between patch series and Vcs. If that were true your argument > would stand, but it is not true, and TopGit is there exactly to show > that (if it is up to the task).
*Sigh*. You are missing context. And the point. Let me see if I can recap. a) Topgit can be used to generate quilt series on the fly, but only for the current state of the package. b) For previous releases of the package, just the git branches are not enough, since we can not recreate previous patches. c) Therefore, we need to additionally store the patch series generated from git branches into yet another git branch (presumably not one the patch series are generated from). Me, I hate c, and I think this is not something I am going to be doing, even if that schema is popular. > The fact is that among Debian developers and maintainers not everyone > is familiar with all Vcs we have, but we do want people to be able to > work on whatever package to help out with bug fixing (and possibly > with NMU). The idea of providing *also* a patch series is to diminish > barrier in contributing to a package. I have rarely seen people do ongoing development of my packages (and I have _some_ experience here: I've had some 30+ packages in Debian for nearly 13 years now). Most people look at he unpacked source, and send me a patch via mail, and I figure out where the patch belongs (or whether the patch needs to be split up). That is fine by me; you do not have to understand topgit et al to contribute. > Of course that should not be done augmenting the burden on top of the > usual maintainer and that, again, is something that TopGit should show > to be considered the right™ tool. I'm OK with releasing a patch series; but will not take patches to the patch series as contributions. Patches to patches are just silly, in my opinion. So, either send me a patch to the unpacked Debian package, or pull from my public git repo, if you want to contribute to development. I can provide you with a patch series if that makes it easier for you to understand the patches applied. But that does not mean I'll store the quilt series in git. Since every released version in the archive will have a topgit generated quilt series (once I can get a work-flow going that I think I can live with), I don't see the need to independently regenerate an historical serialization. Of course, it would be great that with some tagging topgit could keep track of the history itself (as VCS' are supposed to be doing), and not make me store the serialization of git branches in yet another git branch, but hey. I did not write topgit, and I am gratefil for what has been given me to complain too loudly. manoj -- That secret you've been guarding, isn't. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C _______________________________________________ vcs-pkg-discuss mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss