Mailing List Archive: Python: Dev

My patches

1 2

View All

Index | Next | Previous | View Threaded

victor.stinner at haypocalc

Oct 30, 2008, 3:08 AM

Post #1 of 44 (1544 views)
Permalink

My patches

Hi,

Since some months, I'm trying to improve Python but it's difficult because I'm
not allowed to push patches and I have to wait for some reviews and then for
someone interrested by my patches. Sometimes I just get a good reaction
like "nice patch" and then nothing. Should I stop sending new patches and
work on another project, improve old patches and send an email everydays to
the mailing list to get some reaction?

Barry doesn't want to release Python 3.0rc2 because of release blocker issues.
Guido asked if the mailing list has collapsed.

I don't understand: you want help, but some of my patches are waiting since
many weeks ago... The problem is not just about me, but about anyone trying
to contribute to Python: if it's to hard to contribute, people would just
move to another more reactive project.

---

Well, here is a short list of my patches waiting to be commited:

http://bugs.python.org/issue3727 (fix poplib for python3)
+ patch posted 13 days ago

http://bugs.python.org/issue1210 (fix imaplib for python3)
+ patch posted 16 days ago

http://bugs.python.org/issue4036 (support bytes for subprocess.Popen)
+ patch posted 22 days ago

http://bugs.python.org/issue4021 (improve tokenize.detect_encoding)
+ patch posted 28 days ago
+ reviewed by amaury

http://bugs.python.org/issue4008 (IDLE: unicode fix checksyntax())
+ patch posted 28 days ago

http://bugs.python.org/issue3954 (fix _hotshot.logreader)
+ patch posted 39 days ago
+ reviewed by amaury and georg.brandl

http://bugs.python.org/issue3880 (fix _tkinter._flatten)
+ patch posted 44 days ago
+ reviewed by gpolo

http://bugs.python.org/issue3632 (ensure GIL in _PyObject_Dump)
+ patch posted 70 days ago
+ reviewed by amaury

--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Oct 30, 2008, 4:04 AM

Post #2 of 44 (1488 views)
Permalink

Re: My patches [In reply to]

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

On Oct 30, 2008, at 11:08 AM, Victor Stinner wrote:

>Since some months, I'm trying to improve Python but it's difficult because
>I'm not allowed to push patches and I have to wait for some reviews and then
>for someone interrested by my patches. Sometimes I just get a good reaction
>like "nice patch" and then nothing. Should I stop sending new patches and
>work on another project, improve old patches and send an email everydays to
>the mailing list to get some reaction?
>
>Barry doesn't want to release Python 3.0rc2 because of release blocker
>issues. Guido asked if the mailing list has collapsed.
>
>I don't understand: you want help, but some of my patches are waiting since
>many weeks ago... The problem is not just about me, but about anyone trying
>to contribute to Python: if it's to hard to contribute, people would just
>move to another more reactive project.

Victor, don't despair! Your contributions are appreciated.

Let me remind you though that I've been mostly unavailable for the past two
weeks at a work conference. I won't have time to look at anything until
Monday at the earliest. That's why I set the 3.0 schedule the way I did.

One of the reasons why I'm very keen on us moving to a distributed version
control system is to help break the logjam on core developers. True, your
code will still not be able to land in the "official" branch without core
developer intervention, but you will be able to share your code, fixes,
branches with everyone in a much more live way than patches in a tracker. It
will be much easier for others to merge your changes, test them, review them,
etc. and it will be much easier for you to track changes in the official trunk
as other code lands.

In any case, I know it's frustrating not to get good timely feedback, but such
is the nature of open source projects. Please be patient and don't worry.
I'll look at your patches when I'm back in the real world.

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkJlMoACgkQ2YZpQepbvXG0DgCePlFiKrAH/UQkQhLb8Mr7dwtd
mmUAoJN2pOJN40fOQ0otMSgeVCt5sqLL
=Mnta
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

victor.stinner at haypocalc

Oct 30, 2008, 5:02 AM

Post #3 of 44 (1495 views)
Permalink

Re: My patches [In reply to]

> Let me remind you though that I've been mostly unavailable for the past two
> weeks at a work conference.

Cool, you're back :-) But my email was not against you.

> That's why I set the 3.0 schedule the way I did.

Personnaly, I don't want to get python 3.0 final with some broken modules or
some criticial problems. So it's a good thing to delay the release until bugs
are fixed.

> One of the reasons why I'm very keen on us moving to a distributed version
> control system is to help break the logjam on core developers.

Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial,
GIT, anything else? I tried Mercurial which is nice (at least some small
project). But I think that GIT is the fatest and most robust system.

> you will be able to share your code, fixes, branches with everyone
> in a much more live way than patches in a tracker.

Right and it's very difficult to manage patches using the tracker. After
writing the patch, I have to revert all patches to be able to write a new
patch because it's easier to generate a patch in this way. But some patches
depend on other patches :-/

> In any case, I know it's frustrating not to get good timely feedback

A friend told me that his patch took 6 months to be applied :-/ (don't know
which one)

If Python would be more reactive, more developer will be attracted. The
communication is very important in an open source project. I contributed to
many many projects, and I can say that Python is already one of the most
reactive project! But it can be better ;-)

--
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

eckhardt at satorlaser

Oct 30, 2008, 5:19 AM

Post #4 of 44 (1489 views)
Permalink

Re: My patches [In reply to]

On Thursday 30 October 2008, Victor Stinner wrote:
> > One of the reasons why I'm very keen on us moving to a distributed
> > version control system is to help break the logjam on core developers.
>
> Yeah, exactly :-) Does anyone already maintain a distributed tree?
> Mercurial, GIT, anything else?

Bazaar. Take a look at the developers' pages on python.org, they mention that
a BZR checkout is available. I know that it works (though the initial
checkout is glacially slow) but I don't know what "official" support it has
or what is planned with it.

Uli

--
Sator Laser GmbH
Gesch�ftsf�hrer: Thorsten F�cking, Amtsgericht Hamburg HR B62 932

**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschlie�lich s�mtlicher Anh�nge ist nur f�r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf�nger sein sollten. Die E-Mail ist in diesem Fall zu l�schen und darf weder gelesen, weitergeleitet, ver�ffentlicht oder anderweitig benutzt werden.
E-Mails k�nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte �nderungen enthalten. Sator Laser GmbH ist f�r diese Folgen nicht verantwortlich.

**************************************************************************************

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Oct 30, 2008, 5:50 AM

Post #5 of 44 (1489 views)
Permalink

Re: My patches [In reply to]

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

On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:

>> Let me remind you though that I've been mostly unavailable for the past two
>> weeks at a work conference.
>
>Cool, you're back :-) But my email was not against you.

Well, not quite. :) Monday.

>> One of the reasons why I'm very keen on us moving to a distributed version
>> control system is to help break the logjam on core developers.
>
>Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial,
>GIT, anything else? I tried Mercurial which is nice (at least some small
>project). But I think that GIT is the fatest and most robust system.

We have experimental Bazaar and Mercurial mirrors of the various branches.
I've just put up a loggerhead (think ViewCVS for Bazaar) instance on
code.python.org. http://code.python.org. I haven't installed pysqlite yet on
that box, but when I do, it will be much more responsive. (I also haven't
installed the init.d script yet so if it dies, let me know and I'll restart
it.)

Please note that these are *expermental*. We have not officially chosen a
dvcs, or even decided that we're moving to one. Brett as the head of the
infrastructure committee will have more to say about that.

>Right and it's very difficult to manage patches using the tracker. After
>writing the patch, I have to revert all patches to be able to write a new
>patch because it's easier to generate a patch in this way. But some patches
>depend on other patches :-/

I think you will like using Bazaar^H^H^H^H^H^Ha dvcs :).

>If Python would be more reactive, more developer will be attracted. The
>communication is very important in an open source project. I contributed to
>many many projects, and I can say that Python is already one of the most
>reactive project! But it can be better ;-)

