numpy 1.2.1, switching to git?
Ondrej Certik
I just uploaded some fixes to numpy 1.1.1, currently in incoming. The
attached patch fixes the packaging so that it compiles with the new
numpy 1.2.1. However, I had to comment out all the documentation
building, as it has changed upstream (and the current Debian packaging
breaks the build).
So if anyone (Kumar?) have time to work on this, it'd be awesome. For
others, if you just need the package, apply the patch and it will
build.
Ondrej
P.S. bzed, POX, isn't it time to move our packaging to git? 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 -- i.e.
everything will be in one git repo, so users can just download, hit
one command and they have a working package (as opposed to the current
scheme, were they need to download svn, then setup some tarball
directories, then setup svn-uscan, then execute it and only then they
can actually build the package, so it's very annoying for casual users
to setup the environment to contribute to the packaging)
Kumar Appaiah
> So if anyone (Kumar?) have time to work on this, it'd be awesome. For
> others, if you just need the package, apply the patch and it will
> build.
Since you pulled me in, I'll have a look some time next week, unless
someone else does it earlier.
Kumar
--
Kumar Appaiah
--
To UNSUBSCRIBE, email to debian-pyt...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Piotr Ożarowski
> P.S. bzed, POX, isn't it time to move our packaging to git?
I was planing it for a long time, but never found time to actually do it.
If you volunteer to do this, please send a message to PAPT mailing list,
wait a week and if no one will complain, go ahead and convert the
repository. Then we'll test it for a bit and if it will work fine, we'll
do the same with DPMT repo (which has more developers so we'll use
"hey, it's working perfectly fine in PAPT" argument ;).
BTW, I'm Piotr or Piotrek outside IRC ;-P
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
Monty Taylor
much nicer thing overall, since then ubuntu downstream is pretty well
bzr...
(note: I use bzr for all of my other projects, so I have a vested interest)
However... _anything_ is an improvement over svn.
Monty
--
Ondrej Certik
On Thu, Dec 18, 2008 at 8:41 PM, Piotr Ożarowski <pi...@debian.org> wrote:
> [Ondrej Certik, 2008-12-08]
>> P.S. bzed, POX, isn't it time to move our packaging to git?
>
> I was planing it for a long time, but never found time to actually do it.
>
> If you volunteer to do this, please send a message to PAPT mailing list,
> wait a week and if no one will complain, go ahead and convert the
> repository. Then we'll test it for a bit and if it will work fine, we'll
> do the same with DPMT repo (which has more developers so we'll use
> "hey, it's working perfectly fine in PAPT" argument ;).
Great to hear that. If I find time, I'll do that.
>
>
> BTW, I'm Piotr or Piotrek outside IRC ;-P
Cool. I am Ondrej everywhere. :)
On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor <mo...@inaugust.com> wrote:
> /me whinges that switching to bzr for packaging in general would be a
> much nicer thing overall, since then ubuntu downstream is pretty well
> bzr...
>
> (note: I use bzr for all of my other projects, so I have a vested interest)
>
> However... _anything_ is an improvement over svn.
Matthias also wrote me offlist, that he either prefers to stay in svn,
or use bzr, but not git (if I understood well).
The problem with bzr is that it seems to me it is mainly used in
Ubuntu, but that's about it. Also compare for example the number of
packages in the respective vcs:
http://bzr.debian.org/
http://git.debian.org/
http://hg.debian.org/
(git seems to me like a clear winner)
Well, I don't mind either, I know both hg and git quite well and bzr a
little. But I prefer to just use just one vcs for everything, and that
is git in my case, as I think it has the biggest momentum now.
Ondrej
Monty Taylor
> On Thu, Dec 18, 2008 at 9:07 PM, Monty Taylor <mo...@inaugust.com> wrote:
>> /me whinges that switching to bzr for packaging in general would be a
>> much nicer thing overall, since then ubuntu downstream is pretty well
>> bzr...
>>
>> (note: I use bzr for all of my other projects, so I have a vested interest)
>>
>> However... _anything_ is an improvement over svn.
>
> Matthias also wrote me offlist, that he either prefers to stay in svn,
> or use bzr, but not git (if I understood well).
git seems to be fairly polarizing - I'm not sure why. :)
> The problem with bzr is that it seems to me it is mainly used in
> Ubuntu, but that's about it. Also compare for example the number of
> packages in the respective vcs:
>
> http://bzr.debian.org/
> http://git.debian.org/
> http://hg.debian.org/
>
> (git seems to me like a clear winner)
>
> Well, I don't mind either, I know both hg and git quite well and bzr a
> little. But I prefer to just use just one vcs for everything, and that
> is git in my case, as I think it has the biggest momentum now.
Seems like a decent enough rationale... I'm pretty-much fine with any of
them. This will give me a chance to learn a bit about git.
Monty
Tristan Seligmann
> > /me whinges that switching to bzr for packaging in general would be a
> > much nicer thing overall, since then ubuntu downstream is pretty well
> > bzr...
> >
> > (note: I use bzr for all of my other projects, so I have a vested interest)
> >
> > However... _anything_ is an improvement over svn.
>
> Matthias also wrote me offlist, that he either prefers to stay in svn,
> or use bzr, but not git (if I understood well).
>
> The problem with bzr is that it seems to me it is mainly used in
> Ubuntu, but that's about it. Also compare for example the number of
> packages in the respective vcs:
My personal preference ordering would probably be:
hg, bzr, svn, git
--
mithrandi, i Ainil en-Balandor, a faer Ambar
Bernd Zeimetz
> /me whinges that switching to bzr for packaging in general would be a
> much nicer thing overall, since then ubuntu downstream is pretty well
> bzr...
unfortunatelt I don't know why they use bzr as it is really ugly to use
(that's just my subjective opinion, please don't start a flame war now....)
Switching to git would be a good thing, but only if most people of the team
are ok with the switch.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
Steve Langasek
> Monty Taylor wrote:
> > /me whinges that switching to bzr for packaging in general would be a
> > much nicer thing overall, since then ubuntu downstream is pretty well
> > bzr...
> unfortunatelt I don't know why they use bzr
Because bzr was developed in conjunction with Ubuntu? :) (This might mean
Ubuntu is somewhat biased in favor of bzr; OTOH, it also means that bzr
developers are responsive to the needs of Ubuntu developers.)
> as it is really ugly to use
Ugly how?
> (that's just my subjective opinion, please don't start a flame war now....)
It's a rather strongly worded opinion; if you want to avoid flame wars, you
might find it helpful to bring specific criticisms to the table instead of
just declaring a solution "ugly". :)
Slinking back into the shadows of debian-python,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Monty Taylor
>
>> (that's just my subjective opinion, please don't start a flame war now....)
>
> It's a rather strongly worded opinion; if you want to avoid flame wars, you
> might find it helpful to bring specific criticisms to the table instead of
> just declaring a solution "ugly". :)
++
> Slinking back into the shadows of debian-python,
--
Ondrej Certik
> On Sat, Dec 20, 2008 at 06:43:19PM +0100, Bernd Zeimetz wrote:
>> Monty Taylor wrote:
>> > /me whinges that switching to bzr for packaging in general would be a
>> > much nicer thing overall, since then ubuntu downstream is pretty well
>> > bzr...
>
>> unfortunatelt I don't know why they use bzr
>
> Because bzr was developed in conjunction with Ubuntu? :) (This might mean
> Ubuntu is somewhat biased in favor of bzr; OTOH, it also means that bzr
> developers are responsive to the needs of Ubuntu developers.)
>
>> as it is really ugly to use
>
> Ugly how?
>
>> (that's just my subjective opinion, please don't start a flame war now....)
>
> It's a rather strongly worded opinion; if you want to avoid flame wars, you
> might find it helpful to bring specific criticisms to the table instead of
> just declaring a solution "ugly". :)
Well, it's just slow ---- once you get used to git and how fast it is,
it really sucks to wait for basic operations like "bzr di". See e.g.
my comparison here:
http://www.selenic.com/pipermail/mercurial/2008-August/021009.html
But as Bernd said, let's not start a flamewar about this. But I think
it's useful to see what all the debian-python developers think. As I
told Matthias offlist, we should only switch to git if most of
developers are fine with that. Yeah, but since we are talking about
that --- Steve, do you really think that bzr has any future? I know
that Ubuntu is using it a lot, and couple other projects (mostly
hosted on Launchpad), but that's about it. Git, on the other hand, is
used a lot in Debian, and in a lot of other projects. Also you have
many places on the internet to store your repository (github,
gitorious, git.debian.org, ...).
As to mercurial ---- Tristan, I don't know if you actually ever used
hg-buildpackage, but it is written in Haskell (!) and see my blog post
here:
http://ondrejcertik.blogspot.com/2007/10/mercurial-vs-git-for-managing-debian.html
it's not really well polished (well, of course, because not a lot of
people are using it, compared to git-buildpackage).
Anyway, besides stating which vcs one likes, this is mostly a debate
over a beer in Prague, but well, why not, I just had several of them.
Ondrej
Bernd Zeimetz
> On Sat, Dec 20, 2008 at 06:43:19PM +0100, Bernd Zeimetz wrote:
>> Monty Taylor wrote:
>>> /me whinges that switching to bzr for packaging in general would be a
>>> much nicer thing overall, since then ubuntu downstream is pretty well
>>> bzr...
>
>> unfortunatelt I don't know why they use bzr
>
> Because bzr was developed in conjunction with Ubuntu? :) (This might mean
> Ubuntu is somewhat biased in favor of bzr; OTOH, it also means that bzr
> developers are responsive to the needs of Ubuntu developers.)
Actually I didn't know that it was developed by Ubuntu people, all I know is
that Ubuntu uses bzr everywhere. After using cvs, svn, arch, bzr, darcs, git
and other weird things I prefer git - although it has a steep learning curve,
it is much more intuitive to use at the end, comes with a *lot* more features
and is much faster than all other tools. From the idea how a distributed
revision control system should work darcs is still my favourite -
unfortunately I had way too much trouble with bugs when using it and it is
missing a lot of features compared with git, so I don't use it anymore.
My opinion based on the daily use von the tools is really subjective as all
tools do the job they should do most of the time, but using git is just less
pain at the end - although I have to admit that it scared me a bit at the
beginning.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
Cyril Brulebois
> My personal preference ordering would probably be:
>
> hg, bzr, svn, git
git, FD, *
devotee to the rescue.
Mraw,
KiBi.
Ben Finney
> Tristan Seligmann <mith...@mithrandi.net> (20/12/2008):
> > My personal preference ordering would probably be:
> >
> > hg, bzr, svn, git
>
> git, FD, *
bzr, git, hg, FD, svn
--
\ “It is difficult to get a man to understand something when his |
`\ salary depends upon his not understanding it.” —Upton Sinclair, |
_o__) 1935 |
Ben Finney
Jan Dittberner
> Cyril Brulebois <ki...@debian.org> writes:
>
> > Tristan Seligmann <mith...@mithrandi.net> (20/12/2008):
> > > My personal preference ordering would probably be:
> > >
> > > hg, bzr, svn, git
git, bzr, svn
I read some git stuff today and think it's superior to the other VCSs I know.
Jan
Steve Langasek
> On Sat, Dec 20, 2008 at 7:49 PM, Steve Langasek <vor...@debian.org> wrote:
> >> as it is really ugly to use
> > Ugly how?
> Well, it's just slow ---- once you get used to git and how fast it is,
> it really sucks to wait for basic operations like "bzr di". See e.g.
> my comparison here:
> http://www.selenic.com/pipermail/mercurial/2008-August/021009.html
Well, there are a few things I would point out about this:
- This compares a single operation. Broader comparisons of the tools have
shown that bzr is faster at some operations, git is faster at others.
- The performance profiles of the tools have changed over time; indeed, the
"diff" operation in particular is one where git is not an absolute winner.
<http://laserjock.wordpress.com/2008/05/08/git-and-bzr-historical-performance-comparison/>
shows that git used to be slower than bzr at a diff of a tree with
changes, now it's faster; git has always been faster than bzr at diffing a
tree with no changes, but bzr has been closing the gap.
- The bzr team continues to work on the performance of the tool, so <ahem>
"past performance is not a guarantee of future returns".
It may be true that users find bzr slower than git overall for their work;
the above comparison doesn't prove this, though, and I worry that this may
mostly be a self-perpetuating meme: if your expectation is that a tool is
slow, it's going to *feel* slower even if it's not slower overall.
I think there are other important metrics besides raw speed, such as whether
the learning curve is approachable by the community you're trying to reach,
and whether the tool's basic operations have a granularity that's optimized
for the common case; I think these are two areas where bzr wins over git,
but YMMV.
> But as Bernd said, let's not start a flamewar about this. But I think
> it's useful to see what all the debian-python developers think. As I
> told Matthias offlist, we should only switch to git if most of
> developers are fine with that.
I think we're managing to steer clear of flamewar territory so far; but
since I'm not a part of the DPMT and am only tangentially affected by the
team's decision, I shouldn't get a vote and you should feel free to tell me
to shut up about bzr at any time. :) I'm commenting because I'm genuinely
curious about the reasons people would consider bzr ugly, and because you
asked me a question in response to my post, not because I think there's any
reason you guys should listen to me when deciding what tools to use: the
point about Ubuntu being a downstream that makes heavy use of bzr has
already been made, and I don't really have anything to add to that.
> Yeah, but since we are talking about that --- Steve, do you really think
> that bzr has any future? I know that Ubuntu is using it a lot, and couple
> other projects (mostly hosted on Launchpad), but that's about it. Git, on
> the other hand, is used a lot in Debian, and in a lot of other projects.
> Also you have many places on the internet to store your repository
> (github, gitorious, git.debian.org, ...).
Well, the "couple other projects" include things like MySQL, which isn't
small potatoes.
http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
There is also a bzr.debian.org in addition to the git.debian.org, so it's
not that Launchpad is the only place to host bzr branches, and of course you
can generally host a bzr branch anywhere via http, so we're not
single-vendor in terms of hosting. (I use bzr.debian.org myself for a
couple of packages that I maintain, because there are substantial benefits
to me to being able to use the same VCS for Debian and Ubuntu branches.)
So overall, yes, I think bzr does have a future. Even if we only consider
Ubuntu, that's a large project with a lot of momentum related to its use of
bzr (c.f.: Linux/X and git, or Mozilla and hg), which will cause it to be
relevant for some time regardless - and I think it will certainly be
relevant long enough for us to see a bzr-git bidirectional implementation,
at which point users will have the option of choosing the tools they like
anyway, instead of having to choose the tools that work with the repo they
need to contribute to.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
33
Bernd Zeimetz
> Tristan Seligmann <mith...@mithrandi.net> (20/12/2008):
>> My personal preference ordering would probably be:
>>
>> hg, bzr, svn, git
>
> git, FD, *
+1 :)
http://whygitisbetterthanx.com
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
Ondrej Certik
> people like pox and piotr are actually the same.
And the same list for PAPT:
emilio@saturno:~/deb/python-apps$ svn log | egrep "^r[0-9]+ " | cut
-f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Ondrej Certik
> Cyril Brulebois wrote:
>> Tristan Seligmann <mith...@mithrandi.net> (20/12/2008):
>>> My personal preference ordering would probably be:
>>>
>>> hg, bzr, svn, git
>>
>> git, FD, *
>
> +1 :)
+1 too.
Btw, Emilio did a list of the most active DPMT users, here it is. Some
people like pox and piotr are actually the same.
I am surprised I am actually the 6th most active. Pretty cool. :)
Anyway --- when I get some free time, I'll try to assign the VCS
preference to the svn names below. I think it is important that the
people who are the most active use the vcs that they want. People with
no so many commits imho can learn how to use a vcs that is not so much
their favourite. I'll write a howto to our DPMT pages how to generate
couple commits with let's say git (if we switch to it), so that one
doesn't have to learn it --- I am 100% sure that with such a howto, it
will take only 5 minutes to submit a fix to a BTS using let's say git.
Ondrej
emilio@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut
-f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
Piotr Ożarowski
> emilio@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut
> -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r
> 865 piotr
> 609 morph
> 598 kov
> 532 bzed
> 388 pox
865+388=1253
looks like my vote is most meaningful ;-)
unfortunately I use Git only outside Debian, so I don't know about
issues git-buildpackage might have. I know it doesn't have
mergeWithUpstream but it's written in Python, so we can implement this.
The problem is (FWIK) that it's better to use Git with upstream sources
(with tools like pristine-tar)... anyway, I vote for Git, but I'm open
to alternative suggestions.
Ondrej Certik
> [Ondrej Certik, 2008-12-23 11:19]
>> emilio@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut
>> -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r
>> 865 piotr
>> 609 morph
>> 598 kov
>> 532 bzed
>> 388 pox
>
> 865+388=1253
>
> looks like my vote is most meaningful ;-)
>
> unfortunately I use Git only outside Debian, so I don't know about
> issues git-buildpackage might have. I know it doesn't have
> mergeWithUpstream but it's written in Python, so we can implement this.
> The problem is (FWIK) that it's better to use Git with upstream sources
> (with tools like pristine-tar)... anyway, I vote for Git, but I'm open
> to alternative suggestions.
Well, we'll have to divide our svn repo into many small git
repositories anyways. And if there is enough space on git.debian.org,
I suggest we also include upstream sources and use pristine-tar, as
then one will just have to "git clone" and no other messing with the
origtarball (this is really a pain with svn). Take the "mutt" package
as an example:
$ debcheckout mutt
$ cd mutt
$ bzr builddeb
[...]
bzr: ERROR: The build failed.
Because the orig.tar.gz is missing. What is the easiest to obtain the
right orig.tar.gz? (I can go to packages.debian.org and download it by
hand, but preferably there is just one command for that) If we include
upstream sources, it would be just:
$ debcheckout mutt
$ cd mutt
$ git buildpackage
[...]
Finished running lintian.
And that's it. It will be a lot easier for onetime for new people to
start contributing, because they won't have to setup their
environment. But maybe there is some other way to handle upstream
source than just including them in the git repository.
Ondrej
Matthias Klose
> Cyril Brulebois wrote:
> > Tristan Seligmann <mith...@mithrandi.net> (20/12/2008):
> >> My personal preference ordering would probably be:
> >>
> >> hg, bzr, svn, git
> >
> > git, FD, *
>
> +1 :)
>
>
> http://whygitisbetterthanx.com
I only trust my own comparsion without any date and version numbers.
And honestly I don't care about a checkin of the usual 2-5 files
taking half a second longer. What annoys me most with git is the
steep learning curve and the non-intuitive UI, therefore I do prefer
bzr over hg over svn over others.
Matthias
Not a member of the modules team, just listed as uploader of some of
the packages.
Bernd Zeimetz
> I only trust my own comparsion without any date and version numbers.
> And honestly I don't care about a checkin of the usual 2-5 files
> taking half a second longer. What annoys me most with git is the
> steep learning curve and the non-intuitive UI, therefore I do prefer
> bzr over hg over svn over others.
In my opinion git is much more intuitive than any other tool - but you have to
climb a bit on the learning curve before you realize it.
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
Ondrej Certik
> Matthias Klose wrote:
>> I only trust my own comparsion without any date and version numbers.
>> And honestly I don't care about a checkin of the usual 2-5 files
>> taking half a second longer. What annoys me most with git is the
>> steep learning curve and the non-intuitive UI, therefore I do prefer
>> bzr over hg over svn over others.
>
> In my opinion git is much more intuitive than any other tool - but you have to
> climb a bit on the learning curve before you realize it.
If you already know hg, the curve is not steep at all (as I said, it
took me a day or two to feel like at home).
I suspect if you already know bzr well, the curve will not be steep as well.
Ondrej
Loïc Minier
> P.S. bzed, POX, isn't it time to move our packaging to git? 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 -- i.e.
> everything will be in one git repo, so users can just download, hit
> one command and they have a working package (as opposed to the current
> scheme, were they need to download svn, then setup some tarball
> directories, then setup svn-uscan, then execute it and only then they
> can actually build the package, so it's very annoying for casual users
> to setup the environment to contribute to the packaging)
Executive suggestion: we wont be able to use the same VCS for all
packages; use whatever the top contributors prefer, not what all
contributors to all packages prefer.
-- Ondrej Certik <ond...@certik.cz> Sat, 20 Sep 2008 16:31:23 +0200
-- Ondrej Certik <ond...@certik.cz> Sun, 17 Aug 2008 21:03:12 +0200
-- Ondrej Certik <ond...@certik.cz> Tue, 08 Jul 2008 15:08:16 +0200
-- Ondrej Certik <ond...@certik.cz> Sun, 06 Jul 2008 18:28:29 +0200
-- Ondrej Certik <ond...@certik.cz> Mon, 09 Jun 2008 17:02:31 +0200
-- Ondrej Certik <ond...@certik.cz> Wed, 30 Apr 2008 13:52:37 +0200
-- Ondrej Certik <ond...@certik.cz> Thu, 13 Mar 2008 00:42:09 +0100
-- William Grant <willia...@ubuntu.org.au> Sat, 08 Mar 2008 12:56:12 +1100
-- Ondrej Certik <ond...@certik.cz> Wed, 20 Feb 2008 15:06:55 +0100
-- Kumar Appaiah <aku...@ee.iitm.ac.in> Sun, 06 Jan 2008 07:36:20 +0530
-- Kumar Appaiah <aku...@ee.iitm.ac.in> Sat, 22 Dec 2007 22:19:32 +0530
-- Ondrej Certik <ond...@certik.cz> Mon, 17 Dec 2007 17:26:57 +0100
[ Ondrej Certik ]
[ Sandro Tosi ]
[ Riku Voipio ]
[ Tiziano Zito ]
[ Carlos Galisteo ]
[ Ondrej Certik ]
[ Emilio Pozuelo Monfort ]
[ Tiziano Zito ]
[ Ondrej Certik ]
[ Andrew Straw ]
[ Kumar Appaiah ]
[ Chris AtLee ]
[ Kumar Appaiah ]
[ Kumar Appaiah ]
[ Ondrej Certik ]
[ Kumar Appaiah ]
[ Sandro Tosi ]
[ Kumar Appaiah ]
[ Kumar Appaiah ]
[ Ondrej Certik ]
--
Loďc Minier
Loïc Minier
> Executive suggestion: we wont be able to use the same VCS for all
> packages; use whatever the top contributors prefer, not what all
> contributors to all packages prefer.
I thought this was clear from the above rationale, but the stats I
attached are for the numpy package only -- since my suggestion is to
decide on a per-package basis. I checked last year worth of numpy
uploads.
> -- Ondrej Certik <ond...@certik.cz> Sat, 20 Sep 2008 16:31:23 +0200
[...]
got...@sapo.pt
> Cyril Brulebois wrote:
>> Tristan Seligmann <mith...@mithrandi.net> (20/12/2008):
>>> My personal preference ordering would probably be:
>>>
>>> hg, bzr, svn, git
>>
>> git, FD, *
>
> +1 :)
>
>
> http://whygitisbetterthanx.com
I don't know git, but I want to learn about it.. so It can be a nice
oportunity to do it.
So +1 for git.
--
Marco Rodrigues
Raphael Hertzog
> I am surprised I am actually the 6th most active. Pretty cool. :)
I am surprised to still be in the top 10 (hertzog)… it means the team is
not so active as one would expect. :-)
Anyway, I'm fine with git as well but I'm not convinced it's that
important. You should also look at the perl team, they are using git
on some packages only and have not yet decided to mass-convert from
SVN to Git. One of the reasons of the block is that Git makes it difficult
to do operations on all the repositories. And for a global update, you're
forced to use tools like "mr" (and even that won't add new package
automatically).
Furthermore, Git alone doesn't mean much, the questions is whether we have
to use git-buildpackage, topgit and so on.
Hence I would rather suggest a per-package decision for the switch. I
won't cry if SVN continues to be used.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Sandro Tosi
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?
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
locally while waiting to connect to network for "svn up && svn co"? it
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?
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*.
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.
> 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>
uscan --verbose --repack --rename --destdir=/where/you/keep/tarballs
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.
Moreover, I don't see any reason to have the fullsource code in the
same VCS of debian/ for the myriad of damn-simple packages we have.
Another question: do you know of any other big team (we have ~300 pkgs
in both papt/dpmt so I see us as a big team) that is on git? I know
none :) I'd take the example of pkg-perl: they maintain ~1000 pkgs,
and they are still on svn (but I don't know if the plan to move to git
anytime soon, but they use for some "corner cases" like perl apps).
So, any team experience we can learn from? are the tools ready to
allow a team (not just single/small group of maintainers) to work on a
plethora of packages in a feasible way?
> so users can just download, hit
> one command and they have a working package (as opposed to the current
> scheme, were they need to download svn, then setup some tarball
> directories, then setup svn-uscan, then execute it and only then they
> can actually build the package, so it's very annoying for casual users
> to setup the environment to contribute to the packaging)
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 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.
Cheers,
Sandro
PS: I may have written it tough (and the "you" is a generic one), but
read it as an open discussion email with ":)" in whatever place you
like :)
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Scott Kitterman
>On Mon, Dec 08, 2008, Ondrej Certik wrote:
>> P.S. bzed, POX, isn't it time to move our packaging to git? 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 -- i.e.
>> everything will be in one git repo, so users can just download, hit
>> one command and they have a working package (as opposed to the current
>> scheme, were they need to download svn, then setup some tarball
>> directories, then setup svn-uscan, then execute it and only then they
>> can actually build the package, so it's very annoying for casual users
>> to setup the environment to contribute to the packaging)
>
> WARNING bikeshedding VCS discussion spotted!
>
> Executive suggestion: we wont be able to use the same VCS for all
> packages; use whatever the top contributors prefer, not what all
> contributors to all packages prefer.
>
I don't think hg, bzr, or git obviously qualify as accesible. My vote, fwiw, is to stay with svn until we have a documented, accessible workflow with tool support.
Scott K
Steve Langasek
> Matthias Klose wrote:
> > I only trust my own comparsion without any date and version numbers.
> > And honestly I don't care about a checkin of the usual 2-5 files
> > taking half a second longer. What annoys me most with git is the
> > steep learning curve and the non-intuitive UI, therefore I do prefer
> > bzr over hg over svn over others.
> In my opinion git is much more intuitive than any other tool - but you have to
> climb a bit on the learning curve before you realize it.
... That's not what the word "intuitive" means.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Loïc Minier
> I'll argue we want something different. We want VCS that will
> maximize participation. That means both keeping top contributors
> happpy and keeping it accessible to newcomers.
>
> I don't think hg, bzr, or git obviously qualify as accesible. My
> vote, fwiw, is to stay with svn until we have a documented, accessible
> workflow with tool support.
Fair point.
--
Loďc Minier
Pietro Battiston
Just my two cents (I certainly have no right/reason to express a vote, but I followed you discussion with interest): as of now, git may maximize participation of newcomers because it's seen as "cool" (whether or not it is) and more and more adopted, while bzr may maximize participation of newcomers because it's popular _now_ (Launchpad and Ubuntu are; I don't think I'm the only maintainer that became it because of being an Ubuntu user).
I frankly don't see how svn can maximize participation of newcomers. Svn
users are tipically long-time "versioners" who probably tried at least
once some more recent versioning tool, probably bzr, or git, or hg (lots
of projects switched from svn to one of those), while bzr users often
have no idea of what svn is.
Then one can say "let's stick to svn because it's a pain to change"; I
just think the "participation" argument is misleading.
Pietro
Scott Kitterman
Everyone on the team has a workflow for SVN. Not true for the others. We have a working system and we ought not move off of it until we have a approach that is easily accessible and well documented.
Carlos
> I frankly don't see how svn can maximize participation of newcomers. Svn
> users are tipically long-time "versioners" who probably tried at least
Well, maybe we should distinguish between newcomers to the team and
newcomers to VCS. A newcomer to the team could master one VCS, two or
none of them, so it's impossible to know his (or her) preferences in
advance. For a newcomer to VCS I really think that svn is easier to
learn than git/hg/bzr but that's just my opinion.
I think the priorities should be, first of all the personal
preferences of top commiters, and secondly what we think could be
helpful for newcomers.
Regards.
--
---
Carlos Galisteo <cgalisteo AT k-rolus.net>
PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg
Key_Fingerprint::F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65
---
Guy Hulbert
> Everyone on the team has a workflow for SVN. Not true for the others.
> We have a working system and we ought not move off of it until we have
> a approach that is easily accessible and well documented.
Besides. Git will talk to a svn repo so it's unnecessary to rush a
conversion.
[just lurking here and on debian-perl]
--
--gh
Ondrej Certik
thanks for the points, I reacted to some.
On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi <mo...@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
Josselin Mouette
> 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.
Precisely. TTBOMK no other VCS is as smooth to operate as subversion
*for Debian packages*. Only svn-buildpackage can handle correctly the
versioning of the debian/ directory alone.
The only serious alternative is to make feature branches corresponding
to patches and to serialize them on the fly before building. I know
Pierre Habouzit has some scripts to do it with git.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Ben Finney
> TTBOMK no other VCS is as smooth to operate as subversion *for
> Debian packages*. Only svn-buildpackage can handle correctly the
> versioning of the debian/ directory alone.
What mis-handlings of a separate ‘debian/’ directory do you know of in
the other ‘$VCS-buildpackage’ tools?
I've not experienced any mis-handlings of separately-versioned
‘debian/’ with ‘bzr-buildpackage’, but perhaps you know of flaws that
I haven't encountered.
--
\ “I stayed up all night playing poker with tarot cards. I got a |
`\ full house and four people died.” —Steven Wright |
_o__) |
Ben Finney
Loïc Minier
> Precisely. TTBOMK no other VCS is as smooth to operate as subversion
> *for Debian packages*. Only svn-buildpackage can handle correctly the
> versioning of the debian/ directory alone.
bzr bd works fine in this mode; did you try it out?
--
Loďc Minier
Sandro Tosi
> thanks for the points, I reacted to some.
so please accept my reply :)
> On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi <mo...@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
Steve Langasek
> Well, maybe we should distinguish between newcomers to the team and
> newcomers to VCS. A newcomer to the team could master one VCS, two or
> none of them, so it's impossible to know his (or her) preferences in
> advance. For a newcomer to VCS I really think that svn is easier to
> learn than git/hg/bzr but that's just my opinion.
If being easy to learn is a factor in deciding which to use, then this
should certainly not be based on opinions. Ease of acquisition isn't
straightforward to objectively /determine/, but it's not a matter of
opinion.
My informed belief (as distinct from an opinion) is that if your intended
workflow is that of a central repository + checkouts, at the very least svn
is not easier to teach than bzr, and possibly not easier to teach than
hg/git; but that the absolute ceiling is much lower for svn than for DVCS.
The real danger is that most people who know DVCSes aren't content to teach
people how to use them like svn. ;)
I agree with Scott that workflow documentation is really the single biggest
factor in how approachable this will be to new contributors.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
Ondrej Certik
> On Wed, Dec 24, 2008 at 00:48, Ondrej Certik <ond...@certik.cz> wrote:
>> thanks for the points, I reacted to some.
>
> so please accept my reply :)
Absolutely. :)
> have you ever tried git-svn to work over your packages actually in the team?
Yes, git-svn rocks and I use it regularly, but branching+merging sucks
with git-svn, plus you cannot really use it with git-buildpackage,
upstream branch and pristine-tar. Also if you reclone it, you have to
follow the howto here in order to dcommit back to svn:
http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone
> 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.
Yes, I do use it just with the debian dir, to see what other people
have done with the package.
>> 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
I want to be able to also easily build let's say the new numpy version
(1.2.1) together with the one in the Debian archive, e.g. 1.1.1.
Because the 1.2.1 requires a bit more work, I cannot yet upload it to
Debian. So now we have 2 orig.tarballs already. You are right, that in
this case I can get both just with apt-get source or svn-uscan.
> 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.
In fact, svn-uscan downloads the one specified in debian/changelog, so
I can get any orig.tarball I need, as long as upstream webpages have
it. The problem is that I need an internet connection and upstream
needs to have working webpages. With git+upstream branch, I can just
clone the repo and go off the internet and I am safe, because I have
everything needed to build any version.
So it boils down to a question of size, e.g. harddisk and net
connection speed/price.
>
>> 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
Ok.
>
>>> 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
I just asked a question and as a science man, I was curious about the
answer. You say "Of course it's bigger. A lot bigger.". So that made
me think, hmm, let's just try it and see. So I took the last 4
upstream releases of numpy, and imported the orig.tarballs one by one
into one git repository, together with the binary-delta (e.g.
pristine-tar).
version, git size, orig.tar.gz size
1.0.1 1.5M 1.2M
1.1.0 2.2M 1.7M
1.1.1 2.3M 1.6M
1.2.1 2.6M 1.4M
So as you can see, the whole repository with all 4 versions is less
than twice as big as any orig.tar.gz. I do not consider this "a lot
bigger".
> locally, you have the HEAD + all other modifications done in the past,
> for both the upstream code and the debianization. It's like
No, only upstream orig.tar.gz is imported, so we do not care about
upstream revisions -- that's not our problem.
> downloading all the uploaded version of the package in the archive
> compared with only the latest one.
As you can see from my example with numpy above, this doesn't seem to
be the case. The amount of downloaded data is *less* than two
orig.tar.gz in the numpy case above.
>
> 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).
Well, but you need to count the orig.tar.gz that you need to download
as well in order to build any package.
The only example I can see is when doing some changes without actually
building the packages, e.g. adding the vcs links to debian/control and
similar things.
>> 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.
Sure. As I said above, in the numpy case it is less than twice as big.
So for me, that is absolutely no problem.
Unless you want to only work on the debian dir without the
orig.tar.gz, but well, I think that is a corner case, because most of
the time I want to build the package.
>>> 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.
Let's make a friendly bet. :) I am saying it will happen, as an
example, take this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507746
so Janis not only reported a bug, but also sent us a patch, after I
explained how to create the patch.
> 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
I disagree with this. I treat every user as a potential (debian)
developer. I also think everyone who is able to report a bug in our
BTS is able to send a patch, if he knows how to fix it -- e.g. many
times people know the right fix, they only don't know how to
technically fix it in the debian packaging. The point of all of this
is that people can fix and test the packages themselves and thus
saving time of Debian Developers. And also all those people are then
potential developers.
> 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.
In case of numpy imho it is not an overkill, see above.
Ondrej
Piotr Ożarowski
> unfortunately I use Git only outside Debian, so I don't know about
> issues git-buildpackage might have. I know it doesn't have
> mergeWithUpstream but it's written in Python, so we can implement this.
> The problem is (FWIK) that it's better to use Git with upstream sources
> (with tools like pristine-tar)... anyway, I vote for Git, but I'm open
> to alternative suggestions.
update: I vote for status quo (svn, svn-buildpackage, mergeWithUpstream)
for now - at least until all top contributors will have decent internet
connection or we'll work out some kind of remote upstream branches
schema so that one could choose what to download (and a script to
download all repositories (packages) within the team)
Ondrej Certik
> [Piotr Ożarowski, 2008-12-23 13:37]
>> unfortunately I use Git only outside Debian, so I don't know about
>> issues git-buildpackage might have. I know it doesn't have
>> mergeWithUpstream but it's written in Python, so we can implement this.
>> The problem is (FWIK) that it's better to use Git with upstream sources
>> (with tools like pristine-tar)... anyway, I vote for Git, but I'm open
>> to alternative suggestions.
>
> update: I vote for status quo (svn, svn-buildpackage, mergeWithUpstream)
> for now - at least until all top contributors will have decent internet
> connection or we'll work out some kind of remote upstream branches
> schema so that one could choose what to download (and a script to
> download all repositories (packages) within the team)
Agree. We talked with Sandro on IRC, the problem is in a bad internet
connection --- it takes ~40min to download 10MB -- then of course
every MB matters. For me it takes just couple seconds, so it doesn't
really matter if I am downloading tarball+debian dir separately, or
together in a git repo.
I just assumed that everyone has a decent internet connection these
days, and I was wrong. :)
Ondrej
Bernd Zeimetz
> Agree. We talked with Sandro on IRC, the problem is in a bad internet
> connection --- it takes ~40min to download 10MB -- then of course
> every MB matters. For me it takes just couple seconds, so it doesn't
> really matter if I am downloading tarball+debian dir separately, or
> together in a git repo.
but then if you need the original sources to build a package - it doesn't
matter much if you get the tarball or clone a git repository.
> I just assumed that everyone has a decent internet connection these
> days, and I was wrong. :)
unfortunately not...
Cheers,
Bernd
--
Bernd Zeimetz Debian GNU/Linux Developer
GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
Sandro Tosi
...
Last reply on this thread, just to recap what Ondrej and me discussed
on irc this evening.
I didn't realize I ain't made clear what's my network situation: I'm
still at 56k, so many of the think you broadband users consider
normal, trivial, or chip, for me they're not. I have to minimize the
stuff I download at home and maximize the effort, and svn
(+downloading the tarball at work, if they are big) allows me to
achieve this balance.
But even if I had an adsl or so, I would say that that git is not the
right choice for our team (but I would have made a lot less problems
migrating to it). I think that, being things are they are now, svn is
the right choice and keep being. What we really need is to migrate a
svn layout-2 repository (one composed by
{trunk,tags,branches,...}/package).
Anyhow, to be short: I count as 1, and we are in democracy; whatever
the team will come up, I'll stick to it eventually changing/reducing
the way I contribute to it.
Cheers and Happy Holidays,
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Tristan Seligmann
> As to mercurial ---- Tristan, I don't know if you actually ever used
> hg-buildpackage, but it is written in Haskell (!) and see my blog post
> here:
I've used it; being written in Haskell isn't something I consider a
problem. It works just fine for what I've used it for; but then again,
the task it performs is relatively simple, so I could probably get along
without it just fine. The main thing that matters to me is using the
VCS itself, since I'll be spending a lot more time interacting with the
VCS than with some vcs-buildpackage tool.
> Anyway, besides stating which vcs one likes, this is mostly a debate
> over a beer in Prague, but well, why not, I just had several of them.
Heh.
--
mithrandi, i Ainil en-Balandor, a faer Ambar