On Apr 17, 3:47 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> 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... > > 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. If the tracker fields are not to be trusted as authoritative, why give public access to them in the first place ? The Python tracker allows only developers to modify most fields, I guess Trac should have a way to control access too. > 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? For the record, if you count all tickets with patches, then Django has 992 (they drop to 616 after excluding those that need improvement, documentation and tests and to 406 when considering only the "accepted" and "ready for checkin" stage - assuming these numbers mean anything). That's pretty close to the ticket count of a much larger in size and complexity project. Speaking of Python (the language) contribution process, I had the recent pleasant experience of having a patch of mine accepted for Python 2.7. It's not a bug fix, it's a new feature and so it could have easily been ignored, postponed after the release or simply dismissed as unnecessary but it wasn't; within two weeks since the original submission and with great responsiveness and feedback from the core dev that reviewed it, it was committed a few days before the first beta. Quite a different experience from Django. > 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. Again, unless there is a good reason for giving public access to all fields, make them accessible only to trusted members and let the official tracker become this rich vein of trunk ready tickets. Even if nothing else changes, we should at least be able to trust the report counts and have a more accurate view of the project's status. > > 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. Agreed, that's why I stressed "in a controlled manner". The question is what prevents the influx of new skilled and trustworthy blessed members, the institution of code review policies and everything else that a large project needs to flourish. George -- 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.
