On Sun, Apr 18, 2010 at 12:10 AM, George Sakkis <george.sak...@gmail.com> wrote: > 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.
It can, but we've configured it not to. Again, this is territory that is well covered in django-dev history, but in brief: there is a tradeoff. By leaving Trac open, it means anyone can contribute, but the states aren't necessarily accurate. Alternatively, we can lock down Trac, making the ticket states completely accurate, but it relies upon trusted individuals dedicating the time to doing official triage work -- which also means that there is an increased likelyhood that a patch *won't* get triaged (or won't get triaged quickly), because only a select few can actually do the work. So - we need to make a choice. Which is better? Having a Trac that is 100% accurate whenever a judgement is made, but that only has 75% of tickets triaged? Or a ticket that has 100% of tickets triaged, but is only 75% accurate? We've opted for the latter, and rely upon crowd effects (re-reporting of issues, repeated threads on django-users, etc) to identify critical problems that require attention. > 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. The plural of anecdote is not data. I'm glad you had a good experience with Python's ticket tracker. I'm sorry you've had a bad experience with Django's. However, I could easily point at a number of tickets that were closed fixed within hours of original reporting because they caught the attention of a core developer at the right time. I can also point at tickets in Python's ticket repository that have been languishing for years. The reason I know there are long lived tickets in Python is because I've submitted some of them. In fact, the very first ticket that I submitted to Python's tracker [1] took 9 months before it even got triaged. It still hasn't been resolved, and I submitted it in 2006. This doesn't mean that Python's development process is flawed. It means that I haven't been actively pursuing a resolution to this ticket inside the Python community. [1] http://bugs.python.org/issue1521051 >> > 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. We already have a policy for giving people commit access in a controlled manner [2], and lots of suggestions on the same page for what you can do to contribute to prove you're worthy of commit access. If anyone can provide concrete suggestions of any other ways we can encourage skilled individuals to become long term contributors worthy of consideration for commit access, I'm all ears. [2] http://docs.djangoproject.com/en/1.1/internals/contributing/#commit-access 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.