I agree! How can we improve our development process, given that we're an all
volunteer organization?

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkJrYcACgkQ2YZpQepbvXGrgQCeIQV+n81qpZw/CaG3kzdCVYyU
RzYAn2lxqzwZ5QwBw38RkyNsix++h9iI
=O9T4
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Oct 30, 2008, 6:14 AM

Post #6 of 44 (1493 views)
Permalink

Re: My patches [In reply to]

Ulrich Eckhardt wrote:
> On Thursday 30 October 2008, Victor Stinner wrote:
>>> One of the reasons why I'm very keen on us moving to a distributed
>>> version control system is to help break the logjam on core developers.
>> Yeah, exactly :-) Does anyone already maintain a distributed tree?
>> Mercurial, GIT, anything else?
>
> Bazaar. Take a look at the developers' pages on python.org, they mention that
> a BZR checkout is available. I know that it works (though the initial
> checkout is glacially slow) but I don't know what "official" support it has
> or what is planned with it.

It's kept up to date, and will eventually move to a more complete DVCS
experiment (there are also mercurial and git mirrors being maintained,
but they haven't been linked from python.org yet - a trawl through the
python-dev archives should turn up the links to the URLs).

The PSF's infrastructure committee isn't that big though (and all
volunteers), and switching version control systems isn't exactly easy
(even the migration from Sourceforge CVS to python.org SVN took quite a
bit of effort from key people). The migration of all our regular
workflows from the familiar centralised VCS style to a DVCS style of
development promises to be pretty disruptive in the short term, no
matter how beneficial it will be in the long run.

That said, with the tracker migration from Sourceforge to Roundup behind
us, and a hopefully successful 3.0 release not too far away, it's
probably time to start giving the idea more serious thought.

Ultimately, any complete plan for migration from SVN to a DVCS will
likely need to come in the form of a meta-PEP like the one MvL wrote to
justify and document the migration from CVS to SVN:
http://www.python.org/dev/peps/pep-0347/

Unlike PEP 347 (where SVN was purpose built as a "better CVS", thus
making the overall migration path and workflow updates reasonably
straightforward), a PEP for migrating to a DVCS would need to provide
justification not only for moving to a DVCS in general, but also for the
choice of a particular DVCS. Similar to the exercise in selecting
Roundup, part of that would not only be the features of the tool itself,
but also the available volunteer expertise to maintain an instance of it
on python.org.

One thing that such a PEP could probably also use is additional feedback
from folks outside the core dev team on how a DVCS would benefit them
(since the core devs are the ones least affected by the limitations of a
centralised VCS - although having something better than svnmerge to
handle maintenance of multiple branches would be a very good thing for
us too!).

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Oct 30, 2008, 6:20 AM

Post #7 of 44 (1480 views)
Permalink

Re: My patches [In reply to]

Barry Warsaw wrote:
> or even decided that we're moving to one. Brett as the head of the
> infrastructure committee will have more to say about that.

While it is indeed the infrastructure committee's call (since they'll
shoulder the bulk of the effort in organising further investigation into
the idea), I personally believe that moving to some kind of DVCS makes
too much sense for it not to happen eventually.

Anything we can do to make it easier to maintain 4 active branches
(2.x-1 and 3.y-1 maintenance, 2.x and 3.y development) over the next few
years is going to be worth a fair amount of up front effort.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

eric at trueblade

Oct 30, 2008, 7:22 AM

Post #8 of 44 (1481 views)
Permalink

Re: My patches [In reply to]

amk at amk

Oct 30, 2008, 8:04 AM

Post #9 of 44 (1485 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 11:04:42AM +0000, Barry Warsaw wrote:
> One of the reasons why I'm very keen on us moving to a distributed version
> control system is to help break the logjam on core developers. True, your
> code will still not be able to land in the "official" branch without core
> developer intervention, but you will be able to share your code, fixes,
> branches with everyone in a much more live way than patches in a tracker.

I don't see how a DVCS will fix anything. The bottleneck is in
assessing patches for inclusion in the master tree; not enough people
are doing that. We'd just end up with lots of proposed branches
waiting to be merged, instead of patches to be applied.

