Re: numpy 1.2.1, switching to git?
Hi Sandro,
thanks for the points, I reacted to some.
On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi <morph@debian.org> wrote:
>> P.S. bzed, POX, isn't it time to move our packaging to git?
>
> I'm none of them, but I'll speak anyway :) Buxy almost did my point,
> I'd like to express me a bit.
>
> To do a change into something different we need a reason: what's the
> reason for moving from svn to git? is it because it's cool? (I hope
> not ;) ) is it because it has some features missing in svn? maybe, but
> which ones? something else?
Yes, distributed version control system has many features that are
missing in svn (=that I am missing in svn), mainly that I can easily
fiddle with different approaches and branches locally, that I can
easily upload my own branch somewhere for someone else to try. With
svn, I need to append a patch to our BTS/mailinglist.
>
> It's DVCS, ok, but how many time did you have to diff or log a package
> offline? How many time did you have to leave uncommitted changes
Actually, all the time. Maybe it's only how I work, but I often look
at the history to learn what are the latest changes to see where the
package is heading to, what is the style of maintaining, etc. Or
simply to remind myself what I did on this package in the past.
> locally while waiting to connect to network for "svn up && svn co"? it
Also all the time, the latest example being my very first email in this thread.
> would be the same for git or svn: you need network to upload a
> package, and you need network to update/commit/whatever action on the
> repo.
>
> Having a centralized place, to concentrate our work it's a plus, not a
> minus for us (IMO): why would you distribute it?
That's a good point and an argument why we should use one VCS as a team.
>
> Moreover, I do not want upstream code in the VCS we use for
> debianization (I did this error for personal managed pacakges and I do
> not want to do it again). Let upsteam tracks his own source code like
> he prefers, we do not need re-tracking it in git/svn/XXX, what we want
> to do is to keep track of our work, what's in debian/ dir *only*.
As I understand, the upstream code in the repo is useful only so that
one doesn't have to fiddle with orig.tar.gz.
>
> If, for packaging reason, you need to "touch" the upstream code, then
> checkout the upstream code in whatever place you prefer, using the
> same VCS upstream uses, and submit them patches, check differences or
> what-so-ever, but that has nothing to do with packaging that tool.
I agree with this.
>
>> So that I
>> can just commit such patches in a branch and also so that we don't
>> have to mess with the orig.tar.gz, svn-uscan and other things
>
> apt-get source --tar-only <src_pkg>
Ah thanks, I forgot about this.
> uscan --verbose --repack --rename --destdir=/where/you/keep/tarballs
Right, that's almost what my svn-uscan alias does:
$ alias svn-uscan
alias svn-uscan='uscan --verbose --force-download --rename
--destdir=../tarballs'
However, sometimes the orig.tar.gz cannot be obtained with svn-uscan
--- let's say if you are repackaging upstream, or simply if you are
packaging a different version than svn-uscan downloads. One example
being the abinit package, where svn-uscan is offering me the highest
released version number, however the production version (that should
be packaged) is not the highest version available.
>
> I don't see too difficult: 1 command (whatever you prefer) comparing
> with the many of "vi <file> + dch + build + lintian" loops you do to
> prepare a package.
>
>> everything will be in one git repo,
>
> Given my slooooow line, I cannot afford the pain to download every
> packages source code + debianization; now, to have a full checkout of
> dpmt/papt repositories, I need to launch the commands during the
> night. Additionally, doing repositories wide updates will become more
> painful, so I have to refrain from "work on every package" but just on
> mine.
That's a good argument and I don't know the answer to it. But are you
sure it would be that much bigger? If you want to test a package, you
still need to download the orig.tar.gz plus the debian dir (in svn).
(the best thing is to just try this and see)
> What users are you talking about? those that wants to rebuild a
> package are experienced used, so they can apt-get source <pkg> and
> then debcheckout it or whatever order/way they prefer. A normal used
> is "client" of the .deb package installed via
> apt-get/aptitude/synaptic/dpkg/
I am talking about the user (client in your terminology:), who reports
a bug and even suggests a fix, but he doesn't have time to learn how
to fiddle with svn-buildpackage+orig.tar.gz. Especially if the fix
needs to change some patches in debian/patches. See the howto in the
Holger's wiki:
http://wiki.debian.org/HolgerLevsen#head-a629792087aba6594e680a74e93b55a9318ba995
it's too dificult I myself don't remember it and I still need to copy
the commands from the wiki each time I am fixing some patch in
debian/patches. Actually --- when looking at it now, it seems Holger
has found an easy way out ---
/usr/share/svn-buildpackage/contrib/svn-do. But still you need to
setup quilt, apart form that working with quilt is very nice, I like
that.
If things were as easy as "debcheckout", fix anything with "vim" (no
matter if in the debian dir, or upstream sources), test with "git
buildpackage" then commit your changes and send us your commits, or
just publish your branch somewhere, I think that will hugely increase
the number of people actually sending patches. Well, I am sure about
that.
> I recognize that some particularly complex packages may need an ad-hoc
> management, but the vast majority of the packages in the team do not
> need it; so let's "split" those packages in a separate DVCS repository
> (maybe still called papt/dpmt) and keep the other where they are.
>
> Concluding, if you ever switch to a DVCS, I'd vote for git, but given
> the situation, I don't see a strong need to move away from svn.
Imho if we are going to only version the debian dir, then I also don't
see such a strong argument for git (or other distributed vcs). Since
it will still need to fiddle with upstream tarball and also with
debian/patches + quilt.
The biggest argument for git is that everything is at one place, it's
easy to hack on it and to build it. The price for it is that it's
bigger.
Anyway, I think I said everything I wanted to say already in this
thread. Thanks everyone who participated in the discussion so far.
I'll think about all the points all of you raised over the Christmas.
As usual in Debian, the problem was analyzed from all sides and I like
that. :)
Ondrej
Reply to: