On Sat, Apr 17, 2010 at 7:14 PM, George Sakkis <george.sak...@gmail.com> wrote: > On Apr 17, 5:35 am, "Tom X. Tobin" <tomxto...@tomxtobin.com> wrote: >> On Fri, Apr 16, 2010 at 10:10 PM, Russell Keith-Magee >> >> <freakboy3...@gmail.com> wrote: >> > However, at this point, I would like to tell you a story about four >> > people named Everybody, Somebody, Anybody, Nobody. >> >> This is exactly why I try not to bitch too much about Django's >> development process. It's very easy to complain, but it's not quite >> so easy to "shut up and show me the code". > > My point is that unfortunately this is not enough. The 400 languishing > patches have been submitted by people who did exactly that, they "shut > up and showed the code", possibly without ever complaining in this > list. And not only that but their patches (or some percentage of them > at any rate) have been "accepted" or became "ready for checkin" at > some point. How come a developer finds the time to review a patch, > accept it, consider it ready for checkin but not actually commit it ?
For the record, there are 62 tickets marked ready for checkin, not 400 [1]. 29 of those are documentation and translation patches (5 of which are specifically marked for inclusion in 1.2). [1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&order=priority&stage=Ready+for+checkin On top of that, the Ready For Checkin status doesn't mean that a member of the core team has reviewed a patch. It means that someone -- anyone -- thinks the patch is ready for checkin. There's no guarantee that a Ready For Checkin patch is *actually* ready for checkin. If you do a survey of the Ready For Checkin patches, you'll find tickets that don't have test cases, or add features that aren't documented, or make a significant changes that haven't been discussed on django-dev. If I were to sit down and work through that list, I guarantee I wouldn't end up making 62 commits to trunk using the material that has been provided on those tickets. I would also point out the folly of looking at raw ticket counts. Python (the language) has 1078 tickets in the "having patch" status, and 96 in the "needing review" status. Does this mean that Python is a project in crisis? Yes, there is a ticket backlog. Yes, this means there is a lot of work that needs to be done. What we need is people volunteering to actually do that work. However, as I've already indicated in this thread, much of that work could be done without any change in current project policy - we just needs people to actually do the work. My dream outcome would to be in the situation where I don't *ever* have to spend time on Trac trying to work out if the ticket that has been marked Ready For Checkin is *actually* ready for checkin. Give me a rich vein of trunk ready tickets that has been reviewed by someone whose reputation I know and trust, and believe me -- I will use it. > Healthy projects don't need a separately maintained fork/branch on > github or bitbucket just to review and apply patches. They open up > their gates and they invite more contributors to the development > process (in a controlled manner of course) so that they can keep up > with the increasing volume of external contributions. The flipside of this is that too many cooks spoil the broth. If we want to maintain a high quality product, we can't just add a dozen new developers to the core team. I would also point out that even in projects that do have large teams with the commit bit, access to the "core trunk" is generally only made available to a restricted subset of the entire team. Alternatively, some sort of code review process is used to ensure that multiple team members (occasionally, specially blessed team members) check patches before they are committed. There's a lot more to commit policies in open source than raw team size. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.