(What a DVCS might enable is making it easier to do larger
experiments, like the recent Vmgen work, and publish them in a form
that people can download. We could create SVN branches now, but that
means people would then have commit access to all of the Python
source.)

--amk
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

arfrever.fta at gmail

Oct 30, 2008, 8:11 AM

Post #10 of 44 (1481 views)
Permalink

Re: My patches [In reply to]

2008-10-30 16:04 A.M. Kuchling <amk [at] amk> napisał(a):
> On Thu, Oct 30, 2008 at 11:04:42AM +0000, Barry Warsaw wrote:
>> One of the reasons why I'm very keen on us moving to a distributed version
>> control system is to help break the logjam on core developers. True, your
>> code will still not be able to land in the "official" branch without core
>> developer intervention, but you will be able to share your code, fixes,
>> branches with everyone in a much more live way than patches in a tracker.
>
> I don't see how a DVCS will fix anything. The bottleneck is in
> assessing patches for inclusion in the master tree; not enough people
> are doing that. We'd just end up with lots of proposed branches
> waiting to be merged, instead of patches to be applied.
>
> (What a DVCS might enable is making it easier to do larger
> experiments, like the recent Vmgen work, and publish them in a form
> that people can download. We could create SVN branches now, but that
> means people would then have commit access to all of the Python
> source.)

SVN supports path-based authorization.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

fdrake at acm

Oct 30, 2008, 8:16 AM

Post #11 of 44 (1481 views)
Permalink

Re: My patches [In reply to]

On Oct 30, 2008, at 11:11 AM, Arfrever Frehtes Taifersar Arahesis wrote:
> SVN supports path-based authorization.
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html

This has worked well for us with contractors and partners, and isn't
problematic or tedious to maintain.

-Fred

--
Fred Drake <fdrake at acm.org>

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

steve at holdenweb

Oct 30, 2008, 8:20 AM

Post #12 of 44 (1478 views)
Permalink

Re: My patches [In reply to]

Arfrever Frehtes Taifersar Arahesis wrote:
> 2008-10-30 16:04 A.M. Kuchling <amk [at] amk> napisał(a):
>> On Thu, Oct 30, 2008 at 11:04:42AM +0000, Barry Warsaw wrote:
>>> One of the reasons why I'm very keen on us moving to a distributed version
>>> control system is to help break the logjam on core developers. True, your
>>> code will still not be able to land in the "official" branch without core
>>> developer intervention, but you will be able to share your code, fixes,
>>> branches with everyone in a much more live way than patches in a tracker.
>> I don't see how a DVCS will fix anything. The bottleneck is in
>> assessing patches for inclusion in the master tree; not enough people
>> are doing that. We'd just end up with lots of proposed branches
>> waiting to be merged, instead of patches to be applied.
>>
>> (What a DVCS might enable is making it easier to do larger
>> experiments, like the recent Vmgen work, and publish them in a form
>> that people can download. We could create SVN branches now, but that
>> means people would then have commit access to all of the Python
>> source.)
>
> SVN supports path-based authorization.
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html

good point, but then we'd have an authentication management task ...

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ironfroggy at gmail

Oct 30, 2008, 8:23 AM

Post #13 of 44 (1484 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 8:50 AM, Barry Warsaw <barry [at] python> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:
> >If Python would be more reactive, more developer will be attracted. The
> >communication is very important in an open source project. I contributed to
> >many many projects, and I can say that Python is already one of the most
> >reactive project! But it can be better ;-)
>
> I agree! How can we improve our development process, given that we're an all
> volunteer organization?

On that note, are more volunteers needed? Are there any capacities in
which extra sets of hands could make help these improvements or would
it just be more overhead and managing people and figuring out what to
do?

Moderately related note, I'm going to start the python-dev list
summaries again (I have been the worst summary maintainer *ever*) and
I'd like to set up the process as a community effort. That is, I've
got some code I'm going to launch (probably at appengine) where edits
can be made to the summaries by anyone, to be reviewed and taken in,
before submitting the final summaries every two weeks. This should
make keeping them going more likely, because no one person will need
to find the time. It will also make the summaries more accurate if
people actually involved in the discussions can fix any mistakes or
repair omissions. I think the summaries are important, and one of many
puzzle pieces to keeping people informed, which is all part of moving
the development process along. Of course, this is all assuming no one
objects to that plan.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

p.f.moore at gmail

Oct 30, 2008, 8:55 AM

Post #14 of 44 (1484 views)
Permalink

Re: My patches [In reply to]

2008/10/30 A.M. Kuchling <amk [at] amk>:
> On Thu, Oct 30, 2008 at 11:04:42AM +0000, Barry Warsaw wrote:
>> One of the reasons why I'm very keen on us moving to a distributed version
>> control system is to help break the logjam on core developers. True, your
>> code will still not be able to land in the "official" branch without core
>> developer intervention, but you will be able to share your code, fixes,
>> branches with everyone in a much more live way than patches in a tracker.
>
> I don't see how a DVCS will fix anything. The bottleneck is in
> assessing patches for inclusion in the master tree; not enough people
> are doing that. We'd just end up with lots of proposed branches
> waiting to be merged, instead of patches to be applied.

Agreed. There are lots of patches around, but not enough core dev
man-hours to review and apply them. As just adding extra people as
core devs isn't going to work (I don't believe it's *hard* to become a
core dev at the moment, it just needs a level of commitment that many
people can't offer), and as adding hours to the day isn't possible
(hmm, Guido - about that time machine?) I think the best way of
helping is with patch triage.

More people trawling the trackers and reviewing existing patches might
free up core dev time for looking at the more subtle stuff, as long as
(1) core devs could be happy to accept "this is OK, commit it"
comments from non-core devs, and/or (2) it's easy to locate stuff to
review, and just as importantly stuff which has been reviewed and is
"ready to go".

Question - is there anything Roundup can do to help triage? Extra
status or keyword values ("has patch", "ready to go", ...)? More
canned searches ("Show Open" and "Show Unassigned" aren't a lot of
help)? Custom reports (summaries by type)? Or are such things there
and simply not publicised enough?

I just did a quick experiment, checking for trivial documentation
patches I could review, and some things became obvious:

1. There is no way of telling which issues have a patch.
2. Some patches marked as "documentation" are doc fixes, others seem
to be issues where it has been decided that the behaviour is correct
as is, but needs to be documented. Fair enough, but it's much harder
to assess the latter, and there's no way of just grabbing the former
(for example, to spend a spare 30 minutes reviewing simple stuff).
3. There's nothing obvious I can do to move an issue forward. Sure, I
can make a comment, but that's about it. I'd like something that stood
a bit more chance of getting noticed (like a status change, or maybe a
list of people who think this is good to apply, which I can add myself
to).

All of which boil down to (1) quickly finding stuff I can deal with,
and (2) feeling like what I do has an effect.

Hmm, I've spent more time on this than I should have, and it's gone
way off topic. Is there anywhere better to discuss it?

Paul.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

draghuram at gmail

Oct 30, 2008, 9:02 AM

Post #15 of 44 (1484 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 11:55 AM, Paul Moore <p.f.moore [at] gmail> wrote:

> I just did a quick experiment, checking for trivial documentation
> patches I could review, and some things became obvious:
>
> 1. There is no way of telling which issues have a patch.

There is a "patch" keyword that is usually set for issues with patches
and search can be done for given keywords.

Thanks,
Raghu
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ziade.tarek at gmail

Oct 30, 2008, 9:09 AM

Post #16 of 44 (1480 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore <p.f.moore [at] gmail> wrote:
>> I don't see how a DVCS will fix anything. The bottleneck is in
>> assessing patches for inclusion in the master tree; not enough people
>> are doing that. We'd just end up with lots of proposed branches
>> waiting to be merged, instead of patches to be applied.
>
> Agreed. There are lots of patches around, but not enough core dev
> man-hours to review and apply them. As just adding extra people as
> core devs isn't going to work (I don't believe it's *hard* to become a
> core dev at the moment, it just needs a level of commitment that many
> people can't offer), and as adding hours to the day isn't possible
> (hmm, Guido - about that time machine?) I think the best way of
> helping is with patch triage.
>

Since it is a hard and long process "to know it all" in Python, and
to become a core developer

What about having two level of devs ?

+ core developers
+ standard library developers

I mean, the standard library could be open ihmo to a wider range of people,
or maybe even having people specialized in some packages, modules, even
if they don't know anything about the C apis of the core.

Those "standard library developers" could be blessed to work on
specific areas of the standard
library and "followed" by a core developer that can just make sure
everything goes in the right direction
without having too much extra work for that.

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
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

jnoller at gmail

Oct 30, 2008, 9:25 AM

Post #17 of 44 (1482 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziad� <ziade.tarek [at] gmail> wrote:
> On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore <p.f.moore [at] gmail> wrote:
>>> I don't see how a DVCS will fix anything. The bottleneck is in
>>> assessing patches for inclusion in the master tree; not enough people
>>> are doing that. We'd just end up with lots of proposed branches
>>> waiting to be merged, instead of patches to be applied.
>>
>> Agreed. There are lots of patches around, but not enough core dev
>> man-hours to review and apply them. As just adding extra people as
>> core devs isn't going to work (I don't believe it's *hard* to become a
>> core dev at the moment, it just needs a level of commitment that many
>> people can't offer), and as adding hours to the day isn't possible
>> (hmm, Guido - about that time machine?) I think the best way of
>> helping is with patch triage.
>>
>
> Since it is a hard and long process "to know it all" in Python, and
> to become a core developer
>
> What about having two level of devs ?
>
> + core developers
> + standard library developers
>
> I mean, the standard library could be open ihmo to a wider range of people,
> or maybe even having people specialized in some packages, modules, even
> if they don't know anything about the C apis of the core.
>
> Those "standard library developers" could be blessed to work on
> specific areas of the standard
> library and "followed" by a core developer that can just make sure
> everything goes in the right direction
> without having too much extra work for that.
>
> Regards,
> Tarek

Interestingly enough, I consider myself in the "standard library
developers" RE: the multiprocessing package. I just thought that's how
things broke down unofficially. I personally don't feel comfortable
doing much of anything outside of my sandbox, but am more than willing
to commit patches that have been reviewed by people my senior (in
skill!).

-jesse
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

brett at python

Oct 30, 2008, 11:30 AM

Post #18 of 44 (1481 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 06:14, Nick Coghlan <ncoghlan [at] gmail> wrote:
> Ulrich Eckhardt wrote:
>> On Thursday 30 October 2008, Victor Stinner wrote:
>>>> One of the reasons why I'm very keen on us moving to a distributed
>>>> version control system is to help break the logjam on core developers.
>>> Yeah, exactly :-) Does anyone already maintain a distributed tree?
>>> Mercurial, GIT, anything else?
>>
>> Bazaar. Take a look at the developers' pages on python.org, they mention that
>> a BZR checkout is available. I know that it works (though the initial
>> checkout is glacially slow) but I don't know what "official" support it has
>> or what is planned with it.
>
> It's kept up to date, and will eventually move to a more complete DVCS
> experiment (there are also mercurial and git mirrors being maintained,
> but they haven't been linked from python.org yet - a trawl through the
> python-dev archives should turn up the links to the URLs).
>
> The PSF's infrastructure committee isn't that big though (and all
> volunteers), and switching version control systems isn't exactly easy
> (even the migration from Sourceforge CVS to python.org SVN took quite a
> bit of effort from key people). The migration of all our regular
> workflows from the familiar centralised VCS style to a DVCS style of
> development promises to be pretty disruptive in the short term, no
> matter how beneficial it will be in the long run.
>
> That said, with the tracker migration from Sourceforge to Roundup behind
> us, and a hopefully successful 3.0 release not too far away, it's
> probably time to start giving the idea more serious thought.
>
> Ultimately, any complete plan for migration from SVN to a DVCS will
> likely need to come in the form of a meta-PEP like the one MvL wrote to
> justify and document the migration from CVS to SVN:
> http://www.python.org/dev/peps/pep-0347/
>

I have actually started such a PEP, so this is being worked on.

-Brett
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

brett at python

Oct 30, 2008, 11:38 AM

Post #19 of 44 (1488 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 05:50, Barry Warsaw <barry [at] python> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:
[SNIP]
>>If Python would be more reactive, more developer will be attracted. The
>>communication is very important in an open source project. I contributed to
>>many many projects, and I can say that Python is already one of the most
>>reactive project! But it can be better ;-)
>
> I agree! How can we improve our development process, given that we're an all
> volunteer organization?

And this is a key point that people seem to forget. Guido is the ONLY
developer who gets paid to work on Python, and that is only 50% of his
time (when he doesn't have a Google-related workload), and honestly I
would rather he not deal with patches that do not affect what he is
working on.

The rest of us spend our evenings and weekends on this on top of
trying to balance a normal life. In my case I had to stop my Python
work recently because I have been working on my Ph.D. thesis proposal.
Everyone has their lives that take priority.

And no, I do not think that giving out more commit privileges will
necessarily solve everything. Python is known for its quality and part
of that reason is we are careful about handing out privileges. This is
not to say we can't try to help move people along towards getting
privileges faster, but I am not interested in doing what Pugs does and
give everyone who has submitted a patch commit privs.

-Brett
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 30, 2008, 12:43 PM

Post #20 of 44 (1489 views)
Permalink

Re: My patches [In reply to]

> Question - is there anything Roundup can do to help triage? Extra
> status or keyword values ("has patch",

There is "patch" keyword already, and a public query "Patches"
(as well as "My Patches")

> "ready to go", ...)?

We could give more people the right to set the resolution to "Accepted".
This is a matter of trust, though - if the committer then still needs
to review it, anyway, nothing is gained.

> More
> canned searches ("Show Open" and "Show Unassigned" aren't a lot of
> help)?

Please go to the "edit" label next to "Search". You can store your
own searches, but you can also share searches with others.

> Custom reports (summaries by type)?

This I don't understand - how is it different from a search?

> Or are such things there and simply not publicised enough?

Perhaps. I really don't know what percentage of interested users
is aware of roundup capabilities.

> I just did a quick experiment, checking for trivial documentation
> patches I could review, and some things became obvious:
>
> 1. There is no way of telling which issues have a patch.

There is the patch keyword, and you can query for it. There is a
canned query published already.

> 2. Some patches marked as "documentation" are doc fixes, others seem
> to be issues where it has been decided that the behaviour is correct
> as is, but needs to be documented. Fair enough, but it's much harder
> to assess the latter, and there's no way of just grabbing the former
> (for example, to spend a spare 30 minutes reviewing simple stuff).

There is the "easy" keyword. Of course, it might also be useful to
triage more issues as "easy".

> 3. There's nothing obvious I can do to move an issue forward. Sure, I
> can make a comment, but that's about it. I'd like something that stood
> a bit more chance of getting noticed (like a status change, or maybe a
> list of people who think this is good to apply, which I can add myself
> to).

The "developer" role has more user interface. I've just given it to you.

> Hmm, I've spent more time on this than I should have, and it's gone
> way off topic. Is there anywhere better to discuss it?

There is the tracker-discuss list for discussion, and the meta tracker
for actual problems/wishes for the tracker.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 30, 2008, 12:46 PM

Post #21 of 44 (1479 views)
Permalink

Re: My patches [In reply to]

> What about having two level of devs ?
>
> + core developers
> + standard library developers

We effectively have that already. Many of the committers will
only ever commit to a single module (+docs and tests), as they
volunteered to maintain that very module (e.g. Lars Gust�bel
for the tarfile module).

If a committer agrees to restrict himself to a certain area,
he will usually keep that promise, so there isn't really any
need for a finer-grained access control, IMO.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

martin at v

Oct 30, 2008, 12:48 PM

Post #22 of 44 (1480 views)
Permalink

Re: My patches [In reply to]

> Interestingly enough, I consider myself in the "standard library
> developers" RE: the multiprocessing package. I just thought that's how
> things broke down unofficially.

It's actually fairly official (see my other message) - "you know who you
are". It has been working that way fine for the last few years. The
public record if it is in Misc/developers.txt (although that file might
be slightly incomplete/incorrect).

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

amk at amk

Oct 30, 2008, 2:17 PM

Post #23 of 44 (1488 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 03:55:38PM +0000, Paul Moore wrote:
> 2. Some patches marked as "documentation" are doc fixes, others seem
> to be issues where it has been decided that the behaviour is correct
> as is, but needs to be documented. Fair enough, but it's much harder
> to assess the latter, and there's no way of just grabbing the former
> (for example, to spend a spare 30 minutes reviewing simple stuff).

Perhaps the documentation category could be split into 'Documentation'
and 'Documentation Needed'; the latter means the issue entails writing
new text as opposed to rewriting. But I think on average
documentation issues get processed pretty quickly: Georg is responsive
to them, and patches are easy to apply because you don't need to worry
about breaking anything.

In general Python development is much less freewheeling and fun than
it used to be. You could come up with new features and modules, add
lots of new capabilities to a module. Today we're making much smaller
changes, discuss them at far great length, and have to worry about
breaking all the existing Python code out there, It's a sign of
Python's maturity, of course, and I'm not saying that the design
effort and the compatibility requirements should be dropped, but they
certainly act as a damper.

On some of my issues (esp. ones relating to curses and mailbox.py), I
feel paralyzed because problems are occurring on platforms I don't
have access to (e.g. FreeBSD). The buildbots will report problems,
but then you have to debug them by committing changes, triggering a
build, and observing the results. And all of these actions will send
e-mail to python-checkins. (Imagine if every 'print "reached here!"'
you added while debugging was e-mailed to everyone...)

--amk
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

exarkun at divmod

Oct 30, 2008, 2:54 PM

Post #24 of 44 (1460 views)
Permalink

Re: My patches [In reply to]

On Thu, 30 Oct 2008 17:17:02 -0400, "A.M. Kuchling" <amk [at] amk> wrote:
> [snip]
>
>On some of my issues (esp. ones relating to curses and mailbox.py), I
>feel paralyzed because problems are occurring on platforms I don't
>have access to (e.g. FreeBSD). The buildbots will report problems,
>but then you have to debug them by committing changes, triggering a
>build, and observing the results. And all of these actions will send
>e-mail to python-checkins. (Imagine if every 'print "reached here!"'
>you added while debugging was e-mailed to everyone...)

I do that when I need to. People whose lives would be ruined by the
receipt of such an email always have the option of leaving the checkin
list.

However, there is a buildbot feature named "try" which lets you submit
a patch (subject to authentication) and performs a build with the patch
applied. This lets you try lots of little changes without getting your
VCS involved. It needs to be enabled in the buildmaster configuration
and credentials created for any user who will be given access.

Jean-Paul
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

amauryfa at gmail

Oct 30, 2008, 3:18 PM

Post #25 of 44 (1460 views)
Permalink

Re: My patches [In reply to]

On Thu, Oct 30, 2008 at 22:17, A.M. Kuchling <amk [at] amk> wrote:
> On some of my issues (esp. ones relating to curses and mailbox.py), I
> feel paralyzed because problems are occurring on platforms I don't
> have access to (e.g. FreeBSD). The buildbots will report problems,
> but then you have to debug them by committing changes, triggering a
> build, and observing the results. And all of these actions will send
> e-mail to python-checkins. (Imagine if every 'print "reached here!"'
> you added while debugging was e-mailed to everyone...)

By the way, it seems that this python-checkins mailing list did not
archive the recent commits:
http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
I miss them... Can someone fix it?

--
Amaury Forgeot d'Arc
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads