Could someone please add Lars Gustaebel (SF ID "gustaebel") as a developer? He's responsible for writing and maintaining tarfile.py, but his bugfixes usually sit around in the tracker until someone gets around to looking at them, which is inefficient. Thanks! --amk
Could someone please add Lars Gustaebel (SF ID "gustaebel") as a developer? He's responsible for writing and maintaining tarfile.py, but his bugfixes usually sit around in the tracker until someone gets around to looking at them, which is inefficient.
Have him assign the patches to me. I'm not sure it is a good idea to keep adding developers who do only a handful of checkins and disappear. This is doubly true if they are not active on python-dev, have not asked for access, and have not made some commitment to stay around for maintenance. Raymond
On Wed, Oct 20, 2004 at 11:14:50AM -0400, Raymond Hettinger wrote:
I'm not sure it is a good idea to keep adding developers who do only a handful of checkins and disappear. This is doubly true if they are not
Agreed, but based on his track record it seems unlikely that Lars is going to vanish; he contributed the module on 2003/01/05, still maintains the code separately at http://www.gustaebel.de/lars/tarfile/, and has contributed 9 bugfixes since then (compared to 7 bugfixes from others). If we're adding Peter, who'll be maintaining a single module, then adding Lars seems equally reasonable. I like the approach of adding people who will maintain a particular module or package. Long-term, I think it's more sustainable to have a larger number of developers, each person responsible for a small number of modules, than a small number of developers struggling to keep up with everything. --amk
Long-term, I think it's more sustainable to have a larger number of developers, each person responsible for a small number of modules, than a small number of developers struggling to keep up with everything.
I'll be happy to apply the patches of someone maintaining their own module. Raymond
[A.M. Kuchling] ...
If we're adding Peter, who'll be maintaining a single module, then adding Lars seems equally reasonable.
The key difference (to my mind) is that Peter asked for it, but so far Lars has not. If Lars asks, that proves a number of things to me: he knows that we intend to assign tarfile bug reports to him; he agrees that it's appropriate to do so; he confirms that he's comfortable driving CVS; and, last but not least, he knows how to reach python-dev <0.1 wink>.
A.M. Kuchling wrote:
Could someone please add Lars Gustaebel (SF ID "gustaebel") as a developer? He's responsible for writing and maintaining tarfile.py, but his bugfixes usually sit around in the tracker until someone gets around to looking at them, which is inefficient.
In addition to what Tim says (that Lars also should ask for it), I see no real problem with the status quo. I have applied a number of tarfile patches in the past, and keep an eye on any new patches. Of the pending patches, I see no real problem if they are not applied - even if they don't get into 2.4, I think adding them to 2.4.1 might still be appropriate. tarfile is inherently a tricky issue (with the tar file format being so difficult), and I believe Lars appreciates that somebody reviews his changes before applying them. Regards, Martin
Hello! Since I am the subject of this discussion, I think it's necessary to give my view on this too. I am reluctant on this topic. I don't mean to stab Andrew in the back, but he brought up this issue by himself, I was surprised and (very) flattered as I read it today - who wouldn't like to be a Python developer :-) This explains why I didn't ask for it on python-dev myself. I do not think that it is necessary at this point in time to add me as a developer. There is no open tarfile bug left in the bug tracker and the two open tarfile patches both introduce new features which will have to wait until 2.5 anyway. The first big bug wave since the 2.3 release seems to be over. In his post, Martin said that he believes I like my patches be reviewed by others before they're applied and I agree - I like a second opinion, it makes me feel more comfortable even if it slows down the process. I made positive experiences with Neil Norwitz, Martin and Andrew in this respect. I still see myself as the main developer of tarfile. As Andrew mentioned, I maintain a separate distribution on my website and have a lot of user feedback there, too. I search the SF tracker for tarfile bugs on a regular basis and try to help out whenever I can. This is not supposed to change in the future. If it were common Python development policy to add a contributor to the developers list for further maintenance of his module, I would be delighted to step in. But I don't think this is currently the case. BTW, The "Open issues" section of PEP #2 proposes a practice for module maintenance. It's about having a list of module maintainers that are notified each time there are issues with their module. Maybe there needs to be a more general discussion on this whole topic. -- Lars Gustäbel lars@gustaebel.de
Lars Gustäbel wrote:
BTW, The "Open issues" section of PEP #2 proposes a practice for module maintenance. It's about having a list of module maintainers that are notified each time there are issues with their module. Maybe there needs to be a more general discussion on this whole topic.
Is it possible to give developers privileges on SF *without* granting CVS access to those that don't want it? Then (e.g. Lars) could be added to the list of people that bugs could be assigned to, without any (even imagined) pressure to commit changes directly to the source tree. This could also be useful for having a few more people who can handle tracker items on SF (e.g. by assigning bugs to those likely to be knowledgeable about them), without having to give them all CVS access. I'd be interested in having more ability to help handle bugs, but I see no reason at all to give me write access to CVS. However, I don't know enough about Source Forge to know if either idea is possible. Regards, Nick.
Nick Coghlan wrote:
However, I don't know enough about Source Forge to know if either idea is possible.
This wasn't possible in the past, but is possible now. It would be a change of policy, though, since in Python, we have given all SF developers same rights (except for project admins, of course). I would not like to see a change in that policy, as it complicates matters, and it is difficult to tell whether a lack of access rights was by intention or by mistake. In the specific case, I don't find it too difficult to send an email message to Lars whenever I see a tarfile bug that he hasn't noticed yet. Regards, Martin
["Martin v. Löwis"]
In the specific case, I don't find it too difficult to send an email message to Lars whenever I see a tarfile bug that he hasn't noticed yet.
That's okay with me. But if it were possible to assign bugs to me, others could see that these bugs are already taken care of, so they wouldn't have to bother. Wouldn't this save some time? -- Lars Gustäbel lars@gustaebel.de
On Thursday 21 October 2004 02:29 pm, Lars Gustäbel wrote:
If it were common Python development policy to add a contributor to the developers list for further maintenance of his module, I would be delighted to step in. But I don't think this is currently the case.
I think there are lots of people on python-dev who aren't listed as developers on SourceForge. I, for one, have no problem with contributors being on this list. I also don't recall hearing any objections from others.
BTW, The "Open issues" section of PEP #2 proposes a practice for module maintenance. It's about having a list of module maintainers that are notified each time there are issues with their module. Maybe there needs to be a more general discussion on this whole topic.
Perhaps. I think setting up a category for related bugs/patches, adding you to the project on SF, and having such tracker entries automatically assigned to you (on the basis of category) would pretty much take care of this. Martin expressed some reservation about having different people on the project have different permissions, which I'd be more concerned about if it were a matter of denying you a permission you wanted or needed. Given that you specifically prefer not to have commit privs, I don't have a problem with your permissions being set up that way. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
Fred L. Drake, Jr. wrote:
Martin expressed some reservation about having different people on the project have different permissions, which I'd be more concerned about if it were a matter of denying you a permission you wanted or needed. Given that you specifically prefer not to have commit privs, I don't have a problem with your permissions being set up that way.
I'm just trying to say that the permissions won't stay that way. At some point, somebody will wonder about the inconsistency, and "adjust" them, to make them all same again. Regards, Martin
On Friday 22 October 2004 02:25 pm, Martin v. Löwis wrote:
I'm just trying to say that the permissions won't stay that way. At some point, somebody will wonder about the inconsistency, and "adjust" them, to make them all same again.
Whoever's doing that has too much time on their hands. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>
Martin v. Löwis wrote:
Fred L. Drake, Jr. wrote:
Martin expressed some reservation about having different people on the project have different permissions, which I'd be more concerned about if it were a matter of denying you a permission you wanted or needed. Given that you specifically prefer not to have commit privs, I don't have a problem with your permissions being set up that way.
I'm just trying to say that the permissions won't stay that way. At some point, somebody will wonder about the inconsistency, and "adjust" them, to make them all same again.
Although, with the current policy being "Don't add Python developers to SF without their asking for access", surely it would be simple enough to add an unwritten addendum to that unwritten policy to say "Don't adjust a developer's SF permissions without asking them first". Cheers, Nick.
Nick Coghlan wrote:
Although, with the current policy being "Don't add Python developers to SF without their asking for access", surely it would be simple enough to add an unwritten addendum to that unwritten policy to say "Don't adjust a developer's SF permissions without asking them first".
Certainly. Regards, Martin
participants (7)
-
"Martin v. Löwis" -
A.M. Kuchling -
Fred L. Drake, Jr. -
Lars Gustäbel -
Nick Coghlan -
Raymond Hettinger -
Tim Peters