On Thu, Oct 22, 2009 at 3:22 AM, mrts <mrts.py...@gmail.com> wrote: > > On Oct 20, 7:19 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote: > > Django Bug Days > --------------- > > At regular intervals, say twice a month on Saturdays, > set aside 2-3 hours for IRC-based bug hunting sprints.
Yes, we should have more regular sprints. However, you need to remember that organizing things takes time, and time is one of the things that the core team is seriously lacking. That said, Jeremy Dunck has recently expressed an interested in helping to coordinate organization of a regular sprint schedule. If you want to help out organizing these (including finding a time slot that is convenient for the relevant timezones), you might want to get in touch with him - or alternatively, just go ahead and organize them yourself. You don't need core blessing to organize a bug-squashing party. If you want to confirm the availability of the core for such an event, just ask. Talk of a "once every two weeks" schedule is possibly a little optimistic if you expect *all* the core developers to turn up every time, but if you are just talking about setting up a regular time and place where people will know that there will be some bug-catching fun in IRC, that sounds like a great idea. Build it and they will come. :-) > A DVCS mm-tree > -------------- Let me tell you a store about three people named Everybody, Anybody, Somebody and Nobody. There was a job to be done. Everybody agreed it should be done. Anybody could have done it. Somebody should have done it. Nobody actually did it. :-) An mm-style tree could certainly be a useful resource for the core. Merging trunk-ready patches from a git/hg mm-branch would certainly be easier than doing the Trac patch dance. However: 1) Someone actually needs to maintain the tree. Don't underestimate the time required to do this - it will be just as time-consuming as maintaining the trunk, and the core can't compel anyone to do anything. 2) Someone needs to keep maintaining the tree over a long period of time. It's not much help if the mm-tree exists for a week of enthusiasm, then dies out. 3) The Someone in question needs to have the right skills and taste. It's no good having an mm-tree that integrates patches that the core consistently rejects. 4) I can almost guarantee you that if Someone actually met the first three criteria, they would be given the commit bit. It's no good saying "someone should". Someone actually needs to do it. If you want to do it, go right ahead. Again - build it and they will come. > Code review > ----------- > > Code reviews are super useful, because, in the end of the > day, we communicate in code. > > I have no idea if integrating a code review tool with trac > is feasible, so if this looks attractive, the only realistic > way to adopt it would be a social-coding-site-centric > process - patches remain in trac tickets, but it's highly > recommended to maintain corresponding branches in GitHub or > BitBucket, so that community members can write code reviews > there. Personally, I'm not convinced that a code review tool will actually improve anything - it strikes me as a technical solution to something that is actually a social problem. The social problem is that there are people that I trust, and the opinions of those people are very important when I review a patch. Code reviews are useful - when they come from someone you trust. A code review from John Q. Random Hacker is just as likely to be noise as useful feedback. The process of getting my (or anyones) trust is a process of accretion over time - I trust X because I've seen their contributions over several years; I don't trust Y because they have consistently shown poor taste; I don't know if I trust Z because I haven't seen enough of their work. This trust isn't a simple algorithm - it's a personal perception issue. A small number of significant patches could do more to influence trust than a long history of less significant patches. There might be some potential for tool support in this area - but it certainly isn't as simple as just adopting a code review tool. In summary, your mail (and, really, this entire thread) has contained a lot of "the core should", or "someone should". The source of my (and, I suspect Jacob's) frustration is that these comments aren't especially helpful. We know all the things that we *could* do - what we don't have is the time to deliver on all these ideas. On the other hand, saying "I am going to" is extraordinarily helpful. Saying "I already have" is even better. You don't need the core's blessing to do anything. Allow me to assure you that if you develop and maintain a resource that is useful, people - including the core - will use it. The hard part has never been coming up with ideas. The hard part is delivering. Build it, and they will come. 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-developers@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 -~----------~----~----~----~------~----~------~--~---
