Re: numpy 1.2.1, switching to git?
On Wed, Dec 24, 2008 at 00:48, Ondrej Certik <ondrej@certik.cz> wrote:
> thanks for the points, I reacted to some.
so please accept my reply :)
> 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.
have you ever tried git-svn to work over your packages actually in the team?
>> 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.
Really? for a bunch of file under debian/ you need all of this? or are
you talking about upstream code? I think we need to separate the 2
arguments, because the *are* separated: we are packagers, we have to
keep track of our team's things; your involvement in upstream
development is commendable, but this is something "other" that debian
packaging, so it has to be.
>> 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.
the problem is that I don't see what is the "problem of orig.tar.gz":
you have to have one to upload the package, it's compressed (so you
reduce space occupation), if you're good/lucky (no repackage or so)
it's the same "bit-by-bit" the upstream released (And that assure that
nothing weird is happening).
> 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.
well, either you're creating a new revision of an already existing
package (so apt-get source --tar-only would do) or you should stick to
the lastest released tarball, ain't you? There should be strong reason
to not package the latest version but one between the latest and the
one in the archive, that could he handled as expection: they are not
the regular way to do, so we cannot take them as examples.
> 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.
this seems to be a very corner case
>> 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?
Ondrej, you're a science man :) are you just kidding here? :D Of
course it's bigger. A lot bigger. Given you have the whole repository
locally, you have the HEAD + all other modifications done in the past,
for both the upstream code and the debianization. It's like
downloading all the uploaded version of the package in the archive
compared with only the latest one.
Let's take the example of DPMT: the dimension on the svn repo on
alioth is 186M while the full checkout I have here is 47M. And that's
only for debian/ dir (well, almost, but still).
> 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)
But I can only take the latest tarball and debian/ dir not the whole
past: if I want to forge a patch for a package, I don't need and I
don't want to know every single bit that compose the history of it, I
want his source package and work on it, stop :) It's almost the same
for the team: I want to work on the latest version possible.
>> 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.
so you're expecting the same very user to know git so good to clone
the repo, branch it to forge a patch, mail you the diffe between the
current and his branch? I don't think it will ever happen, of if he
can do that, he can managed to do the same as it's now.
Honestly, how many users really do this? or even think about it? They
don't even know that reportbug/BTS exists (sadly) ;) Those users are
"We", the package maintainer
> 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.
sadly, quilt is not so nicely usable with svn, that's why I use dpatch.
> 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.
It's more a dream that a foresee-able situation: users don't know git,
developers do and they can handle anything you propose :)
>> 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.
I think that's what we should care about; upstream work should be done
separately from debian work, that's my point, so it follows directly
from this that I don't feel the need to change, simply :) A already
said, if some packagers of particularly complex packages need
particular solutions, we can find them together, but for the tons of
small modules (mainly) that's a huge overkill.
The same PS as my previous email applies, adding that all I've said
has an "IMHO" applied where you see fit.
Cheers, oh and Merry Xmas (if you believe in it),
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: