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
> 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
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.
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