On 18/03/07, Tony Meyer [EMAIL PROTECTED] wrote:
on someone else's patch. It seems relevant to me that the original
poster (Tony Meyer) hasn't felt strongly enough to respond on his own
behalf to comments on his patch. No disrespect to Tony, but I'd argue
that the implication is that the
Tony Meyer schrieb:
ISTM that there is value in submitting a patch (including tests and
documentation, and making appropriate comment in related patches), even
if that is all that is done (i.e. no follow-up).
That's certainly, absolutely, true. It's also true that there are very
many kinds
On 8/03/2007, at 2:42 AM, Paul Moore wrote:
On 06/03/07, Scott Dial [EMAIL PROTECTED] wrote:
Sadly the sf tracker doesn't let you search for With comments
by. The
patch I was making reference to was 1410680. Someone else actually
had
wrote a patch that contained bugs and I corrected
On Fri, Mar 09, 2007 at 10:10:48PM -0800, Neal Norwitz wrote:
We should probably be a lot more aggressive about closing bugs and
patches without response. Unfortunately many fall into this category.
This question comes up every so often, and after much discussion I
think python-dev always
On 3/10/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Fri, Mar 09, 2007 at 10:10:48PM -0800, Neal Norwitz wrote:
We should probably be a lot more aggressive about closing bugs and
patches without response. Unfortunately many fall into this category.
This question comes up every so often,
On 3/7/07, Facundo Batista [EMAIL PROTECTED] wrote:
A.M. Kuchling wrote:
FWIW, I have a related perception that we aren't getting new core
developers. These two problems are probably related: people don't get
patches processed and don't become core developers, and we don't have
enough
On 3/5/07, Scott Dial [EMAIL PROTECTED] wrote:
If nothing else, as an outsider there is no way to know why your patch
gets ignored while others get swiftly dealt with. Any sort of
information like this would at least provide more transparency in what
may appear to be elitest processes.
Have
Josiah Carlson writes:
And the best way to encourage someone to maintain a package is...
accepting their patches.
And that's what I think is bull. Whether or not we want or need
maintainers for module or package X is independant of the fact that user
Y has submitted a patch for
Giovanni Bajo schrieb:
I can't see that the barrier at contributing is high.
I think this says it all. It now appears obvious to me that people
inside the mafia don't even realize there is one. Thus, it looks
like we are all wasting time in this thread, since they think there
is nothing
On 08/03/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Titus Brown schrieb:
and it's not at all clear to outsiders like me how new
features, old patches, and old bugs are dealt with.
The simple answer is when we have time. There really is not
more to it. Some patches get higher attention,
Martin v. Löwis wrote:
- How can I know if a patch is still open?
Easy: if it's marked as Open.
- I found a problem, and know how to fix it, but what else need to do?
Go to www.python.org, then CORE DEVELOPMENT, then Patch submission.
- Found a problem in the docs, for this I must submit
Barry Warsaw schrieb:
Jira had a way of automatically assigning certain categories to certain
people. I think the term was project leader or some such. Of course,
this didn't mean that someone else couldn't fix the bug or that the bug
couldn't be reassigned to someone else, but at least
Ron Adam schrieb:
But the tracker needs to be able to actually track the status of individual
items for this to work. Currently there's this huge list and you have to
either wade though it to find out the status of each item, or depend on
someone bring it to your attention.
Well, the
Giovanni Bajo schrieb:
On 06/03/2007 10.52, Martin v. Löwis wrote:
I can't see that the barrier at contributing is high.
I think this says it all. It now appears obvious to me that people
inside the mafia don't even realize there is one. Thus, it looks like
we are all wasting time in
As an outsider who has submitted a handful of patches and has always
wanted to become more involved.. I would like to comment as I feel like
I am the target audience in question. I apologize ahead of time if I am
speaking out of place.
Martin v. Löwis wrote:
Phil Thompson schrieb:
1. Don't
Martin v. Löwis wrote:
Paul Moore schrieb:
Here's a random offer - let me know the patch number for your patch,
and I'll review it.
Surprisingly (and I hope Scott can clarify that), I can't find anything.
Assuming Scott's SF account is geekmug, I don't see any open patches
(1574068 was
A.M. Kuchling wrote:
FWIW, I have a related perception that we aren't getting new core
developers. These two problems are probably related: people don't get
patches processed and don't become core developers, and we don't have
enough core developers to process patches in a timely way. And so
On 06/03/07, Scott Dial [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
Paul Moore schrieb:
Here's a random offer - let me know the patch number for your patch,
and I'll review it.
Surprisingly (and I hope Scott can clarify that), I can't find anything.
Assuming Scott's SF account is
Facundo Batista schrieb:
How many people want to submit a patch, or even a bug, or finds a patch
to review, but don't know how to do something and thinks that python-dev
is not the place to ask (too high minds and experienced people and
everything)?
What I propose is a dedicated place
Paul Moore schrieb:
1. Open a new patch, with your recommended changes.
I'd like to second this. If you are creating a patch by responding in a
comment, it likely gets ignored.
2. Address the comments made against Tony's patch, in yours.
3. Add a recommendation to Tony's patch that it be
Martin v. Löwis wrote:
Ron Adam schrieb:
But the tracker needs to be able to actually track the status of
individual items for this to work. Currently there's this huge list
and you have to either wade though it to find out the status of each
item, or depend on someone bring it to your
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
You may ask yourself why this specific patch was unreviewed for
so long. My own explanation is that it is a highly complicated
algorithm (as any kind of cryptographical algorithm), so nobody
felt qualified to review it.
Giovanni Bajo [EMAIL PROTECTED] wrote:
On 3/6/2007 3:11 AM, Josiah Carlson wrote:
Giovanni Bajo [EMAIL PROTECTED] wrote:
I think this should be pushed to its extreme consequences for the standard
library. Patching the standard library requires *much less* knowledge than
patching the
On Wed, Mar 07, 2007 at 11:10:22AM +0100, Martin v. L?wis wrote:
- Giovanni Bajo schrieb:
- On 06/03/2007 10.52, Martin v. L?wis wrote:
-
- I can't see that the barrier at contributing is high.
-
- I think this says it all. It now appears obvious to me that people
- inside the mafia
On 3/7/07, Titus Brown [EMAIL PROTECTED] wrote:
On Wed, Mar 07, 2007 at 11:10:22AM +0100, Martin v. L?wis wrote:
- Giovanni Bajo schrieb:
- On 06/03/2007 10.52, Martin v. L?wis wrote:
-
- I can't see that the barrier at contributing is high.
-
- I think this says it all. It now appears
Titus Brown schrieb:
Hi, I just wanted to interject -- when I used the word mafia, I meant
it in this sense:
Informal. A tightly knit group of trusted associates, as of a political
leader: [He] is one of the personal mafia that [the chancellor]
brought with him to Bonn.
(Martin, I
Facundo Batista schrieb:
I finally understood the problem, and build python from the repository,
and made the tests from *this* python (actually, this was an easy step
because I'm on Ubuntu, but *I* would be dead if working in Windows, for
example).
Ok. *Me*, that I'm not ashame of asking
Georg Brandl schrieb:
Of course, the channel would have to be made an official Python development
tool and advertised on e.g. the website. Also, it couldn't hurt if some of the
other devs would frequent it too, then :)
I definitely won't: I don't use IRC (or any other chat infrastructure),
On 3/7/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Me, for example, has an actual question to this list: How can I know,
if I change something in the doc's .tex files, that I'm not broking
the TeX document structure?.
You don't have to know. As a general contributor, just submit your
On Tuesday 06 March 2007 5:42 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
1. Don't suggest to people that, in order to get their patch reviewed,
they should review other patches. The level of knowledge required to put
together a patch is much less than that required to know if a patch
On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
I'm not sure what your point is. My point is that, if you want to
encourage people to become core developers, they have to have a method of
graduating through the ranks - learning (and being taught) as they go.
On Tuesday 06 March 2007 6:00 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
Any ideas for fixing this problem?
A better patch-tracker, better procedures for reviewing patches
surounding this new tracker, one or more proper dvcs's for people to
work off of. I'm not sure about
On 3/6/07, Phil Thompson [EMAIL PROTECTED] wrote:
On Tuesday 06 March 2007 5:49 am, Martin v. Löwis wrote:
Phil Thompson schrieb:
I'm not sure what your point is. My point is that, if you want to
encourage people to become core developers, they have to have a method of
graduating
On Tuesday 06 March 2007 6:15 am, Raymond Hettinger wrote:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they
Stephen J. Turnbull schrieb:
An informal version of this process is how XEmacs identifies its
Reviewers (the title we give to those privileged to authorize commits
to all parts of XEmacs). People who care enough to make technical
comments on *others'* patches are rare, and we grab the
On 3/6/07, Neil Schemenauer [EMAIL PROTECTED] wrote:
Using git-svn to track a SVN repository seems to work well.
I'm not interested in setting up GIT myself, mostly because it doesn't solve
any issues that other dvcs' don't solve, the on-disk repository is mighty
big and it doesn't work very
Phil Thompson schrieb:
2. Publically identify the core developers and their areas of expertise
and responsibility (ie. which parts of the source tree they own).
I doubt this will help. Much of the code isn't owned by anybody
specifically. Those parts that are owned typically find their
Phil Thompson schrieb:
And please be assured that no such obstacle is in the submitters way.
Most patches are accepted without the submitter actually reviewing any
other patches.
I'm glad to hear it - but I'm talking about the perception, not the fact.
When
occasionally submitters ask if
Phil Thompson schrieb:
Of course it's not unreasonable. I would expect to be told that a patch
must have tests and docs before it will be finally accepted. However,
before I add those things to the patch I would like some timely feedback
from those with more experience that my patch is going
Phil Thompson schrieb:
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment people just seem be
saying that's the way it is because that's
Phil Thompson writes:
MvL wrote:
I doubt this will help. Much of the code isn't owned by anybody
specifically. Those parts that are owned typically find their patches
reviewed and committed quickly (e.g. the tar file module, maintained by
Lars Gustäbel).
Doesn't your last
Martin v. Löwis writes:
Stephen J. Turnbull schrieb:
Second, where the stdlib module is closely bound to the core, the
maintainer ends up being the group of core developers. It can't be
any other way, it seems to me.
It might be that individuals get designated maintainers: Guido
On 06/03/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Scott Dial schrieb:
While I understand that this tit-for-tat mechanism is meant to ensure
participation, I believe in reality it doesn't, as the 400-some
outstanding patches you referenced elswhere indicate. I can personally
attest to
Paul Moore schrieb:
Scott Dial schrieb:
While I understand that this tit-for-tat mechanism is meant to ensure
participation, I believe in reality it doesn't, as the 400-some
outstanding patches you referenced elswhere indicate. I can personally
attest to having a patch that is over a year old
Raymond Hettinger schrieb:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they have good use for them.
Ask the
On 3/6/07, Georg Brandl [EMAIL PROTECTED] wrote:
Raymond Hettinger schrieb:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people
Georg Brandl wrote:
As far as I recall, there has been nearly no one who asked for commit rights
recently, so why complain that the entry barrier is too great? Surely you
cannot expect python-dev to got out and say would you like to have commit
privileges?...
I think the number one suggestion
On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote:
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment people just seem be
Jeremy Hylton schrieb:
You can ask whether we should have a plan for increasing the number of
developers, actively seeking out new developers, and mentoring people
who express interest. Would the code be better if we had more good
developers working on it? Would we get more bugs fixed and
Nick Coghlan schrieb:
One thing that did happen though (which the messages from Jeremy Phil
reminded me of) is that I got a lot of direction, advice and assistance
from Raymond when I was doing that initial work on improving the speed
of the decimal module - I had the time available to run
A.M. Kuchling schrieb:
For example, our oldest bug is http://www.python.org/sf/214033, opened
2000-09-11, and is that (x?)? is reported as an error by the SRE regex
parser; the PCRE engine and Perl both accept it. Fixing it requires
changing sre_parse, figuring out what to do (should it be
Martin v. Löwis schrieb:
Nick Coghlan schrieb:
One thing that did happen though (which the messages from Jeremy Phil
reminded me of) is that I got a lot of direction, advice and assistance
from Raymond when I was doing that initial work on improving the speed
of the decimal module - I had
A.M. Kuchling schrieb:
On Tue, Mar 06, 2007 at 09:06:22AM +, Phil Thompson wrote:
My point is simply that the effort required to review patches seems to be a
problem. Perhaps the reasons for that need to be looked at and the process
changed so that it is more effective. At the moment
George Brandl writes:
As far as I recall, there has been nearly no one who asked for
commit rights recently, so why complain that the entry barrier is
too great? Surely you cannot expect python-dev to got out and say
would you like to have commit privileges?...
Why not? It depends on
On Tue, 6 Mar 2007, [ISO-8859-1] Martin v. L?wis wrote:
Yet, in all these years, nobody else commented that the patch was incomplete,
let alone commenting on whether the feature was desirable.
Which actually brings up another point: in many cases even a simple
comment by a core developer:
Ilya Sandler schrieb:
I'd also suggest that request for test cases/docs comes after
(or together with) suggestion that a feature is desirable in the first
place.
It depends. I was going through some old patches today, and came
across one that added a class to heapq. I couldn't tell (even
after
Nick I don't know whether or not there is anything specific we can do
Nick to encourage that kind of coaching/mentoring activity, but I know
Nick it was a significant factor in my become more comfortable with
Nick making contributions.
Martin While there was no explicit
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
1. Public identification will not help, because:
2. most code isn't in the responsibility of anybody (so publically
identifying responsibilities would leave most code unassigned), and
3. for the code that has some
dustin In summary, create a layer of volunteer, non-committing
dustin maintainers for specific modules who agree to do in-depth
dustin analysis of patches for their areas of expertise, and pass
dustin well-formed, reviewed patches along to committers.
One problem with this sort
On Tue, Mar 06, 2007 at 01:03:39PM -0600, [EMAIL PROTECTED] wrote:
Could the Summer of Code be used as a vehicle to match up current developers
with potentially new ones? The svn sandbox (or a branch) could serve as a
place for developers to get their feet wet. Perhaps Raymond can comment on
On Tue, Mar 06, 2007 at 01:51:41PM -0600, [EMAIL PROTECTED] wrote:
dustin In summary, create a layer of volunteer, non-committing
dustin maintainers for specific modules who agree to do in-depth
dustin analysis of patches for their areas of expertise, and pass
dustin
Neal Norwitz wrote:
I recognize there is a big problem here. Each of us as individuals
don't scale. So in order to get stuff done we need to be more
distributed. This means distributing the workload (partially so we
don't burn out). In order to do that we need to distribute the
Terry Reedy schrieb:
It would also be helpful if the new tracker system could produce a list of
module-specific open items sorted by module, since that would indicate
modules needing attention, and I could look for a batch that were
unassigned.
The new tracker will initially have the same
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy schrieb:
| It would also be helpful if the new tracker system could produce a list
of
| module-specific open items sorted by module, since that would indicate
| modules needing attention, and I could look
On Tuesday 06 March 2007 20:24, Martin v. Löwis wrote:
It might be that individuals get designated maintainers: Guido
maintains list and tuple, Tim maintaines dict, Raymond maintains
set, I maintain configure.in. However, I doubt that would work in
practice.
That approach would simply give us
Martin If, for Modules, you want a more fine-grained classification,
Martin it would be possible to add new categories, or add another field
Martin affected modules (multi-list, I assume).
Why not add some tag capability to the new tracker (maybe the generic
keywords field you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 6, 2007, at 7:51 PM, [EMAIL PROTECTED] wrote:
Why not add some tag capability to the new tracker (maybe the generic
keywords field you mentioned would suffice)? People could attach
whatever
tags seem appropriate. Limiting the tags to a
On 3/6/07, Ron Adam [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
I'm looking forward to a new tracker and hope it manages single projects...
(patches and bugs) better. It would be great if we could search for items
based on possibly the following conditions.
The best place to discuss these
On 3/6/07, Terry Reedy [EMAIL PROTECTED] wrote:
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
1. Public identification will not help, because:
2. most code isn't in the responsibility of anybody (so publically
identifying responsibilities would leave most code
Neal Norwitz wrote:
On 3/6/07, Ron Adam [EMAIL PROTECTED] wrote:
Neal Norwitz wrote:
I'm looking forward to a new tracker and hope it manages single
projects...
(patches and bugs) better. It would be great if we could search for
items
based on possibly the following conditions.
The
On Mon, Mar 05, 2007 at 12:58:13PM -0600, [EMAIL PROTECTED] wrote:
I'm not much of a version control wonk. How would these help? Can't the
folks who need such stuff do some sort of anonymous svn checkout?
The external developers can commit changes, revert them, etc. to their
local repository,
A few meta-points:
On 07:30 pm, [EMAIL PROTECTED] wrote:
2. Publically identify the core developers and their areas of expertise
and
responsibility (ie. which parts of the source tree they own).
I'd like to stress that this is an important point; although we all know
that Guido's the
On Monday 05 March 2007 8:09 pm, Oleg Broytmann wrote:
On Mon, Mar 05, 2007 at 07:30:20PM +, Phil Thompson wrote:
1. Don't suggest to people that, in order to get their patch reviewed,
they should review other patches. The level of knowledge required to put
together a patch is much less
A.M. Kuchling [EMAIL PROTECTED] wrote:
At PyCon, there was general agreement that exposing a read-only
Bazaar/Mercurial/git/whatever version of the repository wouldn't be
too much effort, and might make things easier for external people
developing patches. Thomas Wouters apparently has
On Monday 05 March 2007 9:38 pm, Thomas Wouters wrote:
On 3/5/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
From http://ivory.idyll.org/blog/mar-07/five-things-I-hate-about-python
4. The patch mafia. I like everyone on python-dev that I meet,
but somehow it is annoyingly
Neil Schemenauer [EMAIL PROTECTED] wrote:
Using git-svn to track a SVN repository seems to work well. It
would be trivial to setup a cron job on one of the python.org
machines that would create a publicly accessible repository.
I guess Andrew was looking for specific instructions. Install
Phil Thompson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| On Monday 05 March 2007 6:46 pm, A.M. Kuchling wrote:
| FWIW, I have a related perception that we aren't getting new core
| developers. These two problems are probably related: people don't get
| patches processed and
On Mon, Mar 05, 2007, Terry Reedy wrote:
Tracker item review is an obvious bottleneck in Python development.
In particular, reviewing patches appears not to be nearly as
self-motivating as writing them, and other activities. So I think the
PSF should pay one or more people to do so.
On 05/03/2007 20.30, Phil Thompson wrote:
1. Don't suggest to people that, in order to get their patch reviewed, they
should review other patches. The level of knowledge required to put together
a patch is much less than that required to know if a patch is the right one.
+1000.
2.
On 05/03/2007 19.46, A.M. Kuchling wrote:
At PyCon, there was general agreement that exposing a read-only
Bazaar/Mercurial/git/whatever version of the repository wouldn't be
too much effort, and might make things easier for external people
developing patches.
I really believe this is just
On 3/5/07, Giovanni Bajo [EMAIL PROTECTED] wrote:
On 05/03/2007 19.46, A.M. Kuchling wrote:
At PyCon, there was general agreement that exposing a read-only
Bazaar/Mercurial/git/whatever version of the repository wouldn't be
too much effort, and might make things easier for external people
On 3/5/07, Brett Cannon [EMAIL PROTECTED] wrote:
On 3/5/07, Giovanni Bajo [EMAIL PROTECTED] wrote:
On 05/03/2007 19.46, A.M. Kuchling wrote:
At PyCon, there was general agreement that exposing a read-only
Bazaar/Mercurial/git/whatever version of the repository wouldn't be
too much
On Mon, Mar 05, 2007 at 11:30:06PM +, Neil Schemenauer wrote:
I guess Andrew was looking for specific instructions. ...
I'm happy to let the ball sit in Thomas's court until the Bazaar
developers come out with 0.15 and run their conversion on the SVN
repository. There's no burning hurry
On Mon, Mar 05, 2007 at 08:50:46PM -, [EMAIL PROTECTED] wrote:
is indicative of a failure of the community. A good deal of the
discussion here in recent months has either been highly speculative, or
only tangentially related to Python's development, which is ostensibly
its topic. We
Giovanni Bajo [EMAIL PROTECTED] wrote:
On 05/03/2007 20.30, Phil Thompson wrote:
2. Publically identify the core developers and their areas of expertise and
responsibility (ie. which parts of the source tree they own).
I think this should be pushed to its extreme consequences for the
On 3/5/07, A.M. Kuchling [EMAIL PROTECTED] wrote:
[snip]
One problem may be that there *aren't* maintainers for various
subsystems; various people have contributed bugfixes and patches for,
say, urllib, but I have no idea what single person I would go to for a
problem.
Is it worth creating a
A.M. Kuchling schrieb:
FWIW, I have a related perception that we aren't getting new core
developers. These two problems are probably related: people don't get
patches processed and don't become core developers, and we don't have
enough core developers to process patches in a timely way. And
Phil Thompson schrieb:
1. Don't suggest to people that, in order to get their patch reviewed, they
should review other patches. The level of knowledge required to put together
a patch is much less than that required to know if a patch is the right one.
People don't *have* to review patches.
[EMAIL PROTECTED] schrieb:
The patches list really ought to be _this_ list. The fact that it isn't
is indicative of a failure of the community.
I disagree that python-dev isn't the patches list. People often discuss
patches here (although much discussion is also in the tracker).
One
Phil Thompson schrieb:
I'm not sure what your point is. My point is that, if you want to encourage
people to become core developers, they have to have a method of graduating
through the ranks - learning (and being taught) as they go. To place a very
high obstacle in their way right at the
Phil Thompson schrieb:
Any ideas for fixing this problem?
A better patch-tracker, better procedures for reviewing patches surounding
this new tracker, one or more proper dvcs's for people to work off of. I'm
not sure about 'identifying core developers' as we're all volunteers, with
dayjobs
Neil Schemenauer schrieb:
I guess Andrew was looking for specific instructions. Install git
and git-svn. For Debian stable, you can get them from
http://backports.org/debian/pool/main/g/git-core/.
Initialize the repository:
git-svn init http://svn.foo.org/project/trunk
Fetch
Collin Winter schrieb:
It would also be helpful to have some loose guidelines/requirements
for how to become a module maintainer (e.g., we're looking for the
following traits...).
That is easy to answer: Review the patches of the module, and post
a message to python-dev about your findings
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they have good use for them.
Ask the Georg-bot how readily he was
Scott Dial schrieb:
While I understand that this tit-for-tat mechanism is meant to ensure
participation, I believe in reality it doesn't, as the 400-some
outstanding patches you referenced elswhere indicate. I can personally
attest to having a patch that is over a year old with no core
Raymond Hettinger schrieb:
[Phil Thompson]
I think a lot of people care, but many can't
do anything about because the barrier to entry is too great.
Do you mean commit priviledges? ISTM, those tend to be
handed out readily to people who assert that they have good use for them.
Ask the
Giovanni Bajo writes:
On 05/03/2007 20.30, Phil Thompson wrote:
1. Don't suggest to people that, in order to get their patch
reviewed, they should review other patches. The level of knowledge
required to put together a patch is much less than that required
to know if a patch is the
Giovanni Bajo writes:
On 05/03/2007 19.46, A.M. Kuchling wrote:
At PyCon, there was general agreement that exposing a read-only
Bazaar/Mercurial/git/whatever version of the repository wouldn't be
too much effort, and might make things easier for external people
developing
On 5 Mar, 2007, at 19:58, [EMAIL PROTECTED] wrote:
amk Any ideas for fixing this problem?
Not a one.
amk Tangentially related:
amk At PyCon, there was general agreement that exposing a read-
only
amk Bazaar/Mercurial/git/whatever version of the repository
wouldn't be
99 matches
Mail list logo
