Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bytes for the command line, process arguments and environment variables
> I don't have new solutions, it's just an email to restart the discussion > about > bytes ;-) Martin also asked for a PEP to change the posix module API to > support bytes. And I repeat this request: we don't need new discussions; we need a draft specification. Restarting discussion will just cause it to go in circles over and over again, until everybody is bored and quits, so that some time later somebody can restart the discussion, to go in circles again. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sat, Jan 3, 2009 at 5:50 PM, "Martin v. Löwis" wrote: >> A little offtopic: it seems to me it is a flaw of svn, that it >> encourages the model of two classes of developers, those with a commit >> access (first class) and those without it (second class). Victor -- >> maybe you can try something 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
David Cournapeau gmail.com> writes: > > It does not make integration easier, but it certainly makes patch > management easier for the patch writer. There are other means to > manage patch on top of svn, but I find git-svn extremely useful. > Actually, I use git-svn on top of svn repositories for 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyOS_GetLastModificationTime
On Friday 02 January 2009 23:18:04 Martin v. Löwis wrote: > Correct me if I'm wrong: it seems that the function isn't called > anymore. So I propose to just remove it (and the file it lives > in). Filed as issue #4817, including patch. Uli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> > 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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Ulrich Eckhardt knuut.de> writes: > > saying "please merge r1234 from > foo into trunk" is much easier than downloading and applying a patch, which > doesn't even cover all possible changes that SVN does. I don't know about others, but downloading and applying a patch doesn't bother me (it's 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sun, Jan 4, 2009 at 1:21 AM, Antoine Pitrou wrote: > > You could clone one of the existing DCVS mirrors and open a branch on a public > hosting service (bitbucket.org, launchpad, etc.). The annoying thing, though, > is that it requires your co-workers to learn the DVCS in question. The 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
[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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Saturday 03 January 2009 17:21:16 Antoine Pitrou wrote:
> Ulrich Eckhardt knuut.de> writes:
> > saying "please merge r1234 from
> > foo into trunk" is much easier than downloading and applying a patch,
> > which doesn't even cover all possible changes that SVN does.
>
> I don't know about 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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Ulrich Eckhardt knuut.de> writes: > > 1. I think that a patch can not e.g. capture a moved, renamed or deleted > file. > Further, it can not handle e.g. things like the executable bit or similar > things that SVN otherwise does manage. That is what makes a patch only > partially suitable. You are right, I had forgotten about that. regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sun, Jan 4, 2009 at 1:46 AM, "Martin v. Löwis" wrote: > [I don't want to get into another DVCS flamewar, but I just > can't let this go uncommented :-] I am sorry if that sounded like a flamewar, that was not my intention: I just wanted to point out that there are solution that the op can 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sat, Jan 3, 2009 at 8:46 AM, "Martin v. Löwis" wrote: > [I don't want to get into another DVCS flamewar, but I just > can't let this go uncommented :-] >> (took me ~ 1 hour to get around >> without any previous encounter with git and I am no genius) > > I'm no genius, either, and I think that 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.html Ondrej ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Georg Brandl gmx.net> writes: > > It looks like it does, and that's a good thing (once in a while). Hey, and we've even had a DVCS sub-thread in the process ;) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 signature.asc Description: This is a digitally signed message part. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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-
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Barry Warsaw python.org> writes: > > Although it doesn't help Victor specifically, anyone with svn commit > privileges also has permission to push Bazaar (and I think Mercurial) > branches back to code.python.org. Actually the Mercurial repositories are read-only. We would need some server-side support (a script or something) to allow people to create separate repos or branches. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 3, 2009, at 1:51 PM, Antoine Pitrou wrote: Barry Warsaw python.org> writes: Although it doesn't help Victor specifically, anyone with svn commit privileges also has permission to push Bazaar (and I think Mercurial) branches back to code.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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Wrong buildbot page for 3.x-stable
Hello, it seems that both the following pages are identical, and are for release30-maint: http://www.python.org/dev/buildbot/3.0.stable/ http://www.python.org/dev/buildbot/3.x.stable/ Isn't the latter supposed to point to the py3k branch buildbots? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sat, Jan 3, 2009 at 10:21 PM, Nick Coghlan wrote: >> [cut] >> >>> 1/ is better for the flow, but the quality of the doc might suffer >>> from it if Georg (or others) doesn't have time to review it >> >> This is of little concern. As long as the documentation continues >> to build (into html), 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> Out of curiosity : is there any mechanism in the post-commit that > checks if "make html" > doesn't spit any error ? No, there is no such mechanism. There are daily builds which will report errors eventually. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 Barry has not upgraded the bzr installation to support the newest wire protocol. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] compiling python2.5 on linux under wine
hey, has anyone investigated compiling python2.5 using winegcc, under wine? i'm presently working my way through it, just for kicks, and was wondering if anyone would like to pitch in or stare at the mess under a microscope. it's not as crazed as it sounds. cross-compiling python2.5 for win32 with mingw32 is an absolute miserable bitch of a job that goes horribly wrong when you actually try to use the minimalist compiler to do any real work. so i figured that it would be easier to get python compiled using wine. i _have_ got some success - a python script and a python.exe.so (which is winegcc's friendly way of telling you you have something that stands a chance of working) as well as a libpython25.dll.so. what i _don't_ yet have is an _md5.dll (or should it be _md5.lib?) i.e. the standard modules are a bit... iffy. the _winreg.o is compiled; the _md5.o is compiled; the winreg.lib is not. whoops. plus, it's necessary to enable nt_dl.c which is in PC/ _not_ in Modules/. one of the key issues that's a bit of a bitch is that python is compiled up for win32 with a hard-coded pyconfig.h which someone went to a _lot_ of trouble to create by hand instead of using autoconf. oh - and it uses visualstudio so there's not even a Makefile. ignoring that for the time-being was what allowed me to get as far as actually having a python interpreter (with no c-based modules). so there's a whole _stack_ of stuff that needs dragging kicking and screaming into the 21st century. there _is_ a reason why i want to do this. actually, there's two. firstly, i sure as shit do _not_ want to buy, download, install _or_ run visual studio. i flat-out refuse to run an MS os and visual studio runs like a dog under wine. secondly, i want a python25.lib which i can use to cross-compile modules for poor windows users _despite_ sticking to my principles and keeping my integrity as a free software developer. thirdly i'd like to cross-compile pywebkitgtk for win32 fourthly i'd like to compile and link applications to the extremely successful and well wicked MSHTML.DLL... in the _wine_ project :) not the one in windows (!) i want to experiment with DOM model manipulation - from python - similar to the OLPC HulaHop project - _but_ i want to compile or cross-compile everything from linux, not windows (see 1 above) fifthly i'd like to see COM (DCOM) working and pywin32 compiled and useable under wine, even if it means having to get a license to use dcom98 and oleauth.lib and oleauth.h etc. and all the developer files needed to link DCOM applications under windows. actually what i'd _really_ like to see is FreeDCE's DCOM work actually damn well finished, it's only been eight years since wez committed the first versions of the IDL and header files, and it's only been over fifteen years since microsoft began its world domination using COM and DCOM. ... but that's another story :) so that's ... five reasons not two. if anyone would like to collaborate on a crazed project with someone who can't count, i'm happy to make available what i've got up to so far, on github.org. l. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sat, Jan 3, 2009 at 09:52, Georg Brandl wrote: > Steve Holden schrieb: > >> I think it was courageous of Brett to tackle this issue head-on as he >> did, and of Victor to respond so positively to the various comments that >> have been made on this thread. It would be a pity to lose a developer >> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> I have been using bzr for all of my importlib work. It's worked out > well sans the problem that SOMEONE Barry has not > upgraded the bzr installation to support the newest wire protocol. I'm probably to blame for this. Debian doesn't come with the latest bzr revision (bzr evolves way too fast 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sat, Jan 3, 2009 at 14:17, "Martin v. Löwis" wrote: >> I have been using bzr for all of my importlib work. It's worked out >> well sans the problem that SOMEONE Barry has not >> upgraded the bzr installation to support the newest wire protocol. > > I'm probably to blame for this. Debian doesn't 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
>> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ParseTuple question
On 2/01/2009 10:32 PM, Ulrich Eckhardt wrote: Hi! I'm looking at NullImporter_init in import.c and especially at the call to PyArg_ParseTuple there. What I'm wondering is what that call will do when I call the function with a Unicode object. Will it convert the Unicode to a char string first, will it return the Unicode object in a certain (default) encoding, will it fail? PyArg_ParseTuple will fail if a unicode object is passed where a 's' format string is specified. I'm working on the MS Windows CE port, and I don't have stat() there. Also, I don't have GetFileAttributesA(char const*) there, so I need a wchar_t (UTF-16) string anyway. What would be the best way to get one? On 'normal' windows you generally would need to use WideCharToMultiByte() to get a 'char *' version of your wchar string - but I expect you already know that, so I doubt I understand the question... Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Infra issues (was: Re: I would like an svn account)
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ć | http://radian.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
-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- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infra issues
> 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Barry Warsaw python.org> writes: > > Do any of the DVCS under consideration satisfy that requirement? Out of curiosity, I apt-get'ed Mercurial on a stable Debian (0.9.1-1+etch1) and I was able to clone the trunk mirror (*) fine. It just took a bit over two minutes. (*) http://code.python.org/hg/trunk/ Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Infra issues (was: Re: I would like an svn account)
On Sat, Jan 3, 2009 at 15:21, Ivan Krstić 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" wrote: >> Do any of the DVCS under consideration satisfy that requirement? I >> guess I'm asking whether you think all this talk about DVCSes is futile >> or premature? > > I still do hope that Debian releases lenny before any of this advances. > 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
On Sun, Jan 4, 2009 at 9:28 AM, Brett Cannon wrote: > On Sat, Jan 3, 2009 at 16:06, "Martin v. Löwis" wrote: >>> Do any of the DVCS under consideration satisfy that requirement? I >>> guess I'm asking whether you think all this talk about DVCSes is futile >>> or premature? >> >> I still do hope 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Martin v. Löwis v.loewis.de> writes: > > As for Mercurial, I have been told their repository layout has not > > changed since their first release and updates have been more about bug > > fixes and speed improvements. > > Speed improvements we can ignore; for bug fixes, it would be good to > know 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
Brett Cannon wrote: [...] > I have been using bzr for all of my importlib work. It's worked out > well sans the problem that SOMEONE Barry has not > upgraded the bzr installation to support the newest wire protocol. > If you think *that's* a problem try getting him to write a simple bloody blog 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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I would like an svn account
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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] py3k, bad sys.path and abort()
I've recently noticed that in py3k, the lack of a suitable sys.path will
cause Py_FatalError() to be called, which immediately terminates the
entire application.
On Windows, it is fairly easy for this to happen for developers or
anyone who hasn't run the official Python installation; just have Python
used in a 'service', web server, COM object or anything else which loads
python3x.dll from the system32 etc directory, and neglect to have added
the PYTHONPATH entry in the registry or global environment. As a result
Python can't sniff a good default sys.path, fails to import encodings,
then winds up calling Py_FatalError("Py_Initialize: can't initialize sys
standard streams");
I realize this is something of an edge-case, but having abort() called
on the application in this case is somewhat harsh and difficult to
diagnose. In Python 2.x, you end up with a fairly crippled Python
environment, but it functions well enough to offer clues that your
sys.path isn't setup.
Would it be practical and desirable to handle this situation more
gracefully, possibly just leaving sys.std* set to None and letting
whatever exceptions then occur happen as normal without terminating the
process? Given it is an edge-case, I thought I'd open it here for
discussion before putting work into a patch or opening a bug.
Thanks,
Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
