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/

Hi, Stephen J. Turnbull 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 Fri, Jan 2, 2009 at 18:53, Victor Stinner wrote:

Le Wednesday 31 December 2008 22:20:54, vous avez écrit :

...

When it comes to commit privs in general, I am of the school that they should be handed out carefully. I for one do not want to have to babysit other committers to make sure 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

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

David Cournapeau 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.

Brett Cannon wrote:

On Sat, Jan 3, 2009 at 00:50, "Martin v. Löwis" wrote:

...

...

A little offtopic: it seems to me it is a flaw of svn, that it encourages the model of two classes of developers, those with a commit access (first class) and those without it (second class). Victor -- 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/

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/

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.

-----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-----

...

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/

Georg Brandl writes:

It looks like it does, and that's a good thing (once in a while).

Hey, and we've even had a DVCS sub-thread in the process ;)

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/

Ulrich Eckhardt 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.

[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

David Cournapeau wrote:

On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" wrote:

...

[I don't want to get into another DVCS flamewar, but I just can't let this go uncommented :-]

I am sorry if that sounded like a flamewar, that was not my intention:

Oops - maybe the smiley was not 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

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

On Sat, Jan 3, 2009 at 11:47 AM, Georg Brandl wrote:

Martin v. Löwis schrieb:

...

...

I don't know about others, but downloading and applying a patch doesn't bother me (it's actually much quicker than doing a whole new SVN checkout).

Same here. In fact, when I had to backport patches 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

Ulrich Eckhardt 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.

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

-----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-----

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

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

Barry Warsaw 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.

On Sat, Jan 3, 2009 at 10:42, Barry Warsaw wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jan 3, 2009, at 11:36 AM, Martin v. Löwis wrote:

...

We can setup such a branch, unless you reconsider and try bazaar first. There wouldn't be any pushing it back upstream, though - you 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

On Sat, Jan 3, 2009 at 14:17, "Martin v. Löwis" wrote:

...

I have been using bzr for all of my importlib work. It's worked out well sans the problem that SOMEONE <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

-----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-----

-----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-----

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

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

On Sat, Jan 3, 2009 at 16:39, "Martin v. Löwis" wrote:

...

Bazaar has been backwards-compatible with everything from my understanding, so any changes they have made to the repository layout or network protocol they use should not be an issue regardless of what client or server versions are 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

2009/1/4 Brett Cannon :

Bazaar has been backwards-compatible with everything from my understanding, so any changes they have made to the repository layout or network protocol they use should not be an issue regardless of what client or server versions are being used. As for the version 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.

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

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/

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?"

-----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-----

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 ---------------------------------------------------------------

On Sun, Jan 4, 2009 at 8:51 PM, Steve Holden 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 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

I missed the beginning here; oh well. On Sun, Jan 4, 2009 at 9:51 AM, Aahz 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

On Sat, Jan 3, 2009 at 14:47, "Martin v. Löwis" wrote:

...

...

As a consequence, I would always request that whatever VCS Python uses: the version that is in the current Debian's "stable" distribution must be sufficient to use the VCS, and must in particular be sufficient on the server 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

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.

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/

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/

On Sat, Jan 3, 2009 at 5:17 PM, "Martin v. Löwis" wrote:

...

Yes, that's the problem. Is it not possible to have finer permission (instead of boolean permission: commit or not commit)? Eg. give commit access but only for a file or a directory? It looks like Tarek Ziade is now allowed to 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/

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 3:39 PM, Tarek Ziadé wrote:

Out of curiosity : is there any mechanism in the post-commit that checks if "make html" doesn't spit any error ?

Not automatically. However, Georg and I test it fairly often and fix markup errors if they're present. -- Regards, 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.