> > I think it's very easy to underestimate the amount of work required in > > checking in a patch. It seems like a simple handful-of-lines patch like > > yours > > should be a no-brainer, but there's a whole bunch of steps I (or any > > other bug fixer) has to go through before we can check a fix in: > > > And adding new developers to a project is *hard*. We want to be completely > > sure > > that we trust someone before giving them commit access. Sure, we could > > switch to > > a model like PHP where anyone with a patch gets commit access, but then we'd > > risk turning out like, well, PHP. > > > Finally: this is open source. Nothing prevents you from modifying your > > code in any way you want; you don't need my permission or the checkin > > of your patch in order to use it. > > Fully agree.. What I am interested in finding out is if this really is > a good direction to turn, maintaning what essentially is a private > fork, and then use it in a production environment? The issue with it > being in the "official" django tree is that there are alot more people > out there using that codebase and improving on it. Keeping my own > fork would mean less to no peer review. >
I think all the points being made are valid. There are people who want to help, and to try to reduce the bottlenecks and the pressure on the core developers wherever they can. We all acknowledge what a hard job it is to keep on top of things with a limited number of hours in the day. What's the thinking on documentation-only patches? While they are just as worthy of review and critical assessment as code patches, there is less of a concern about affecting trunk stability, and less impact analysis work needed. Could there be a more streamlined process to get them reviewed and into trunk? I couldn't see anything in the current tracker that allows such patches to be identified and fast-tracked. Another thing I've noticed is that tickets with small, low-risk patches (which in theory should be easier and quicker to close) are not that easy to single out in the tracker, sharing equal space in the Trac reports with weightier patches which are harder to assess and finalise. Closing out the easier tickets quickly would benefit everyone by improving the signal/noise ratio - how could this be addressed? I've only recently started using Django (yay!) and been trying to help out triaging tickets, suggesting patches etc. in accordance with the documented guidelines. Hope I'm not stepping on any toes. Please set me straight if I've missed anything obvious. Regards, Vinay Sajip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
