I would like an svn account
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. The bigger patch was the bytes filename support for Python3, accepted by Guido (after a long review ;-)). 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 svn. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
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 many issues using the bug tracker. The bigger patch was the bytes filename support for Python3, accepted by Guido (after a long review ;-)).
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 svn.
+1 here Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Dec 30, 2008, at 8:30 PM, Nick Coghlan <ncoghlan@gmail.com> 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 reasons that I don't know).
I helped to fix many issues using the bug tracker. The bigger patch was the bytes filename support for Python3, accepted by Guido (after a long review ;-)).
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 svn.
+1 here
Cheers, Nick.
Also +1 FWIW Jesse
From: "Victor Stinner" <victor.stinner@haypocalc.com>
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 svn.
Based on the work I've seen so far, my preference is that you continue to use the tracker instead of directly committing patches. Raymond
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 that commit privilege is not about quality of code, it's about quality of review. Would you review your own code in the same way that other committers review their own? Would you make the same decisions about which fixes to commit, which changes to wait for others' review, and which to propose on Python-Dev first? Remember, to be appropriate for Python, a patch needs not only to be good code, it must also be "Pythonic". Does your personal sense of code quality result in Pythonic patches? (I can't answer that, because my own sense of Pythonicity is dubiously reliable at best.<wink>) Another possible reason is that, while it's not an absolute requirement, in my projects I'm always a lot more supportive of candidates who have a track record of helping others get their patches committed. Of course if your patches have a history of being accepted often without substantial change, then implicitly you are doing good self-review, and that might be enough. But in my book, that path *should* take longer and demand higher standards than the "review others' patches" path.
The bigger patch was the bytes filename support for Python3, accepted by Guido (after a long review ;-)).
Would you have committed that patch if nobody else had reviewed it?
Just because there are not enough people to review/commit patches on the tracker and
Are you planning to review and commit other people's patches, and help reduce this backlog? Or just your own? Your emphasis on your own working speed suggests the latter. Again, I'm more supportive of people who want commit privileges in part to help improve the project's process, as well as to remove obstacles to their own work.
so there are more and more open issues (and so more and more lost patches) :-(
An open issue is not a lost patch. It's an open issue. In my own projects, I oppose candidates who seem to think that the presumption is that a patch should be applied quickly unless there's good reason given not to. Your phrasing suggests that attitude to me. You don't have to pay attention to me, since I don't have a vote in the matter. And I don't mean to be negatively critical of you, because I'm not in a position to speak for the Powers That Be in Python. Those are my criteria, and other people and projects use different ones. But it seems to me that the committers in Python do mostly conform to my criteria, and thus it's *possible* that those criteria are somewhat representative of the "maybe other reasons [you] don't know." If so, I suppose an explicit explanation may be of use to you (and others in your position). Happy New Year to you!
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 prefer external eyes to review my code for parts of the code that I don't understand/known well enough.
Would you make the same decisions about which fixes to commit, which changes to wait for others' review, and which to propose on Python-Dev first?
I think that I'm able to know if a patch needs a review or not. Especially if the patch changes the behaviour or the API (or if the patch is complex), I always prefer a review. I will not use svn as I use the tracker. Sometimes, I write a quick and dirty patch to demonstrate a feature or to propose a solution to fix the bug. If the solution is accepted, I try to write a better patch.
The bigger patch was the bytes filename support for Python3, accepted by Guido (after a long review ;-)).
Would you have committed that patch if nobody else had reviewed it?
Certainly not. The patch changed the behaviour of most functions related to files. The mailing list + the bug tracker were the right tools.
Just because there are not enough people to review/commit patches on the tracker and
Are you planning to review and commit other people's patches, and help reduce this backlog? Or just your own?
It depends on the issue. There are many trivial fixes that doesn't change the behaviour / API but just improve the project and are waiting for a review or are reviewed but not commited yet. About my own patch: yes, I would like to use direclty on the svn without using the tracker to fix trivial bugs. Example: during one month, there were two gcc warnings in _testcapi module. The fix was trivial and it requires too much efforts to open an issue for such stupid warning.
Again, I'm more supportive of people who want commit privileges in part to help improve the project's process, as well as to remove obstacles to their own work.
My not-so-secret goal is also to improve Python stability against fuzzing. I stopped to work on fuzzing because it took sometimes months to fix a dummy bug (dummy : easy to understand but also easy to fix without side effects). Example of such issue: "import _tkinter; _tkinter.mainloop()" crashs Python (maybe not directly but later on garbage collection). I opened the issue (with a patch) in august, gpolo reviewed the patch ("Looks fine to me.") two weeks later, but 4 months later the isue is still open: http://bugs.python.org/issue3638 Is it was you called "An open issue is not a lost patch."?
An open issue is not a lost patch. It's an open issue. In my own projects, I oppose candidates who seem to think that the presumption is that a patch should be applied quickly unless there's good reason given not to. Your phrasing suggests that attitude to me.
Even after a review, some issues stay open for months or years. Another example of issue: nntplib doesn't support IPv6, dmorr proposed a simple and good patch reusing the nice function socket.create_connection() one year ago. In this case, I think that nobody was able to test the change. But without testing it, I'm sure that the patch is better than the current situation. Well, if I have to commit the patch, I will test it before. My computer has a public IPv6 address :-) http://bugs.python.org/issue1664
You don't have to pay attention to me,
No, your opinion is interresting. I hope that my answers will help you to understand my expectations about an svn account :-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
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. But in some sense to commit code you have to have reviewed it, that's all I meant.
Is it was you called "An open issue is not a lost patch."?
Yes, and I'll say it again:
An open issue is not a lost patch. It's an open issue.
Even after a review, some issues stay open for months or years.
There *is* a process problem, though I don't claim to have an idea how to solve it. Some developers (especially well-known is Martin van Loewis) are trying to address this with the "one committer's review for five reviews" offer, but maybe there are even better ways to do it. However, this is a *different problem* from "lost patches", which many projects do suffer from, and shouldn't be called by that name, which is insulting to the Python committers. In particular, we know that effort is devoted to tracking open issues by the developers, both individually and as a formal matter (the weekly report). It is insufficient in some sense, but way better than, say, in XEmacs (a project I'm supposed to be leading :-/ ). And IIRC the statistics show that the number of issues closed is of the same order of magnitude as those opened, although consistently lower by 10-20%. Actually, I think that's pretty amazing for a project that has nobody whose salary depends on getting the numbers up.
You don't have to pay attention to me,
No, your opinion is interresting. I hope that my answers will help you to understand my expectations about an svn account :-)
Well, as I say I have no vote. But I hope your answers will help to convince any doubters among the committers.
Hi, Stephen J. Turnbull <stephen <at> xemacs.org> writes:
There *is* a process problem, though I don't claim to have an idea how to solve it. Some developers (especially well-known is Martin van Loewis) are trying to address this with the "one committer's review for five reviews" offer, but maybe there are even better ways to do it. However, this is a *different problem* from "lost patches", which many projects do suffer from, and shouldn't be called by that name, which is insulting to the Python committers.
I don't think it is insulting (I say that as a young Python committer), and I do think it is fair to call them "lost patches". Perhaps not after four months, but when a good patch hasn't been committed after two years, it is potentially lost because the code base has changed a lot since that and 1) the patch doesn't apply completely anymore 2) it must be reassessed whether the patch is good/useful/necessary with respect to the current code base, which can be tricky. As for reviews, we don't seem to use Rietveld a lot, although it offers a nice interface for comfortably viewing changes, and possibly commenting them. The overhead of having to open a separate issue in Rietveld and upload the patch there is a bit annoying, though. Regards Antoine.
On Wed, Dec 31, 2008 at 07:11, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi,
Stephen J. Turnbull <stephen <at> xemacs.org> writes:
There *is* a process problem, though I don't claim to have an idea how to solve it. Some developers (especially well-known is Martin van Loewis) are trying to address this with the "one committer's review for five reviews" offer, but maybe there are even better ways to do it. However, this is a *different problem* from "lost patches", which many projects do suffer from, and shouldn't be called by that name, which is insulting to the Python committers.
I don't think it is insulting (I say that as a young Python committer), and I do think it is fair to call them "lost patches". Perhaps not after four months, but when a good patch hasn't been committed after two years, it is potentially lost because the code base has changed a lot since that and 1) the patch doesn't apply completely anymore 2) it must be reassessed whether the patch is good/useful/necessary with respect to the current code base, which can be tricky.
It is unfortunate when a good patch for a real issue doesn't get applied during the current development cycle. But I honestly think, in general, the important ones do get looked at and handled. Yes, some slip through the cracks, but overall I think we do pretty well.
As for reviews, we don't seem to use Rietveld a lot, although it offers a nice interface for comfortably viewing changes, and possibly commenting them. The overhead of having to open a separate issue in Rietveld and upload the patch there is a bit annoying, though.
My hope is that some day we get around to fixing this and getting a code review application tied into the issue workflow so it is no more than pressing a button. -Brett
On Tue, Dec 30, 2008 at 16:55, Victor Stinner <victor.stinner@haypocalc.com> 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 am going to stick my neck out on this one and say why I have not spoken up for giving you commit privs, Victor, and my general thoughts on handing them out since I don't think this has been stated by anyone before. 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. That's a waste of my time since that defeats the purpose of having more committers. This is why I think Benjamin got is privs too soon. Luckily Georg took it upon himself, I assume because he gave Benjamin the privileges, to double-check all of Benjamin's checkins and fix them until Benjamin absorbed enough of the development process to no longer need to be watched over. But I was honestly rather close to suggesting Benjamin lose is privileges early on until he had more time to figure out how things worked. Luckily it didn't come to that and Benjamin has turned out to be a good developer. I also want people who have no agenda. It's okay to have an area you care about, but that doesn't mean you should necessarily say "I will only work on math, ever, even if something is staring me right in the face!", etc. There is also dedication. I don't like giving commit privileges to people who I don't think will definitely stick around. It's fine if they come and go, but if I am not sure if they will typically come back I would prefer to not bother giving them the privilege of saying they are a developer of Python. Typically this takes a year of regular contributions for me to believe this. And lastly, general cohesion with the other committers. Once you become a committer you become a co-worker in a way and that means getting along with everybody. And since we don't have some manager who forces a new co-worker down our throats we tend to be very picky about this. Plus I already lived through high school and I don't want that kind of drama here. So that is my personal criteria on whether or not I speak up for someone getting commit privileges. How do you play into all of this in my head? To start, your focus on security, for me at least, goes too far sometimes. I have disagreed with some of your decisions in the name of security in the past and I am not quite ready to say that if you committed something I wouldn't feel compelled to double-check it to make sure you didn't go too far. This worry, though, has gone down a lot compared to the last time you asked for commit privs. And I do worry about your attitude. I remember at one point you basically threatened to stop helping because your patches were not been looked at quickly. That really pissed me off personally. You have improved here and are a lot less abrasive than you were, but I am still smarting a little from some comments you made a few months back that came off as pushy. And as I said, I prefer to give commit privileges to people who I think will stick around and have been contributing regularly for a year (I just checked bugs.python.org and it looks like you got really involved only five months ago). Saying you stopped doing your fuzzing work simply because the turn-around was not to your liking does not cause me to instantly think you will stick around when it gets nasty around here (which in variably does a couple times a year). In other words I think you are on the right track to get commit privileges in the future, but just not right now (although if you did get them right now I wouldn't throw up a roadblock). -Brett
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 anyone could help me in Python core if I had an svn account, and I get this answer: everybody will review the changes. Anyway, why do you fear problems? Did I already push buggy commits? I posted many patches on Python bug tracker, most of them required many versions until they get perfect. But it doesn't mean that with an svn account, I will skip the bug tracker to wrote directly in the svn as my personal copy of Python!?
I also want people who have no agenda. It's okay to have an area you care about, but that doesn't mean you should necessarily say "I will only work on math, ever, even if something is staring me right in the face!", etc.
I wrote that I would like to improve Python quality by fuzzing, but I already contributed to many different topics by patches on the bug tracker.
There is also dedication. I don't like giving commit privileges to people who I don't think will definitely stick around. (...)
I don't understand why this is a problem.
To start, your focus on security, for me at least, goes too far sometimes. I have disagreed with some of your decisions in the name of security in the past and I am not quite ready to say that if you committed something I wouldn't feel compelled to double-check it to make sure you didn't go too far.
I'm not sure that I understood correclty: does it mean that some of my issues were not reproductible in the real world (far from the real usage of Python)? It's true that some issues found by fuzzing are hard to reproduce (require a prepared environment), but my goal is to kill all bugs :-) Even if the bug is hard to reproduce, it does exist and that's why I'm thinking that it should be fixed. Sorry if I misused the name "security" but I don't remember where I wrote that "this issue is very security and related to security". Maybe by the imageop issues? -- About fuzzing: I'm still using my fuzzer Fusil on Python trunk and py3k, and I find fewer and fewer bugs ;-) Most of the time I rediscover bugs already reported to the tracker, but not fixed yet. So the fuzzing job is mostly done ;-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
On Fri, Jan 2, 2009 at 18:53, Victor Stinner <victor.stinner@haypocalc.com> 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 that they did something correctly.
Last time I asked if anyone could help me in Python core if I had an svn account, and I get this answer: everybody will review the changes. Anyway, why do you fear problems? Did I already push buggy commits? I posted many patches on Python bug tracker, most of them required many versions until they get perfect. But it doesn't mean that with an svn account, I will skip the bug tracker to wrote directly in the svn as my personal copy of Python!?
I know people will review your commits, but I prefer to have that be a safety precaution than any feeling that it is really required. And if you really do plan to continue to use the tracker heavily, that does help alleviate this worry. Once you have the ability to check in directly the temptation to skip having to wait for reviews becomes rather strong.
I also want people who have no agenda. It's okay to have an area you care about, but that doesn't mean you should necessarily say "I will only work on math, ever, even if something is staring me right in the face!", etc.
I wrote that I would like to improve Python quality by fuzzing, but I already contributed to many different topics by patches on the bug tracker.
There is also dedication. I don't like giving commit privileges to people who I don't think will definitely stick around. (...)
I don't understand why this is a problem.
Because when people contribute large bodies of code and then disappear someone then eventually has to step in and take up maintenance. That means more stuff for someone to have to keep up with and having to learn how the code works.
To start, your focus on security, for me at least, goes too far sometimes. I have disagreed with some of your decisions in the name of security in the past and I am not quite ready to say that if you committed something I wouldn't feel compelled to double-check it to make sure you didn't go too far.
I'm not sure that I understood correclty: does it mean that some of my issues were not reproductible in the real world (far from the real usage of Python)? It's true that some issues found by fuzzing are hard to reproduce (require a prepared environment), but my goal is to kill all bugs :-) Even if the bug is hard to reproduce, it does exist and that's why I'm thinking that it should be fixed.
Sorry if I misused the name "security" but I don't remember where I wrote that "this issue is very security and related to security". Maybe by the imageop issues?
What I mean is that I remember an instance or two where you found something that seemed like a security issue but that is otherwise not critical and wanting to make a change for it that I disagreed with based on it being security-related. Python is basically secure, but we have never claimed we are perfect. And I understand wanting to squash all bugs, but there have to be priorities, and sometimes security is not the highest priority for really obscure stuff. Or at least that's my opinion.
--
About fuzzing: I'm still using my fuzzer Fusil on Python trunk and py3k, and I find fewer and fewer bugs ;-) Most of the time I rediscover bugs already reported to the tracker, but not fixed yet. So the fuzzing job is mostly done ;-)
That's good to hear! As I said, you are on your way, but I personally just am not ready to give you a +1 for commit privs. As Raymond said and you admitted to above, your patches still go through several revisions. Having commit privileges means you can skip that step and I am just not feeling comfortable with that to happen yet. But if another core developer or three are willing to say they will act as probationary officers on ALL of your commits for a while and you at least initially continue to use the issue tracker until the people watching your commits are willing to say you don't need to be watched, then I am fine with you getting commit privs. 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 why I am trying to rationalize this for Victor instead of just sitting quietly while he does or does not get responses from people on whether he should get commit privileges. Every time commit privileges are given out it is a leap of faith and sometime the leap comes up short. -Brett
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 why I am trying to rationalize this for Victor instead of just sitting quietly while he does or does not get responses from people on whether he should get commit privileges. Every time commit privileges are given out it is a leap of faith and sometime the leap comes up short.
I am not a core developer, but I was following this thread with interest. 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 bugtracker and wait until someone reviews the patches? If I understood correctly, your main point is that using bugtracker for committing patches is very painful (I agree). But since patches should be reviewed anyways, imho just using better tools that make the workflow more fluent could solve the problem and remove the friction of deciding if someone is good enough to get a svn commit access. Ondrej
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 bugtracker and wait until someone reviews the patches?
I don't think that this changes anything at all. You can commit to your DVCS all the time, however, doing so is futile if your patches don't get integrated. So you will always have two classes of developers: those with write permissions to the trunk branch, and those without. FWIW, you can already get the Python tree through bazaar and a few other DVCSs.
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. Victor wants to commit small changes without review. Regards, Martin
On Sat, Jan 3, 2009 at 5:50 PM, "Martin v. Löwis" <martin@v.loewis.de> 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 like "git svn", so that you don't have to use the bugtracker and wait until someone reviews the patches?
I don't think that this changes anything at all. You can commit to your DVCS all the time, however, doing so is futile if your patches don't get integrated.
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 projects I have write access to. git-svn is then a powerful way to manage patches (thanks to rebase). cheers, David
David Cournapeau <cournape <at> 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 projects I have write access to. git-svn is then a powerful way to manage patches (thanks to rebase).
I also use Mercurial for my Python work. It's much more practical to evolve and maintain patches, even with commit access. Regards Antoine.
On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" <martin@v.loewis.de> 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 like "git svn", so that you don't have to use the bugtracker and wait until someone reviews the patches?
I don't think that this changes anything at all. You can commit to your DVCS all the time, however, doing so is futile if your patches don't get integrated.
So you will always have two classes of developers: those with write permissions to the trunk branch, and those without.
Nor will this ever change. I do not ever see us taking on the attitude of a project like Pugs where they give commit privileges to anyone who has ever written a single, good patch.
FWIW, you can already get the Python tree through bazaar and a few other DVCSs.
And work is being done to eventually transition to a DVCS anyway, so this will not be an issue forever.
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. Victor wants to commit small changes without review.
This is what I understood to be Victor's desire as well. Victor is prolific enough in writing patches for Python that he has been bitten by the fact that issues are triaged based on individual committer priorities which can lead to patches sitting on the tracker for a while. -Brett
Brett Cannon wrote:
On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" <martin@v.loewis.de> 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 like "git svn", so that you don't have to use the bugtracker and wait until someone reviews the patches? I don't think that this changes anything at all. You can commit to your DVCS all the time, however, doing so is futile if your patches don't get integrated.
So you will always have two classes of developers: those with write permissions to the trunk branch, and those without.
Nor will this ever change. I do not ever see us taking on the attitude of a project like Pugs where they give commit privileges to anyone who has ever written a single, good patch.
FWIW, you can already get the Python tree through bazaar and a few other DVCSs.
And work is being done to eventually transition to a DVCS anyway, so this will not be an issue forever.
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. Victor wants to commit small changes without review.
This is what I understood to be Victor's desire as well. Victor is prolific enough in writing patches for Python that he has been bitten by the fact that issues are triaged based on individual committer priorities which can lead to patches sitting on the tracker for a while.
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. As someone with a strong interest in Python's development, but whose interests lie outside direct development at the code face I would like to see some way where committed non-committers like Victor could be mentored through the initial stages of development, to the point where they can be trusted to make commits that don't need reversion. 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 long time and who knew all the wrinkles of the job. Quite how to achieve a similar effect in today's distributed development environment is less obvious. Could we talk about this at PyCon (as well as continuing this thread to some sort of conclusion)? While the sprints are great for those who are already involved some activity specifically targeted at new developers would be a welcome addition, and might even help recruit them. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
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.
Full ACK.
As someone with a strong interest in Python's development, but whose interests lie outside direct development at the code face I would like to see some way where committed non-committers like Victor could be mentored through the initial stages of development, to the point where they can be trusted to make commits that don't need reversion.
I don't think we have the manpower to do that beyond the already established "I have to sign off all your commits" procedure. Of course, this is time consuming, so maybe for Victor it is just the matter of no developer currently finding the time to do it.
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 long time and who knew all the wrinkles of the job. Quite how to achieve a similar effect in today's distributed development environment is less obvious.
IRC gets relatively close to sitting next to someone :)
Could we talk about this at PyCon (as well as continuing this thread to some sort of conclusion)? While the sprints are great for those who are already involved some activity specifically targeted at new developers would be a welcome addition, and might even help recruit them.
Topic for the language summit? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
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's best interests at heart.
Full ACK.
As someone with a strong interest in Python's development, but whose interests lie outside direct development at the code face I would like to see some way where committed non-committers like Victor could be mentored through the initial stages of development, to the point where they can be trusted to make commits that don't need reversion.
I don't think we have the manpower to do that beyond the already established "I have to sign off all your commits" procedure. Of course, this is time consuming, so maybe for Victor it is just the matter of no developer currently finding the time to do it.
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 long time and who knew all the wrinkles of the job. Quite how to achieve a similar effect in today's distributed development environment is less obvious.
IRC gets relatively close to sitting next to someone :)
Could we talk about this at PyCon (as well as continuing this thread to some sort of conclusion)? While the sprints are great for those who are already involved some activity specifically targeted at new developers would be a welcome addition, and might even help recruit them.
Topic for the language summit?
+1, but I won't be at the summit because I'll be teaching tutorials that day. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On Sat, Jan 3, 2009 at 09:52, Georg Brandl <g.brandl@gmx.net> 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's best interests at heart.
Full ACK.
As someone with a strong interest in Python's development, but whose interests lie outside direct development at the code face I would like to see some way where committed non-committers like Victor could be mentored through the initial stages of development, to the point where they can be trusted to make commits that don't need reversion.
I don't think we have the manpower to do that beyond the already established "I have to sign off all your commits" procedure. Of course, this is time consuming, so maybe for Victor it is just the matter of no developer currently finding the time to do it.
This is why I am trying to document the development procedures. That way at least the initial steps for handling various details are obvious and thus won't take up someone's time in explaining them. And to help make sure this thread stays on course, it very well might be the case that no one has the time to be Victor's mentor at this moment. I know I don't have the time right now.
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 long time and who knew all the wrinkles of the job. Quite how to achieve a similar effect in today's distributed development environment is less obvious.
IRC gets relatively close to sitting next to someone :)
Could we talk about this at PyCon (as well as continuing this thread to some sort of conclusion)? While the sprints are great for those who are already involved some activity specifically targeted at new developers would be a welcome addition, and might even help recruit them.
Topic for the language summit?
Maybe. We will see how that whole thing goes. I suspect it will be rather organic so it will depend on how much time there is. 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 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 rights anymore beyond Barry, Martin, and Neal). -Brett
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 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 rights anymore beyond Barry, Martin, and Neal).
FWIW, I'm also among them. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
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 rights anymore beyond Barry, Martin, and Neal).
[I don't think Barry actually can/does provide these privileges] I'd like to point out that there is a separation between the management privilege, and the technical implementation. Neal, Georg, and I do add committers to the database, however, we don't make the decision to add them. Instead, we (atleast I) try to sense consensus among committers, and then implement what I feel this consensus is. There can always a BDFL pronouncement, and also the release manager (i.e. Barry) can order that somebody gets commit access. In most other cases, consensus was fairly obvious. In the specific case of Victor Stinner, there had been a few seconds, but none of the long-time committers supported him, so I did not add him (I was opposed myself as well). Now that he asked a second time, the opposition spoke up. Regards, Martin
-----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: GnuPG v1.4.9 (Darwin) iQCVAwUBSV/1TnEjvBPtnXfVAQKtwwP/XCZhr6PiAQ74aygiAV2BgsWjuc7iTVrC Rjssr2U6BKIhHDz8g1WkIoaaeKDfq1TU9eCiEPf4+FxtFRsqVox3j1r71PuHDqtc 9jfiXje0x1CtXa7SKJbdU55EUWHMuf1kOwqk1LoiotdVP82Jq/cbOhQ+/QlOPzsk aajuxL5eoqA= =mpRv -----END PGP SIGNATURE-----
-----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 long time and who knew all the wrinkles of the job. Quite how to achieve a similar effect in today's distributed development environment is less obvious.
Could we talk about this at PyCon (as well as continuing this thread to some sort of conclusion)? While the sprints are great for those who are already involved some activity specifically targeted at new developers would be a welcome addition, and might even help recruit them.
I think this is a great idea. I would like to see a more formal mentoring process. As a community I think we need a constant source of fresh blood, and mentoring is a great way to shepherd those new recruits to full commit privileges. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV+v0XEjvBPtnXfVAQIUsAP/aAO7ykXaSP/mA6Cs2874vYIHWZnzYnJx +hyv2i0A65Td9FX2+Jno/TtXLamnU7qC+gqOvf+bkPKyV1T0SlInm0ZXPa0hcNou tKCN0xQCSpKIKnSWMI1VFapHyTUHneDvwY6AHh3mK77MLWdZBK1GTr3Pp10D+5Tj eH9b93mBehY= =xJml -----END PGP SIGNATURE-----
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 because I know them better than the other ones ;-)
Victor wants to commit small changes without review.
That's true. Open an issue for trivial changes takes to much time. -- I hope that the discussion of my svn acount would benefit to the whole Python process ;-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
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* patches. I spoke about my issues because I know them better than the other ones ;-)
Victor wants to commit small changes without review.
That's true. Open an issue for trivial changes takes to much time.
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 portability, or backwards compatibility. In a few cases, we can see that as committing the fix leads to some complaint, and it is backed out again. But there might be others where the problem is overlooked and only noticed after some time in a more public fashion.
--
I hope that the discussion of my svn acount would benefit to the whole Python process ;-)
It looks like it does, and that's a good thing (once in a while). Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
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 portability, or backwards compatibility. In a few cases, we can see that as committing the fix leads to some complaint, and it is backed out again. But there might be others where the problem is overlooked and only noticed after some time in a more public fashion.
And other times something that *seems* to have a simple fix turns out to be a symptom of a deeper problem (there was one along those lines recently where there was an underlying issue with the changes to __hash__ inheritance in Py3k that surfaced as an apparent misbehaviour of hashing of range() instances - the problem was actually in PyObject_Hash(), range() just happened to trigger it). Deciding when to commit a fix directly and when to use the tracker (or even a branch) to get additional input on a change is actually one of the more interesting judgment calls that comes with commit privileges. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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: 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 nobody knows the whole Python project, it's too huge for a single brain ;-)
your main point is that using bugtracker for committing patches is very painful (I agree)
No, my point is that some patches stay too long in the tracker. GIT, Mercurial or anything else are a little bit better than the tracker (the patches can be synchronized with upstream), but the goal is to be part of the upstream code base. A distributed VCS is useful to test huge changes. Performance improvment on integers (patches to optimize the multiplication, use base 2^30 instead of 2^15, etc.) would benefit from such tools, because cooperative work is easier. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
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 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?
Yes it is possible. As far as your goal is concerned, couldn't you live with a branch where you develop the feature? That way, people could see your code and e.g. switch their working copies there for testing or even merge it into trunk some day. SVN actually supports that rather well, it would be guaranteed to not affect the quality of the releases negatively and 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. Actually, I'd like such a branch, too, where I could move much quicker and in particular with the backing of a VCS to port Python to MS Windows CE. Currently, I'm tempted to pull the code into a private repository, which causes problems when I want to push it back upstream. Uli
Ulrich Eckhardt <doomster <at> 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 actually much quicker than doing a whole new SVN checkout). What takes time and effort is to actually check and review the patch (or branch, or whatever).
Actually, I'd like such a branch, too, where I could move much quicker and in particular with the backing of a VCS to port Python to MS Windows CE. Currently, I'm tempted to pull the code into a private repository, which causes problems when I want to push it back upstream.
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. Regards Antoine.
On Sun, Jan 4, 2009 at 1:21 AM, Antoine Pitrou <solipsis@pitrou.net> 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 problem is pushing back to upstream; I don't know much about mercurial, but I would advise the op to take a look at git-svn or similar tools with other DVCS (each tool has its own way). It really is the best IMHO to track a project upstream, with the option of pushing back - again, it is so simple (took me ~ 1 hour to get around without any previous encounter with git and I am no genius) and useful that it is my method of choice to commit to projects I am developing for and which use svn. cheers, David
[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 messages are incomprehensible, and it fails to do stuff that should be trivial (and indeed is trivial in subversion). On this project, I spent 40% of the time fighting git, 40% of the time fighting Perl, and was productive on 20% of the time. IOW, I find the learning curve for git extremely steep. Regards, Martin
On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" <martin@v.loewis.de> 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 implement all by himself to make his life easier - or not.
IOW, I find the learning curve for git extremely steep.
But a steep learning curve means that little input gives great output, no ? :) David
David Cournapeau wrote:
On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" <martin@v.loewis.de> 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 obvious enough. I didn't think of your message as flaming - rather of mine. Sorry for the misunderstanding.
I just wanted to point out that there are solution that the op can implement all by himself to make his life easier - or not.
Right. I believe the bazaar branches that we have set up can do the same thing, just as well.
IOW, I find the learning curve for git extremely steep.
But a steep learning curve means that little input gives great output, no ? :)
:-) I never understood that picture well. In any case (to stay in the picture), the problem is not only that it is steep (and thus stressing to climb), but also that it (the amount of stuff you need know to use git) is very large. Regards, Martin
On Sat, Jan 3, 2009 at 8:46 AM, "Martin v. Löwis" <martin@v.loewis.de> 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 git is the most horrible VCS that I ever had to use. The error messages are incomprehensible, and it fails to do stuff that should be trivial (and indeed is trivial in subversion). On this project, I spent 40% of the time fighting git, 40% of the time fighting Perl, and was productive on 20% of the time. IOW, I find the learning curve for git extremely steep.
That is interesting, I had the opposite experience. :) http://ondrejcertik.blogspot.com/2008/12/experience-with-git-after-4-months.... Ondrej
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 than trying to use svn merge. Integrating patches is only tedious if they don't apply cleanly anymore, in which case I usually ask the contributor to regenerate it (which they often can easily do as they had been tracking trunk in their own sandboxes).
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.
We (as his co-workers) would continue to request patches. So the DVCS better has a convenient way to generate a patch (even from multiple DVCS commits). I think that's what (git) people call "feature branch": a branch with the sole purpose of developing a single patch. Regards, Martin
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 original patch multiple times, rather than trying to use svn merge.
Integrating patches is only tedious if they don't apply cleanly anymore, in which case I usually ask the contributor to regenerate it (which they often can easily do as they had been tracking trunk in their own sandboxes).
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.
We (as his co-workers) would continue to request patches. So the DVCS better has a convenient way to generate a patch (even from multiple DVCS commits). I think that's what (git) people call "feature branch": a branch with the sole purpose of developing a single patch.
One good thing is also that a big change is usually split up into multiple commits, and each commit can be exported as a single patch. I for one am much better at reviewing small, isolated changes, than glorious rewrites of a whole module, and I suspect I'm not alone in this. So it's much better to have a large change chunked into small, manageable bites that can even be applied individually without having to pull in everything at once. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, Jan 3, 2009 at 11:47 AM, Georg Brandl <g.brandl@gmx.net> 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 before the usage of svnmerge.py, I would always apply the original patch multiple times, rather than trying to use svn merge.
Integrating patches is only tedious if they don't apply cleanly anymore, in which case I usually ask the contributor to regenerate it (which they often can easily do as they had been tracking trunk in their own sandboxes).
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.
We (as his co-workers) would continue to request patches. So the DVCS better has a convenient way to generate a patch (even from multiple DVCS commits). I think that's what (git) people call "feature branch": a branch with the sole purpose of developing a single patch.
One good thing is also that a big change is usually split up into multiple commits, and each commit can be exported as a single patch. I for one am much better at reviewing small, isolated changes, than glorious rewrites of a whole module, and I suspect I'm not alone in this. So it's much better to have a large change chunked into small, manageable bites that can even be applied individually without having to pull in everything at once.
Another advantage is the commit logs, which give the reviewer some insight into what the patch author was thinking. I groan internally whenever I see a patch which starts with 100 "-" lines followed by a complete rewrite of the code. Incremental diffs make it easier to follow the evolution of the code leading to a better review. For patch authors, it also conferrers the beauty of version control to their work. For example, if I review dislikes the last change, it's trivial to revert. -- Regards, Benjamin
On Saturday 03 January 2009 17:21:16 Antoine Pitrou wrote:
Ulrich Eckhardt <doomster <at> 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 actually much quicker than doing a whole new SVN checkout).
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. 2. You don't checkout anew. You simply switch ("svn switch") your existing working copy to the branch which just pulls the differences and merges them into your existing working copy. Or, you could merge the changes on a branch ("svn merge") into your working copy.
What takes time and effort is to actually check and review the patch (or branch, or whatever).
Yes, full ACK. Uli
Ulrich Eckhardt <doomster <at> 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.
You are right, I had forgotten about that. regards Antoine.
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 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.
Probably correct; this isn't a problem in practice, either. In fact, it is better if properties come from the subversion installation of the committer, rather than from the contributor, as the committer is supposed to have his autoprops set correctly. I do think that "svn diff" will record property changes, and that may include svn:executable. I don't know which patch tool would interpret them, though. Regards, Martin
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 typically request a tarfile for additions).
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.
Probably correct; this isn't a problem in practice, either. In fact, it is better if properties come from the subversion installation of the committer, rather than from the contributor, as the committer is supposed to have his autoprops set correctly.
I do think that "svn diff" will record property changes, and that may include svn:executable. I don't know which patch tool would interpret them, though.
Subversion 1.7 will probably contain 'svn patch' subcommand, which will be able to apply patches which change properties, or copy/add/delete files/directories... -- Arfrever Frehtes Taifersar Arahesis
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.
Actually, git and Mercurial support the git extensions to the diff format, which support those things (mode changes, moves, copies, etc.) So if you're willing to sacrifice patch(1) compatibility, there are options... Cheers, Dirkjan
-----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. That is what makes a patch only partially suitable.
Bazaar bundles handle moved, renamed and deleted files and directories, afaik. Executable bits and other file metadata are harder because such properties are OS specific, and Bazaar tries to be OS agnostic.
2. You don't checkout anew. You simply switch ("svn switch") your existing working copy to the branch which just pulls the differences and merges them into your existing working copy. Or, you could merge the changes on a branch ("svn merge") into your working copy.
I know that many VCSs support this style of working, but this just doesn't fit my brain. I much prefer separate working trees, each with its own feature or fix. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV+ymnEjvBPtnXfVAQIDKgQArzTiPmBZnrVBnfrn4kfIJ/21cT+RVCsI S9rtIrMRtxAETIeA0ko/9zPLatktYft8hpK77IBo2f1ZSs9vpGRZbm30j4OtQOAR /A/1hr6yGCNzc0OtbHoB7OoJ+1+0ORv+otmUIXJYWTiIOhG3y6oj1gWYkmwhYJRc 87333i8VIj0= =azL0 -----END PGP SIGNATURE-----
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 things that SVN otherwise does manage. That is what makes a patch only partially suitable.
Bazaar bundles handle moved, renamed and deleted files and directories, afaik. Executable bits and other file metadata are harder because such properties are OS specific, and Bazaar tries to be OS agnostic.
Actually, Bazaar also handles the execute bit too. But it doesn't try to capture any other file metadata like mtime or permissions. -Andrew.
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 may affect the efficiency of producing and technically integrating the patch. It doesn't help to the least in speeding up reviews of the patch, or reduces the amount of work necessary to do a review. For that, all that the contributor can do is to make the contribution review-friendly (make the patch technically complete, separate independent issues, provide a concise, but explicit description, and possibly a guide through the patch); I think Victor could still improve his patches in this respect (and I do understand the difficulties of the language barrier). 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. Of course, there are more active reviewers, so the acceptance rate is higher; OTOH, many committers don't review at all, or shy away from difficult patches.
Actually, I'd like such a branch, too, where I could move much quicker and in particular with the backing of a VCS to port Python to MS Windows CE. Currently, I'm tempted to pull the code into a private repository, which causes problems when I want to push it back upstream.
[I guess you aren't happy with the DVCS systems, such as bazaar, which supposedly work perfect in exactly this case. I won't blame you for that, but still, consider trying out one of them for this project] 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. The only advantage I can see is that it simplifies repeated merging of the trunk into your branch. Regards, Martin
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 of the patch is that he/she doesn't know that. You may drop a comment like "please explain how to reproduce the problem / why the patch is needed / how your patch fixes the issue" or "the patch is complex, can't you write smaller patch or try to fix it in a different way"? If Martin doesn't understand the patch, who will understand it? :-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
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 very same VCS-but-different-branch - these are all minor details, which may affect the efficiency of producing and technically integrating the patch. It doesn't help to the least in speeding up reviews of the patch, or reduces the amount of work necessary to do a review.
This is true...
Actually, I'd like such a branch, too, where I could move much quicker and in particular with the backing of a VCS to port Python to MS Windows CE. Currently, I'm tempted to pull the code into a private repository, which causes problems when I want to push it back upstream.
[I guess you aren't happy with the DVCS systems, such as bazaar, which supposedly work perfect in exactly this case. I won't blame you for that, but still, consider trying out one of them for this project]
I tried bazaar, but it's just too much to tackle at once: porting to CE, learning BZR and maintaining a feature branch on trunk (though the latter should not be too difficult, according to BZR's reputation).
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. The only advantage I can see is that it simplifies repeated merging of the trunk into your branch.
Actually, now that I think about it, I must admit that it doesn't really matter to me whether I use a local mirror or work on a remote branch. The problem is still splitting up the whole port into pieces that can be digested (read: reviewed) at a time. Since I'm confident with the use of SVN, I'll for now stay with it and a local mirror, but any single change that can be submitted will be submitted, hopefully to have something working here soon. Cheers! Uli
-----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. The only advantage I can see is that it simplifies repeated merging of the trunk into your branch.
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. Not the official branches, but a little sandbox for yourself. I don't know if anybody's actually doing this. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV+xoXEjvBPtnXfVAQKhkwP+JgSPtX5CPSNYr9O15ISr1BB8d/fLYmhN SvJlMaSEADZeaetIaiFfbTBA0YQJHiGrQW/KIHshaJEOAyRrghuCYk0OupMw76H9 MSnsEQSEClOicbRKsZN3HuyTuO6QQq7RDg5nfGWX1yE6oUjlhpaofsz6dpSIPnwE jAYncLW4x0c= =INSu -----END PGP SIGNATURE-----
Barry Warsaw <barry <at> 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-side support (a script or something) to allow people to create separate repos or branches.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 3, 2009, at 1:51 PM, Antoine Pitrou wrote:
Barry Warsaw <barry <at> 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-side support (a script or something) to allow people to create separate repos or branches.
That /should/ be fairly easy to do I think. There's a script that Martin runs to give new people svn write access. At Pycon I hacked that to basically write out the ~bzr/.ssh/authorized_keys file. We'd have to set up a ~hg user and then hack the script once more. I don't have time to do that right now unfortunately, but maybe one of the pydotorg'ers could give it a shot. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV+0hXEjvBPtnXfVAQLSOQP/YJXdOU5QbcHLaSbkXxx5MjmwruqNSniD t/cbLbqQ6NgJYlskqqpWbvmBsZmN040KUdj4DI9nyymHAwB4LzFnc1rbErf4RCHd daopYPazwlS8Dv2r2ryjzdhrGDKlnYCbwUIb0f/JDvVZChCtcaN3m+lGWS7EnhD2 hFTHCo+0f6M= =v98I -----END PGP SIGNATURE-----
On Sat, Jan 3, 2009 at 10:42, Barry Warsaw <barry@python.org> 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 would still need to go through the tracker for all changes. The only advantage I can see is that it simplifies repeated merging of the trunk into your branch.
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. Not the official branches, but a little sandbox for yourself. I don't know if anybody's actually doing this.
I have been using bzr for all of my importlib work. It's worked out well sans the problem that SOMEONE <cough>Barry</cough> has not upgraded the bzr installation to support the newest wire protocol. -Brett
I have been using bzr for all of my importlib work. It's worked out well sans the problem that SOMEONE <cough>Barry</cough> 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 for Debian, so that even their backports infrastructure doesn't provide recent binaries). I'm fairly opposed to installing non-vendor packages on www.python.org, as those typically don't see any maintenance, and often break as the regular packages get upgraded. 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. Unfortunately, the current Debian release is stuck in political debates, so that we still can't use subversion 1.5 on the server. Regards, Martin
On Sat, Jan 3, 2009 at 14:17, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I have been using bzr for all of my importlib work. It's worked out well sans the problem that SOMEONE <cough>Barry</cough> 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 for Debian, so that even their backports infrastructure doesn't provide recent binaries). I'm fairly opposed to installing non-vendor packages on www.python.org, as those typically don't see any maintenance, and often break as the regular packages get upgraded.
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 maintain the installation of the DVCS software? I would be willing to do this if/when the replacement for svn is chosen.
Unfortunately, the current Debian release is stuck in political debates, so that we still can't use subversion 1.5 on the server.
This is why depending wholly on Debian for everything can be annoying. I understand the policy and support it overall, but in the case of something like a DVCS that doesn't have ridiculous dependencies like svn and someone explicitly taking the lead on the specific installation it would seem like an exception could potentially be made. -Brett
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 maintain the installation of the DVCS software? I would be willing to do this if/when the replacement for svn is chosen.
Now we need to separate between server side and client side; for each side, there should be a minimum required version (which might be different). If Debian stable doesn't include the minimum required client version, I will be opposed to switching to the DVCS. If it doesn't include the minimum required server version, I could live with somebody maintaining a manual installation (which then hopefully can be replaced with an official package on the next upgrade).
This is why depending wholly on Debian for everything can be annoying. I understand the policy and support it overall, but in the case of something like a DVCS that doesn't have ridiculous dependencies like svn and someone explicitly taking the lead on the specific installation it would seem like an exception could potentially be made.
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 for the cases where we gave in: shared libraries were missing after the upgrade (for Zope), the software wasn't available anymore after the upgrade (in case of manually-install Python pacakges), and so on. Very few people have actually helped in fixing these problems (applause to AMK for being very helpful with the most recent incidents). I'd rather have the users annoyed than finding out that the custom setup opened an entrance for hackers. Regards, Martin
-----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 problems on upgrade for the cases where we gave in: shared libraries were missing after the upgrade (for Zope), the software wasn't available anymore after the upgrade (in case of manually-install Python pacakges), and so on. Very few people have actually helped in fixing these problems (applause to AMK for being very helpful with the most recent incidents).
I'd rather have the users annoyed than finding out that the custom setup opened an entrance for hackers.
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 something different, but still. If you can't even upgrade svn to 1.5 on Debian stable, then I think you'll find it impossible to switch to any modern DVCS. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV/s0HEjvBPtnXfVAQLkXQQAhuWFDoOUuA44JFtiTYGXJE1r3khAlUyL jo8kLDPRBUG4X9yFmsLdd1dqYSHjTJTin1aHLtfN804pKhaCQRwoWCGl9fi5quks Y39axH0L0FjDhteSVFiDYefgALJR9OELyrrxCpB5EJtxPE/cxyuQzOSeEts/QBzi ViW3h5OidGg= =YwjS -----END PGP SIGNATURE-----
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 something different, but still. If you can't even upgrade svn to 1.5 on Debian stable, then I think you'll find it impossible to switch to any modern DVCS.
Maybe. Again, we should separate between client and server. The server we can control, and adjust as needed. The clients we can't (heck, we even support Windows :-) If "switching to a modern DVCS" means that users now need to start compiling their VCS before they can check out Python, I don't think we should switch to a modern DVCS. Such a system must be mature, and if it isn't included in Debian stable, it can't be mature (and free software). In the specific case, if a decision is made to switch to bazaar, and bzr 1.5 is recent enough, then I'd be happy to upgrade to testing (although 1.5 is also available from backports, and already installed; stable has *bzr 0.11*). Since lenny was frozen, bzr managed to release 5 minor versions (so it is 1.10 now); this makes me very worried whether this software is mature. IOW, Python shouldn't require a VCS that is not even a year old (a year ago, bzr 1.1 was released). Regards, Martin
-----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. Yes I know we've talked about that before and yes I know it would not be easy to switch to something different, but still. If you can't even upgrade svn to 1.5 on Debian stable, then I think you'll find it impossible to switch to any modern DVCS.
Maybe. Again, we should separate between client and server. The server we can control, and adjust as needed. The clients we can't (heck, we even support Windows :-)
Ouch. :)
If "switching to a modern DVCS" means that users now need to start compiling their VCS before they can check out Python, I don't think we should switch to a modern DVCS. Such a system must be mature, and if it isn't included in Debian stable, it can't be mature (and free software).
Well, I'm not sure I agree with that definition, but aside from that, I can tell you that for Bazaar, our users would have access to installers for the major OSes: http://bazaar-vcs.org/Download
In the specific case, if a decision is made to switch to bazaar, and bzr 1.5 is recent enough, then I'd be happy to upgrade to testing (although 1.5 is also available from backports, and already installed; stable has *bzr 0.11*). Since lenny was frozen, bzr managed to release 5 minor versions (so it is 1.10 now); this makes me very worried whether this software is mature.
IOW, Python shouldn't require a VCS that is not even a year old (a year ago, bzr 1.1 was released).
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? - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV/0v3EjvBPtnXfVAQJCUAQAqecbBtn5NnadHTl1CaHAwfA9ku51StNS k6YD2q39IokqwtjjJpiNTlPRseh8LuQVzG+Dt8fp0PndkTxS4SvbGEY1iRK11XEg wmLthKbxylBe6yuaGW4RcsmgaOMiEnr22QvY639I3yVJPVzI/0rIpak8BDod6EaT 9wGKe6xxQXg= =OUqf -----END PGP SIGNATURE-----
Barry Warsaw <barry <at> 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/trunk/ Regards Antoine.
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 the experience with any of them to be able to tell whether they are good enough. A year ago, the revision numbers were bzr 1.0 git 1.5.4 mercurial 0.9.5 Again, I don't know these packages well enough to understand what these numbers mean. I know for bzr that apparently bzr 1.0 is considered unsuitable for anything, so this would be ruled out. For git, 1.5.4 vs. 1.5.6 doesn't look too frightening, so the software appears to be in good shape. For Mercurial, the 1.0 release was made in March 2008, which might meet the "one year" criteria before this discussion is over. I know that when switching to Subversion was discussed, there was opposition on grounds of subversion still being too young, and indeed, it took more than a year from the start of the discussion until the switch was made. I do think Subversion was mature since 1.0, which was released in Feb 2004; PEP 347 was written in August 2005; the switchover happened in Oct 2005. So I think I will be fine if the software that I use has been mature for a year. From what I've heard, bazaar might not qualify (apparently, there were recent protocol changes); it seems that git would qualify. Whether mercurial is mature, and for how long it had been, I don't know. Regards, Martin
On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" <martin@v.loewis.de> 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. This would mean
bzr 1.5 git 1.5.6 mercurial 1.0.1
I don't have the experience with any of them to be able to tell whether they are good enough.
A year ago, the revision numbers were
bzr 1.0 git 1.5.4 mercurial 0.9.5
Again, I don't know these packages well enough to understand what these numbers mean. I know for bzr that apparently bzr 1.0 is considered unsuitable for anything, so this would be ruled out.
For git, 1.5.4 vs. 1.5.6 doesn't look too frightening, so the software appears to be in good shape. For Mercurial, the 1.0 release was made in March 2008, which might meet the "one year" criteria before this discussion is over.
I know that when switching to Subversion was discussed, there was opposition on grounds of subversion still being too young, and indeed, it took more than a year from the start of the discussion until the switch was made. I do think Subversion was mature since 1.0, which was released in Feb 2004; PEP 347 was written in August 2005; the switchover happened in Oct 2005.
So I think I will be fine if the software that I use has been mature for a year. From what I've heard, bazaar might not qualify (apparently, there were recent protocol changes); it seems that git would qualify. Whether mercurial is mature, and for how long it had been, I don't know.
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 monthly releases, so it has nothing to do with stability and more with their timed release schedule. 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. -Brett
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 monthly releases, so it has nothing to do with stability and more with their timed release schedule.
Ok: so what *is* the minimum required version, and why is the 1.5 version installed on code.python.org not good enough (as you complained about it)? Every time this comes up, I say "we can provide version A", and then somebody comes along saying "this is really bad, can't you provide version A+X?". This was the case always with bzr: first, 0.11 was not good enough, then 1.0, now 1.5. I wonder that if I install 1.10, whether that might not be good enough anymore 6 months after it got installed. Please understand that I don't know bazaar at all, so I have to trust the claims that any past version that was ever in use is so bad that it absolutely must be replaced.
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 how much one can go back without hitting a serious bug (e.g. one that might break the repository). Regards, Martin
Martin v. Löwis <martin <at> 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 how much one can go back without hitting a serious bug (e.g. one that might break the repository).
History of the release notes can be read here: http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew
From a quick look (and assuming everything is here), there hasn't been any repository corruption bug since 0.9.5, although a couple of crashes are mentioned.
Regards Antoine.
On Sat, Jan 3, 2009 at 16:39, "Martin v. Löwis" <martin@v.loewis.de> 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 being used. As for the version number, the team does monthly releases, so it has nothing to do with stability and more with their timed release schedule.
Ok: so what *is* the minimum required version, and why is the 1.5 version installed on code.python.org not good enough (as you complained about it)?
Not sure what the minimum is (Barry would know better than me), but my complaint is purely speed-related. -Brett
On Sun, Jan 4, 2009 at 9:28 AM, Brett Cannon <brett@python.org> wrote:
On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" <martin@v.loewis.de> 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. This would mean
bzr 1.5 git 1.5.6 mercurial 1.0.1
I don't have the experience with any of them to be able to tell whether they are good enough.
A year ago, the revision numbers were
bzr 1.0 git 1.5.4 mercurial 0.9.5
Again, I don't know these packages well enough to understand what these numbers mean. I know for bzr that apparently bzr 1.0 is considered unsuitable for anything, so this would be ruled out.
For git, 1.5.4 vs. 1.5.6 doesn't look too frightening, so the software appears to be in good shape. For Mercurial, the 1.0 release was made in March 2008, which might meet the "one year" criteria before this discussion is over.
I know that when switching to Subversion was discussed, there was opposition on grounds of subversion still being too young, and indeed, it took more than a year from the start of the discussion until the switch was made. I do think Subversion was mature since 1.0, which was released in Feb 2004; PEP 347 was written in August 2005; the switchover happened in Oct 2005.
So I think I will be fine if the software that I use has been mature for a year. From what I've heard, bazaar might not qualify (apparently, there were recent protocol changes); it seems that git would qualify. Whether mercurial is mature, and for how long it had been, I don't know.
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.
It is not true in my experience: it is backward compatible, yes, in the sense that you can often manage to get out of the situation, but with some extra work. I would consider myself a relatively knowledgeable bzr user (I have been using it for more than 2 years now for almost all my projects, before switching to git), and I had several times some problems with it. The ML occasionally also have quite a few people having problems. David
2009/1/4 Brett Cannon <brett@python.org>:
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 monthly releases, so it has nothing to do with stability and more with their timed release schedule.
As far as I am aware (and it's not based on much practical experience, so I could be wrong) the big issue with older Bazaar formats is that they are substantially slower. And there's some sort of interoperability constraint that I don't understand, which means that, although newer clients can read from older servers, the fact that the server uses an older format means that the slowness affects the client (it may be that it's possible to get around this with some level of juggling at the client). It would be very useful to have a good statement of the impact of different client/server versions.
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.
According to Mercurial compatibility rules, - New Mercurial should always be able to read old Mercurial repositories - Old Mercurial should always be able to pull from new Mercurial servers - Old Mercurial should break with a meaningful error message if it can't read a new Mercurial repository which basically means, the server version used will not affect the client and you will always be able to upgrade the server version without pain (point 2, "pull", is about client/server interaction). The last point states that you can even *down*grade the server with minimal pain (for *real* conservatives :-)) In practical terms Mercurial is 100% compatible back to at least June 2007 (version 0.9.4, the earliest documented at http://www.selenic.com/mercurial/wiki/index.cgi/WhatsNew). Paul.
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 doesn't mean that. All of the DVCS contenders have Windows and Mac OS installers (usually from 3rd parties, but working closely with the core). For *nix users, does anybody really use a vanilla Debian stable for a development workstation? Everybody else has reasonably fresh versions available via the standard package manager, even Debian Lenny.
I don't think we should switch to a modern DVCS. Such a system must be mature, and if it isn't included in Debian stable, it can't be mature (and free software).
The versions in Debian stable were all usable for their time, but this is a rapidly developing field, even when, like Subversion, your goal is to refactor software designed in the early 1990s! "It's in Debian stable" is an excessively strict standard for the client's version.
In the specific case, if a decision is made to switch to bazaar, and bzr 1.5 is recent enough, then I'd be happy to upgrade to testing (although 1.5 is also available from backports, and already installed; stable has *bzr 0.11*). Since lenny was frozen, bzr managed to release 5 minor versions (so it is 1.10 now); this makes me very worried whether this software is mature.
The bzr team is experimenting with a time-based release process; the rate at which minor versions appear should not worry you. More important is the count of new repository formats. There are about 5 currently in common use. Great efforts are made to keep them interoperable, though some are not. Python should avoid use of those for the near future but I don't think it should be considered a showstopper.
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 Mac OS installers (usually from 3rd parties, but working closely with the core).
I'll notice that git-win32 is totally bad for any serious Windows developers. At least 4 months ago which is the last time I tried it. You'll have a very hard time persauding the experienced Windows developers in this list that git-win32 is a good thing to use. -- Giovanni Bajo Develer S.r.l. http://www.develer.com
On Fri, Jan 9, 2009 at 1:48 AM, Giovanni Bajo <rasky@develer.com> 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 doesn't mean that. All of the DVCS contenders have Windows and Mac OS installers (usually from 3rd parties, but working closely with the core).
I'll notice that git-win32 is totally bad for any serious Windows developers. At least 4 months ago which is the last time I tried it. You'll have a very hard time persauding the experienced Windows developers in this list that git-win32 is a good thing to use.
Do you mean this one: http://code.google.com/p/msysgit/ or is git-win32 something else? Ondrej
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 for the cases where we gave in: shared libraries were missing after the upgrade (for Zope), the software wasn't available anymore after the upgrade (in case of manually-install Python pacakges), and so on. Very few people have actually helped in fixing these problems (applause to AMK for being very helpful with the most recent incidents).
I'd rather have the users annoyed than finding out that the custom setup opened an entrance for hackers.
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 something different, but still. If you can't even upgrade svn to 1.5 on Debian stable, then I think you'll find it impossible to switch to any modern DVCS.
I appreciate Martin's conservatism, especially since he usually ends up being the one who has to fill in the gaps when things fall though the cracks. I would never suggest that he went against his instincts about likely pitfalls in installation of non-standard software. I suspect this was the PyCon web server's downfall: a dog's breakfast disguised as a unified installation. Is it maybe time we thought about hiring a part-time sysadmin to take care of the cruddy stuff that soaks up time without increasing productivity? We have the finds, and if they run out the I'd rather spend my time raising more funds that administering systems ... there are many people who are better at that than I was in my prime! Hey, isn't Ubuntu Debian-based? ... Don't we know people who work for the vendor? ... Maybe they could offer some support if we switched? ... regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
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. You're still going to need to go with a "don't think about fixing what ain't broke, and even if it's just kinda broke, Just Say No to that upgrade dope" policy. No, something has to be done about the "no upgrades" policy, or it's not worth switching from Debian stable.
On Sun, Jan 04, 2009, 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 former NetBSD developers is grouching about upgrade hell, I don't see any real benefits to be gained. You're still going to need to go with a "don't think about fixing what ain't broke, and even if it's just kinda broke, Just Say No to that upgrade dope" policy.
What kind of upgrade hell are you talking about? I have used several different Linux distributions, Windows, and OS X, and I have to say that upgrading Ubuntu has been by far the easist and least painful of them all. Because I was lazy, last weekend I finally did a two-stage upgrade from 7.10 to 8.04 and then 8.10, with zero noticeable problems. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "roses are reddish, violets are bluish, Chanukah is 8 days, don't you wish you were Jewish?"
Aahz writes:
all. Because I was lazy, last weekend I finally did a two-stage upgrade from 7.10 to 8.04 and then 8.10, with zero noticeable problems.
The scary one is two independent reports of fstab corruption in the 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from CD, mounting the partition, and editing fstab: the editor saves but the fstab returns to the original corrupt state upon reboot. Several reports of inability to use formerly working Japanese input methods. Several reports of formerly working xorg.conf suddenly reverting to VESA 1024x768x8 (or worse). I don't use Ubuntu so this is all hearsay, but I do trust the ex-NetBSD dev to be reporting accurately. He's only having problems with his custom X11 keymap getting trashed, and something else relatively minor with Xorg. And for that ML this is huge; I don't recall so many screams on a commercial vendor upgrade since Red Hat went from HJ Liu libc to glibc 2.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 4, 2009, at 11:26 AM, Stephen J. Turnbull wrote:
Aahz writes:
all. Because I was lazy, last weekend I finally did a two-stage upgrade from 7.10 to 8.04 and then 8.10, with zero noticeable problems.
The scary one is two independent reports of fstab corruption in the 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from CD, mounting the partition, and editing fstab: the editor saves but the fstab returns to the original corrupt state upon reboot.
Several reports of inability to use formerly working Japanese input methods. Several reports of formerly working xorg.conf suddenly reverting to VESA 1024x768x8 (or worse).
Just as a data point, we routinely upgrade our Ubuntu desktop machines as soon as the next version goes beta, exactly so we can help smooth out any hitches long before our users do. Some of us tend to be conservative, some radical, but we have a fairly wide range of systems and close interaction with our distro team. At any one time I have four or more Ubuntu boxes (servers, laptops, VMs, desktops) and I tend to upgrade them one at a time. For me, servers have been the easiest to upgrade. I've never had a problem with the OS specifically. I have had problems with certain applications (e.g. Moin) where it's usually a matter of sussing out all the new configuration changes, but I'm not sure you can avoid that. On the desktops, IME the most troublesome part is always X, mostly because it's a nightmare in its own right :) but also because my proprietary hardware drivers lag behind. I've had one or two problems with wireless. I've never had a problem with some of the crazier things I try, like encrypted file systems. Remember too, these are all beta upgrades. I'm not shy about contacting our excellent support team about these problems. I usually hold back at least one VM to upgrade to final, and that's always gone easier than any other OS, reflecting Aahz's experience. I don't doubt that people have problems upgrading, in fact for anything as complex as an operating system, it would be impossible to avoid. I'm biased of course, but I have to say our distro team does an excellent job here. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWDnlnEjvBPtnXfVAQLIbwP+MiYoO0eBm77dc/nfyjHp593C1+CyprCQ 9TMNI5O5sD5VdiXWuhO5XSn6hvTf7tgZ4pAAQgYhcgapEoG3rYCjQ5RGs4jSdQTs SxLptzj4U2gODRFMNCOBspQf97krSGxp1UKFzRujUvPJP3NQw7Xp90FkT/rjLd3N iCAlNWtp2Hs= =FzKC -----END PGP SIGNATURE-----
Barry Warsaw writes:
The scary one is two independent reports of fstab corruption in the 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from CD, mounting the partition, and editing fstab: the editor saves but the fstab returns to the original corrupt state upon reboot.
For me, servers have been the easiest to upgrade. I've never had a problem with the OS specifically. I have had problems with certain applications [...]. On the desktops, IME the most troublesome part is always X, [...].
This certainly conforms to what I've seen on that LUG list. Since nobody on that list is running Ubuntu server, the "scary one" (quoted above) can probably be discounted, too. That looks like some user-friendliness run amok.
Stephen J. Turnbull wrote:
And for that ML this is huge; I don't recall so many screams on a commercial vendor upgrade since Red Hat went from HJ Liu libc to glibc 2.
I've had problems with Kubuntu's graphical updater crashing, but never anything a "sudo apt-get dist-upgrade" didn't fix. Although I'm still on Kubuntu 8.04 - KDE 4 isn't far enough along for me to consider switching to 8.10, so I probably won't be upgrading again until the next LTS release. (Also, if the infrastructure committee *do* consider using Ubuntu for any of the python.org servers, then the LTS releases are the ones that should probably be considered, rather than the 6-monthly ones). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Stephen J. Turnbull wrote:
Aahz writes:
all. Because I was lazy, last weekend I finally did a two-stage upgrade from 7.10 to 8.04 and then 8.10, with zero noticeable problems.
The scary one is two independent reports of fstab corruption in the 8.04 to 8.10 upgrade. It is claimed to be unfixable by booting from CD, mounting the partition, and editing fstab: the editor saves but the fstab returns to the original corrupt state upon reboot.
Several reports of inability to use formerly working Japanese input methods. Several reports of formerly working xorg.conf suddenly reverting to VESA 1024x768x8 (or worse).
You can add my name to those reporting inexplicable reversion of video settings. I'm getting tired of it seeing a 640 x 480 screen.
I don't use Ubuntu so this is all hearsay, but I do trust the ex-NetBSD dev to be reporting accurately. He's only having problems with his custom X11 keymap getting trashed, and something else relatively minor with Xorg.
And for that ML this is huge; I don't recall so many screams on a commercial vendor upgrade since Red Hat went from HJ Liu libc to glibc 2.
Ubuntu is a victim of its own success. They now have to deal with the same diversity of hardware environments as Windows. I hope that Canonical will find a way to stabilize things. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On Sun, Jan 4, 2009 at 8:51 PM, Steve Holden <steve@holdenweb.com> wrote:
Ubuntu is a victim of its own success. They now have to deal with the same diversity of hardware environments as Windows. I hope that Canonical will find a way to stabilize things.
I think it's actually worse. Microsoft can always (and, in my experience, often does) restrict their support to hardware sets approved for "Windows ver. N". Custom-built or upgraded ("tampered-with") boxes often get worse (or no) support than OEM boxes. Linux distributions, on the other hand, are expected to provide support for any hardware. In this respect, since Ubuntu has a larger user base, and therefore a larger range of hardware sets, yes, their job is difficult, but I'm not sure this is a victimization, rather more of an inherent issue exacerbated by its success. Either way, it does kind of suck. On Sun, Jan 4, 2009 at 11:26 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
This certainly conforms to what I've seen on that LUG list. Since nobody on that list is running Ubuntu server, the "scary one" (quoted above) can probably be discounted, too. That looks like some user-friendliness run amok.
True, most of the upgrade problems deal with packages that aren't in the server install. This should be an easy one, but now I'd ask, why not use Debian instead? -- Cheers, Leif
Leif Walsh writes:
True, most of the upgrade problems deal with packages that aren't in the server install. This should be an easy one, but now I'd ask, why not use Debian instead?
You mean, "why not stick with Debian instead?"<wink> The reason is that Debian stable lags the real world dramatically. It's an extremely stable platform (in all meanings of "stable"), but quite restrictive. Ubuntu's LTS versions are much more up-to-date. Debian "sid" is out, obviously, and Debian "testing" has the problem that it is a fairly fast-moving target. Not so much as "sid", but if I were the sysadmin, I would not be happy with installing "testing" as of some date, knowing that many components would not correspond to that tag within hours, at most days. It's a hard question IMO.
I missed the beginning here; oh well. On Sun, Jan 4, 2009 at 9:51 AM, Aahz <aahz@pythoncraft.com> wrote:
On Sun, Jan 04, 2009, 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 former NetBSD developers is grouching about upgrade hell, I don't see any real benefits to be gained. You're still going to need to go with a "don't think about fixing what ain't broke, and even if it's just kinda broke, Just Say No to that upgrade dope" policy.
In my experience, Ubuntu tends to stray away from the Way Things Are Traditionally Done, and this can be problematic, sometimes. Because they change things so drastically, they can do some pretty neat stuff, but if I decide I want to tweak something on my own, I usually find that they haven't provided a mechanism for changing something they've already changed (or at least not for a few releases). So, I blunder on ahead and mess with it, and when it comes time to upgrade, their scripts are expecting it to be the way they left it, but obviously it isn't that way, so it breaks horribly. Of course, if you aren't trying to mess with all manner of weird things (I think my latest trouble came from messing with pam and shared memory to get my audio software to run smoothly), it should be perfectly stable and upgradable. -- Cheers, Leif
-----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 former NetBSD developers is grouching about upgrade hell, I don't see any real benefits to be gained. You're still going to need to go with a "don't think about fixing what ain't broke, and even if it's just kinda broke, Just Say No to that upgrade dope" policy.
No, something has to be done about the "no upgrades" policy, or it's not worth switching from Debian stable.
One interesting thing about Ubuntu is that you can hook into the Personal Package Archives feature on Launchpad, so if you want to track newer versions of individual packages than either the distro or backports provides, you can do so using the standard package manager, with dependency tracking, etc. It's up to the PPA owner to make sure new releases are available to address things like security concerns and such. The bzr team is pretty good about that (I regularly run bzr from a PPA on my Ubuntu machines). B. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWDt2HEjvBPtnXfVAQKjGwP8DHd+vp7ELDEtMNBZxNIktPJXAbYOtnP2 uSvueN3TIoguTtCLTMKuObhHems9bttIodroWxLQ4/8hGEAI3yPS7FTadxdO00hK FjJQffKaEaGOQ/bKdr/nTxCvArfzhYCSwSfYMFsq/85roM3UpsHirT9oyWjWyJIw p5nOczWAi70= =opqm -----END PGP SIGNATURE-----
On Sat, Jan 3, 2009 at 14:47, "Martin v. Löwis" <martin@v.loewis.de> 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 side.
Even if someone like me or Barry volunteers to maintain the installation of the DVCS software? I would be willing to do this if/when the replacement for svn is chosen.
Now we need to separate between server side and client side; for each side, there should be a minimum required version (which might be different).
If Debian stable doesn't include the minimum required client version, I will be opposed to switching to the DVCS.
OK.
If it doesn't include the minimum required server version, I could live with somebody maintaining a manual installation (which then hopefully can be replaced with an official package on the next upgrade).
That's what I am talking about.
This is why depending wholly on Debian for everything can be annoying. I understand the policy and support it overall, but in the case of something like a DVCS that doesn't have ridiculous dependencies like svn and someone explicitly taking the lead on the specific installation it would seem like an exception could potentially be made.
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 for the cases where we gave in: shared libraries were missing after the upgrade (for Zope), the software wasn't available anymore after the upgrade (in case of manually-install Python pacakges), and so on. Very few people have actually helped in fixing these problems (applause to AMK for being very helpful with the most recent incidents).
Right, which is why I wouldn't want to do this unless the installation was owned by someone who was definitely going to be around for a LONG time.
I'd rather have the users annoyed than finding out that the custom setup opened an entrance for hackers.
Right. Whomever stepped forward to maintain a custom install would need to really stay on top of things. -Brett
On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
There have been many problems on upgrade for the cases where we gave in: shared libraries were missing after the upgrade (for Zope), the software wasn't available anymore after the upgrade (in case of manually-install Python pacakges), and so on. Very few people have actually helped in fixing these problems
What's the preferred way of offering help with infrastructure problems, and to what extent, in your opinion, is the solution to have more hands on deck vs. farming out certain (groups of) services to different machines? -- Ivan Krstić <krstic@solarsail.hcs.harvard.edu> | http://radian.org
What's the preferred way of offering help with infrastructure problems, and to what extent, in your opinion, is the solution to have more hands on deck vs. farming out certain (groups of) services to different machines?
With the current installations, there aren't that many issues. The one service that could always use more people to help is the roundup installation; in many cases, this involves extending roundup (through the builtin extension mechanisms). Unfortunately, nearly everybody who ever offered to help with the roundup installation ran away after a month or so. We have most services centralized at xs4all, with a fairly clear separation between mail on the one side, and web on the other side. For the bug tracker, we use a service offered by Upfront Hosting. This takes care of hardware issues and software installation, but we still manage the tracker installation(s). We recently also had a shortage of people managing email; fortunately, new (active) volunteers were found. For the web content, there is currently nobody really in charge, it seems, which is usually not an issue (my impression is that Aahz and Skip try to see that important things get done). For the Wiki, there is an active group of despammers. The job board has active maintainers again as well. The various other services don't need steady attention. In particular wrt. software installation, it all works fine - IMO also due to the policy that we use vendor packages if at all possible. Regards, Martin P.S. I might have left out important activities. Please do let me know in private which these are - I might honestly not know, or forgotten how much day-to-day work they actually cost.
On Sat, Jan 3, 2009 at 15:21, Ivan Krstić <krstic@solarsail.hcs.harvard.edu> wrote:
On Jan 3, 2009, at 5:47 PM, Martin v. Löwis wrote:
There have been many problems on upgrade for the cases where we gave in: shared libraries were missing after the upgrade (for Zope), the software wasn't available anymore after the upgrade (in case of manually-install Python pacakges), and so on. Very few people have actually helped in fixing these problems
What's the preferred way of offering help with infrastructure problems, and to what extent, in your opinion, is the solution to have more hands on deck vs. farming out certain (groups of) services to different machines?
For volunteering with infrastructure stuff, you can just speak up on the proper mailing list: either pydotorg or tracker-discuss (the former is a catch-all while the latter is specifically the issue tracker). And for people who are PSF members there is an infrastructure committee that I chair which handles the big-picture issues (e.g. choosing the issue tracker, server purchases, etc.). -Brett
Brett Cannon wrote: [...]
I have been using bzr for all of my importlib work. It's worked out well sans the problem that SOMEONE <cough>Barry</cough> 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 entry ... i-can-say-this-now-the-entry-is-published-ly y'rs - steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
-----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 <cough>Barry</cough> 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 entry ...
Ouch. That's the thanks I get. And you didn't even post a url to help increase my net.fame.
i-can-say-this-now-the-entry-is-published-ly y'rs - steve
B. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWDr/XEjvBPtnXfVAQJu0gQAqBnayG5cwKJ7N7FRFRoaaeyT38xKjnZ0 Y1l8qKWx1ErN92rKPfeVf28XAqxaedE9rNUOPd2PVOEjU61Pbf7mHEY7yjFk7jZT nuHoAuvTUPh8Ip5nkVmfh4LzpX6Z/3uuP5+aMz1QI0nREXok9pPTtKsktZo4UiLU CJrk/Gzpl+g= =Y8O9 -----END PGP SIGNATURE-----
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 <cough>Barry</cough> 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 entry ...
Ouch. That's the thanks I get. And you didn't even post a url to help increase my net.fame.
http://onyourdesktop.blogspot.com/2008/12/barry-warsaw.html always-willing-to-oblige-ly yr's - steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
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 nobody knows the whole Python project, it's too huge for a single brain ;-)
I like them, too - that's why I'm generally not opposed to handing out such privileges fairly generously. In our experience, you don't need to enforce such a restriction technically - the social enforcement (you lose access if you are changing things you were not supposed to change) is sufficient. In fact, the Python repository also hosts Stackless Python, so technically, Python committers can commit to stackless also, and vice versa - but nobody does, of course. There are many other people who commit only to specific files, or only specific kinds of changes; see Misc/developers.txt for a (possibly incomplete) list. Regards, Martin
On Sat, Jan 3, 2009 at 5:17 PM, "Martin v. Löwis" <martin@v.loewis.de> 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 commit, but only on distutils. I like such permission because nobody knows the whole Python project, it's too huge for a single brain ;-)
I like them, too - that's why I'm generally not opposed to handing out such privileges fairly generously. In our experience, you don't need to enforce such a restriction technically - the social enforcement (you lose access if you are changing things you were not supposed to change) is sufficient.
This is a great model, as long as the concerned people focus in specific topics/areas. I think it is harder to apply for people that does fuzz testing on the code base : the core is impacted most of the time. There's another concern with that model, and I am wondering about it for the next series of patches I am working on in distutils. 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 ? -> 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 2/ slows things down, make the feature/change unavailable until Georg (or others) had the time to review it Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
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 confident that the documentation actually builds, feel free to commit it without pre-review. I recommend that you build the documentation at least once; I personally often commit documentation patches without testing first that they build when I'm confident about the markup I use.
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), nearly all documentation changes are improvements. Regards, Martin
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 pre-review ?
If you are confident that the documentation actually builds, feel free to commit it without pre-review. I recommend that you build the documentation at least once; I personally often commit documentation patches without testing first that they build when I'm confident about the markup I use.
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), nearly all documentation changes are improvements.
I agree with Martin here - breaking the documentation build isn't good, but other than that most doc changes are going to be OK. And as for doing your own doc build, these days that should be as simple as changing to the Docs directory and typing "make html" (stale code in the Docs/tools directory can sometimes be a problem, but if you haven't built the docs before then that shouldn't come up). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Sat, Jan 3, 2009 at 10:21 PM, Nick Coghlan <ncoghlan@gmail.com> 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), nearly all documentation changes are improvements.
I agree with Martin here - breaking the documentation build isn't good, but other than that most doc changes are going to be OK.
Ok, I'll stick with that process,
And as for doing your own doc build, these days that should be as simple as changing to the Docs directory and typing "make html" (stale code in the Docs/tools directory can sometimes be a problem, but if you haven't built the docs before then that shouldn't come up).
Running "make html" is part of my process when I change Doc, but I didn't know about the stale code issue, thanks for the tip Out of curiosity : is there any mechanism in the post-commit that checks if "make html" doesn't spit any error ? Cheers, Tarek
On Sat, Jan 3, 2009 at 3:39 PM, Tarek Ziadé <ziade.tarek@gmail.com> 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, Benjamin
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 a pre-review ?
If you are confident that the documentation actually builds, feel free to commit it without pre-review. I recommend that you build the documentation at least once; I personally often commit documentation patches without testing first that they build when I'm confident about the markup I use.
FWIW, I review most doc patches as they come into the commits mailing list. Also, since the docs are built regularly, and problems are usually fixed very fast, I don't want anybody to hold back a patch because of docs only.
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), nearly all documentation changes are improvements.
Agreed. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
-----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).
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 nobody knows the whole Python project, it's too huge for a single brain ;-)
Well, except for Guido and Tim maybe :) Python does have finer grain permissions, but it's strictly by convention. We /could/ have technical means to control those permissions, but it's never been worth the effort before.
your main point is that using bugtracker for committing patches is very painful (I agree)
No, my point is that some patches stay too long in the tracker. GIT, Mercurial or anything else are a little bit better than the tracker (the patches can be synchronized with upstream), but the goal is to be part of the upstream code base.
A distributed VCS is useful to test huge changes. Performance improvment on integers (patches to optimize the multiplication, use base 2^30 instead of 2^15, etc.) would benefit from such tools, because cooperative work is easier.
A DVCS has lots and lots of benefits. One that I like a lot is that it will be much easier for people to maintain such bigger branches while still tracking changes to the trunk. And a DVCS like Bazaar supports bundles which are essentially super-patches that contain all the meta data that a real branch would have. So a bzr bundle would be a fine thing to attach to a tracker issue, and it would be much more alive than a plain old patch. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSV+wuXEjvBPtnXfVAQK/bQQAnZIjOCZAvRX/Jgzwn7Qkq5cqSnB/6qs2 gDls7tTlGJdtmYgSoZDVhosExaLA7AqvSMxsdTgEID4ejhh1TX42xzifeWyAhwrz WrK591SfoNXHG+YxhIRebt9wenGYzn3S/Qe5eJ0Jct7u0G6rDWK0X35OyZa+woC1 BNK6H0fTfUo= =mK3Y -----END PGP SIGNATURE-----
participants (24)
-
"Martin v. Löwis" -
Aahz -
Andrew Bennetts -
Antoine Pitrou -
Arfrever Frehtes Taifersar Arahesis -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
David Cournapeau -
Dirkjan Ochtman -
Georg Brandl -
Giovanni Bajo -
Ivan Krstić -
Jesse Noller -
Leif Walsh -
Nick Coghlan -
Ondrej Certik -
Paul Moore -
Raymond Hettinger -
Stephen J. Turnbull -
Steve Holden -
Tarek Ziadé -
Ulrich Eckhardt -
Victor Stinner