On Fri, Jan 9, 2009 at 1:48 AM, Giovanni Bajo wrote:
> On Sun, 04 Jan 2009 18:50:09 +0900, Stephen J. Turnbull wrote:
>
>> "Martin v. Löwis" writes:
>>
>> > If "switching to a modern DVCS" means that users now need to start
>> > compiling their VCS before they can check out Python,
>>
>> It does
On Sun, 04 Jan 2009 18:50:09 +0900, Stephen J. Turnbull wrote:
> "Martin v. Löwis" writes:
>
> > If "switching to a modern DVCS" means that users now need to start
> > compiling their VCS before they can check out Python,
>
> It doesn't mean that. All of the DVCS contenders have Windows and M
Barry Warsaw wrote:
> On Jan 3, 2009, at 11:29 PM, Steve Holden wrote:
>
>> Brett Cannon wrote:
>> [...]
>>> I have been using bzr for all of my importlib work. It's worked out
>>> well sans the problem that SOMEONE Barry has not
>>> upgraded the bzr installation to support the newest wire protoco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 4, 2009, at 4:21 AM, Stephen J. Turnbull wrote:
Steve Holden writes:
Hey, isn't Ubuntu Debian-based? ...
Ouch. I don't actually use Ubuntu, but when everybody on my local LUG
list from the "Linux should be Windows but cheaper" newbies to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 11:29 PM, Steve Holden wrote:
Brett Cannon wrote:
[...]
I have been using bzr for all of my importlib work. It's worked out
well sans the problem that SOMEONE Barry has not
upgraded the bzr installation to support the newest wire
2009/1/4 Brett Cannon :
> Bazaar has been backwards-compatible with everything from my
> understanding, so any changes they have made to the repository layout
> or network protocol they use should not be an issue regardless of what
> client or server versions are being used. As for the version numb
Disclaimer: I'm a member of the team working with Brett on the DVCS
PEP, and definitely pro-DVCS (specifically working on the git parts).
"Martin v. Löwis" writes:
> If "switching to a modern DVCS" means that users now need to start
> compiling their VCS before they can check out Python,
It do
Steve Holden writes:
> Hey, isn't Ubuntu Debian-based? ...
Ouch. I don't actually use Ubuntu, but when everybody on my local LUG
list from the "Linux should be Windows but cheaper" newbies to former
NetBSD developers is grouching about upgrade hell, I don't see any
real benefits to be gained.
Barry Warsaw wrote:
> On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
>
>> It's always possible to make exceptions. It's not just about the VCS;
>> there have been requests to replace Apache, NTP, Zope, Postgres,
>> MoinMoin, and a few other packages. There have been many problems
>> on upgrade
Brett Cannon wrote:
[...]
> I have been using bzr for all of my importlib work. It's worked out
> well sans the problem that SOMEONE Barry has not
> upgraded the bzr installation to support the newest wire protocol.
>
If you think *that's* a problem try getting him to write a simple bloody
blog en
On Sat, Jan 3, 2009 at 16:39, "Martin v. Löwis" wrote:
>> Bazaar has been backwards-compatible with everything from my
>> understanding, so any changes they have made to the repository layout
>> or network protocol they use should not be an issue regardless of what
>> client or server versions are
Martin v. Löwis v.loewis.de> writes:
> > As for Mercurial, I have been told their repository layout has not
> > changed since their first release and updates have been more about bug
> > fixes and speed improvements.
>
> Speed improvements we can ignore; for bug fixes, it would be good to
> know
On Sun, Jan 4, 2009 at 9:28 AM, Brett Cannon wrote:
> On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" wrote:
>>> Do any of the DVCS under consideration satisfy that requirement? I
>>> guess I'm asking whether you think all this talk about DVCSes is futile
>>> or premature?
>>
>> I still do hope
> Bazaar has been backwards-compatible with everything from my
> understanding, so any changes they have made to the repository layout
> or network protocol they use should not be an issue regardless of what
> client or server versions are being used. As for the version number,
> the team does mont
On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" wrote:
>> Do any of the DVCS under consideration satisfy that requirement? I
>> guess I'm asking whether you think all this talk about DVCSes is futile
>> or premature?
>
> I still do hope that Debian releases lenny before any of this advances.
> Th
Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jan 3, 2009, at 11:54 AM, Ulrich Eckhardt wrote:
>
>> 1. I think that a patch can not e.g. capture a moved, renamed or
>> deleted file.
>> Further, it can not handle e.g. things like the executable bit or
>> similar
>>
> Do any of the DVCS under consideration satisfy that requirement? I
> guess I'm asking whether you think all this talk about DVCSes is futile
> or premature?
I still do hope that Debian releases lenny before any of this advances.
This would mean
bzr 1.5
git 1.5.6
mercurial 1.0.1
I don't have t
Barry Warsaw python.org> writes:
>
> Do any of the DVCS under consideration satisfy that requirement?
Out of curiosity, I apt-get'ed Mercurial on a stable Debian (0.9.1-1+etch1)
and I was able to clone the trunk mirror (*) fine. It just took a bit over two
minutes.
(*) http://code.python.org/hg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 6:27 PM, Martin v. Löwis wrote:
[I don't think Barry actually can/does provide these privileges]
I probably could, but I got pretty burned out doing regular admin
stuff. ;/
- -Barry
-BEGIN PGP SIGNATURE-
Version: Gn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 6:12 PM, Martin v. Löwis wrote:
Maybe this is a false choice. Maybe the problem is standardizing on
Debian stable. If that distribution isn't giving us and our users
what
we need, maybe we need to re-evaluate that choice. Ye
> And with the
> tight feedback loop between committer and contributor along with
> working on a new feature instead of existing code leads to people
> getting commit privileges on the spot (if someone is there to give
> them the privileges; I honestly don't know who has the abilities to
> give the
> Maybe this is a false choice. Maybe the problem is standardizing on
> Debian stable. If that distribution isn't giving us and our users what
> we need, maybe we need to re-evaluate that choice. Yes I know we've
> talked about that before and yes I know it would not be easy to switch
> to somet
On Sat, Jan 3, 2009 at 14:47, "Martin v. Löwis" wrote:
>>> As a consequence, I would always request that whatever VCS Python
>>> uses: the version that is in the current Debian's "stable" distribution
>>> must be sufficient to use the VCS, and must in particular be sufficient
>>> on the server sid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
It's always possible to make exceptions. It's not just about the VCS;
there have been requests to replace Apache, NTP, Zope, Postgres,
MoinMoin, and a few other packages. There have been many proble
>> As a consequence, I would always request that whatever VCS Python
>> uses: the version that is in the current Debian's "stable" distribution
>> must be sufficient to use the VCS, and must in particular be sufficient
>> on the server side.
>>
>
> Even if someone like me or Barry volunteers to ma
Brett Cannon schrieb:
> And the sprints at PyCon have actually acted as a mentoring session
> for a lot of people. People end up helping out with a new feature and
> the committers there are able to do a review instantly. And with the
> tight feedback loop between committer and contributor along w
On Sat, Jan 3, 2009 at 14:17, "Martin v. Löwis" wrote:
>> I have been using bzr for all of my importlib work. It's worked out
>> well sans the problem that SOMEONE Barry has not
>> upgraded the bzr installation to support the newest wire protocol.
>
> I'm probably to blame for this. Debian doesn't
> I have been using bzr for all of my importlib work. It's worked out
> well sans the problem that SOMEONE Barry has not
> upgraded the bzr installation to support the newest wire protocol.
I'm probably to blame for this. Debian doesn't come with the latest
bzr revision (bzr evolves way too fast f
Martin v. Löwis schrieb:
>> Since I will probably add some documentation, and since this
>> documentation will probably
>> benefit from some reviews, what would be the best process ?
>>
>> 1/ commit the changeset and ask for a post-review by Georg (or others)
>> 2/ hold the changeset in a diff for
On Sat, Jan 3, 2009 at 09:52, Georg Brandl wrote:
> Steve Holden schrieb:
>
>> I think it was courageous of Brett to tackle this issue head-on as he
>> did, and of Victor to respond so positively to the various comments that
>> have been made on this thread. It would be a pity to lose a developer
On Sat, Jan 3, 2009 at 10:42, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jan 3, 2009, at 11:36 AM, Martin v. Löwis wrote:
>
>> We can setup such a branch, unless you reconsider and try bazaar first.
>> There wouldn't be any pushing it back upstream, though - you w
> Out of curiosity : is there any mechanism in the post-commit that
> checks if "make html"
> doesn't spit any error ?
No, there is no such mechanism. There are daily builds which will
report errors eventually.
Regards,
Martin
___
Python-Dev mailing lis
On Sat, Jan 3, 2009 at 3:39 PM, Tarek Ziadé wrote:
>
> Out of curiosity : is there any mechanism in the post-commit that
> checks if "make html"
> doesn't spit any error ?
Not automatically. However, Georg and I test it fairly often and fix
markup errors if they're present.
--
Regards,
Benjam
On Sat, Jan 3, 2009 at 10:21 PM, Nick Coghlan wrote:
>> [cut]
>>
>>> 1/ is better for the flow, but the quality of the doc might suffer
>>> from it if Georg (or others) doesn't have time to review it
>>
>> This is of little concern. As long as the documentation continues
>> to build (into html), n
Martin v. Löwis wrote:
>> Since I will probably add some documentation, and since this
>> documentation will probably
>> benefit from some reviews, what would be the best process ?
>>
>> 1/ commit the changeset and ask for a post-review by Georg (or others)
>> 2/ hold the changeset in a diff for a
Georg Brandl wrote:
> I've become cautious of labeling patches as "trivial". Some may really be,
> e.g. typos and the like, but those are almost always dealt with quickly.
> Others may seem trivial, as in "add that line here", but there is often
> a problem associated -- like the question of porta
> Since I will probably add some documentation, and since this
> documentation will probably
> benefit from some reviews, what would be the best process ?
>
> 1/ commit the changeset and ask for a post-review by Georg (or others)
> 2/ hold the changeset in a diff for a pre-review ?
If you are con
On Sat, Jan 3, 2009 at 5:17 PM, "Martin v. Löwis" wrote:
>> Yes, that's the problem. Is it not possible to have finer permission (instead
>> of boolean permission: commit or not commit)? Eg. give commit access but only
>> for a file or a directory? It looks like Tarek Ziade is now allowed to
>> co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 1:51 PM, Antoine Pitrou wrote:
Barry Warsaw python.org> writes:
Although it doesn't help Victor specifically, anyone with svn commit
privileges also has permission to push Bazaar (and I think Mercurial)
branches back to code.py
Barry Warsaw python.org> writes:
>
> Although it doesn't help Victor specifically, anyone with svn commit
> privileges also has permission to push Bazaar (and I think Mercurial)
> branches back to code.python.org.
Actually the Mercurial repositories are read-only. We would need some
server-s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 11:54 AM, Ulrich Eckhardt wrote:
1. I think that a patch can not e.g. capture a moved, renamed or
deleted file.
Further, it can not handle e.g. things like the executable bit or
similar
things that SVN otherwise does manage. T
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 11:36 AM, Martin v. Löwis wrote:
We can setup such a branch, unless you reconsider and try bazaar
first.
There wouldn't be any pushing it back upstream, though - you would
still
need to go through the tracker for all changes.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 10:52 AM, Victor Stinner wrote:
A little offtopic: it seems to me it is a flaw of svn, that it
encourages the model of two classes of developers, those with a
commit
access (first class) and those without it (second class).
Y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 3, 2009, at 7:57 AM, Steve Holden wrote:
In the old days this would have happened by a process known in the
British training world as "sitting with Nellie" - doing the work next
to, and directly supervised by, someone who had been doing it a
Georg Brandl wrote:
> Steve Holden schrieb:
>
>> I think it was courageous of Brett to tackle this issue head-on as he
>> did, and of Victor to respond so positively to the various comments that
>> have been made on this thread. It would be a pity to lose a developer
>> who so obviously has Python
On Saturday 03 January 2009 17:36:04 Martin v. Löwis wrote:
> > As far as your goal is concerned, couldn't you live with a branch where
> > you develop the feature?
>
> That still doesn't help the change getting merged into the trunk.
> Whether you store it in a patch file, in a DVCS, or in the ver
On 03/01/2009 17:54, Ulrich Eckhardt wrote:
1. I think that a patch can not e.g. capture a moved, renamed or deleted file.
Further, it can not handle e.g. things like the executable bit or similar
things that SVN otherwise does manage. That is what makes a patch only
partially suitable.
Actuall
2009-01-03 18:10:27 Martin v. Löwis napisał(a):
> > 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> > file.
>
> Correct. However, this rarely happened. Contributors are not supposed
> rename files, and they can indicate deletions and additions in plain
> English (I typ
On Sat, Jan 3, 2009 at 11:47 AM, Georg Brandl wrote:
> Martin v. Löwis schrieb:
>>> I don't know about others, but downloading and applying a patch doesn't
>>> bother me (it's actually much quicker than doing a whole new SVN checkout).
>>
>> Same here. In fact, when I had to backport patches befor
Steve Holden schrieb:
> I think it was courageous of Brett to tackle this issue head-on as he
> did, and of Victor to respond so positively to the various comments that
> have been made on this thread. It would be a pity to lose a developer
> who so obviously has Python's best interests at heart.
Martin v. Löwis schrieb:
>> I don't know about others, but downloading and applying a patch doesn't
>> bother me (it's actually much quicker than doing a whole new SVN checkout).
>
> Same here. In fact, when I had to backport patches before the usage of
> svnmerge.py, I would always apply the orig
Georg Brandl gmx.net> writes:
>
> It looks like it does, and that's a good thing (once in a while).
Hey, and we've even had a DVCS sub-thread in the process ;)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Victor Stinner schrieb:
>> > If I understood correctly, your main point is that using bugtracker
>> > for committing patches is very painful (I agree).
>>
>> I understood differently: I thought Victor's complaint is that some
>> of his patches stay uncommitted for a long time.
>
> Not only *my* pa
David Cournapeau wrote:
> On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" wrote:
>> [I don't want to get into another DVCS flamewar, but I just
>> can't let this go uncommented :-]
>
> I am sorry if that sounded like a flamewar, that was not my intention:
Oops - maybe the smiley was not obvio
On Sat, Jan 3, 2009 at 8:46 AM, "Martin v. Löwis" wrote:
> [I don't want to get into another DVCS flamewar, but I just
> can't let this go uncommented :-]
>> (took me ~ 1 hour to get around
>> without any previous encounter with git and I am no genius)
>
> I'm no genius, either, and I think that
On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" wrote:
> [I don't want to get into another DVCS flamewar, but I just
> can't let this go uncommented :-]
I am sorry if that sounded like a flamewar, that was not my intention:
I just wanted to point out that there are solution that the op can
imp
> 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> file.
Correct. However, this rarely happened. Contributors are not supposed
rename files, and they can indicate deletions and additions in plain
English (I typically request a tarfile for additions).
> Further, it can
Ulrich Eckhardt knuut.de> writes:
>
> 1. I think that a patch can not e.g. capture a moved, renamed or deleted
> file.
> Further, it can not handle e.g. things like the executable bit or similar
> things that SVN otherwise does manage. That is what makes a patch only
> partially suitable.
Yo
> For me, as a reviewer, a patch is either obvious,
> correct, and complete at first sight - or it is difficult. I can review
> only one difficult patch per week (currently), and that can easily cause
> patches that I need to review to stay in the tracker many months.
The problem for the author o
On Saturday 03 January 2009 17:21:16 Antoine Pitrou wrote:
> Ulrich Eckhardt knuut.de> writes:
> > saying "please merge r1234 from
> > foo into trunk" is much easier than downloading and applying a patch,
> > which doesn't even cover all possible changes that SVN does.
>
> I don't know about other
[I don't want to get into another DVCS flamewar, but I just
can't let this go uncommented :-]
> (took me ~ 1 hour to get around
> without any previous encounter with git and I am no genius)
I'm no genius, either, and I think that git is the most horrible
VCS that I ever had to use. The error mess
> I don't know about others, but downloading and applying a patch doesn't
> bother me (it's actually much quicker than doing a whole new SVN checkout).
Same here. In fact, when I had to backport patches before the usage of
svnmerge.py, I would always apply the original patch multiple times,
rather
> As far as your goal is concerned, couldn't you live with a branch where you
> develop the feature?
That still doesn't help the change getting merged into the trunk.
Whether you store it in a patch file, in a DVCS, or in the very same
VCS-but-different-branch - these are all minor details, which
On Sun, Jan 4, 2009 at 1:21 AM, Antoine Pitrou wrote:
>
> You could clone one of the existing DCVS mirrors and open a branch on a public
> hosting service (bitbucket.org, launchpad, etc.). The annoying thing, though,
> is that it requires your co-workers to learn the DVCS in question.
The proble
Ulrich Eckhardt knuut.de> writes:
>
> saying "please merge r1234 from
> foo into trunk" is much easier than downloading and applying a patch, which
> doesn't even cover all possible changes that SVN does.
I don't know about others, but downloading and applying a patch doesn't
bother me (it's a
> Yes, that's the problem. Is it not possible to have finer permission (instead
> of boolean permission: commit or not commit)? Eg. give commit access but only
> for a file or a directory? It looks like Tarek Ziade is now allowed to
> commit, but only on distutils. I like such permission because
On Saturday 03 January 2009 16:52:56 Victor Stinner wrote:
> > A little offtopic: it seems to me it is a flaw of svn, that it
> > encourages the model of two classes of developers, those with a commit
> > access (first class) and those without it (second class).
>
> Yes, that's the problem. Is it n
> > If I understood correctly, your main point is that using bugtracker
> > for committing patches is very painful (I agree).
>
> I understood differently: I thought Victor's complaint is that some
> of his patches stay uncommitted for a long time.
Not only *my* patches. I spoke about my issues be
> A little offtopic: it seems to me it is a flaw of svn, that it
> encourages the model of two classes of developers, those with a commit
> access (first class) and those without it (second class).
Yes, that's the problem. Is it not possible to have finer permission (instead
of boolean permission
Brett Cannon wrote:
> On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" wrote:
>>> A little offtopic: it seems to me it is a flaw of svn, that it
>>> encourages the model of two classes of developers, those with a commit
>>> access (first class) and those without it (second class). Victor --
>>> may
David Cournapeau gmail.com> writes:
>
> It does not make integration easier, but it certainly makes patch
> management easier for the patch writer. There are other means to
> manage patch on top of svn, but I find git-svn extremely useful.
> Actually, I use git-svn on top of svn repositories for
On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" wrote:
>> A little offtopic: it seems to me it is a flaw of svn, that it
>> encourages the model of two classes of developers, those with a commit
>> access (first class) and those without it (second class). Victor --
>> maybe you can try something l
On Sat, Jan 3, 2009 at 5:50 PM, "Martin v. Löwis" wrote:
>> A little offtopic: it seems to me it is a flaw of svn, that it
>> encourages the model of two classes of developers, those with a commit
>> access (first class) and those without it (second class). Victor --
>> maybe you can try something
> A little offtopic: it seems to me it is a flaw of svn, that it
> encourages the model of two classes of developers, those with a commit
> access (first class) and those without it (second class). Victor --
> maybe you can try something like "git svn", so that you don't have to
> use the bugtracke
> And I hope everyone realizes that they can speak up (publicly or
> privately) about *anyone* in regards to whether they think they need
> to lose their commit privileges for personal or coding reasons. I know
> it's tough to speak out publicly about someone and their coding
> abilities which is w
On Fri, Jan 2, 2009 at 18:53, Victor Stinner
wrote:
> Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
>> When it comes to commit privs in general, I am of the school that they
>> should be handed out carefully. I for one do not want to have to
>> babysit other committers to make sure tha
Le Wednesday 31 December 2008 22:20:54, vous avez écrit :
> When it comes to commit privs in general, I am of the school that they
> should be handed out carefully. I for one do not want to have to
> babysit other committers to make sure that they did something
> correctly.
Last time I asked if an
On Tue, Dec 30, 2008 at 16:55, Victor Stinner
wrote:
> Hi,
>
> I already asked in September to get an svn account to be able to commit
> directly patches to trunk (or other branches like py3k). My query was
> rejected because I didn't know Python core enough (and maybe other reasons
> that I don't
Victor Stinner writes:
> Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit :
> > Would you review your own code in the same way that other committers
> > review their own?
>
> I'm unable to review my own code.
Of course not, in the formal "software process" sense.
Le Wednesday 31 December 2008 08:46:09 Stephen J. Turnbull, vous avez écrit :
> Would you review your own code in the same way that other committers
> review their own?
I'm unable to review my own code. I always re-read my code and test it, but I
can not see every possibles cases. That's why I p
Victor Stinner writes:
> I already asked in September to get an svn account to be able to
> commit directly patches to trunk (or other branches like py3k). My
> query was rejected because I didn't know Python core enough (and
> maybe other reasons that I don't know).
One possible reason is th
From: "Victor Stinner"
Why an svn account instead of just using the amazing bug tracker? Just because
there are not enough people to review/commit patches on the tracker and so
there are more and more open issues (and so more and more lost patches) :-( I
will be able to work faster using the
On Dec 30, 2008, at 8:30 PM, Nick Coghlan wrote:
Victor Stinner wrote:
Hi,
I already asked in September to get an svn account to be able to
commit
directly patches to trunk (or other branches like py3k). My query was
rejected because I didn't know Python core enough (and maybe other
re
Victor Stinner wrote:
> Hi,
>
> I already asked in September to get an svn account to be able to commit
> directly patches to trunk (or other branches like py3k). My query was
> rejected because I didn't know Python core enough (and maybe other reasons
> that I don't know).
>
> I helped to fix
Hi,
I already asked in September to get an svn account to be able to commit
directly patches to trunk (or other branches like py3k). My query was
rejected because I didn't know Python core enough (and maybe other reasons
that I don't know).
I helped to fix many issues using the bug tracker. Th
85 matches
Mail list logo
