On Tue, 2008-11-18 at 05:45 -0800, Matt Brown wrote: > I have a bit of confusion about how possibly "non-trivial" patches are > supposed to be handled. > > Common practice here seems to be that if someone wants to propose a > change and has a patch ready, they open a ticket first and then a > discussion here. The docs indicate that if the patch is non-trivial > (for some definition of non-trivial), the author should show that a > discussion of alternate solutions occurred here. I assume that the > ticket description is where this evidence goes. > > My question is: if I have a non-trivial patch, does the alternate- > solutions discussion need to occur before I post my patch to Trac, or > is it all right to create the ticket first and follow up with linkage > later?
That sounds fine. There's no hard and fast procedure. What we're trying to accomplish is this: when design discussions occur in a ticket there are multiple problems. Firstly, only the people who happen to notice the ticket will see the discussion. I make a point of reading every single change to Trac tickets and even then I'll often not notice that a particular ticket isn't really fleshed out as to the design or the patch is just a proto-implementation. Those of us who do follow and contribute to those discussions have one forum we need to follow to keep up on that: django-developers. Yes, there's the slight drawback that everybody then has to see every conversation and there's no keeping it contained just in that ticket. Being forced to be exposed to the development process by being subscribed to the developers mailing list isn't really a downside that gets a lot of sympathy, though. The second problem is when there really isn't any consensus yet, even amongst those with non-pony ideas to add. You end up with a ticket with anywhere from 20 to 100 comments with multiple conflicting threads of conversation and it's a disaster to try and read through (particularly thanks to Trac's displaying of changes to the CC list as just as important as substantive comments). A mailing list makes it quite a bit easier to read through that stuff I've found (kind of confirming the old saw that a web browser really isn't an ideal UI for much beyond scrolling through web pages). So, by all means post your patch. If it's a change that's likely to have alternate approaches or change something dramatic, you might well want to start a thread here as well. That sometimes leads to disasters where people attempt to respond in both places (or sometimes people stop responding on the mailing list when things aren't going as smoothly as they like and just post a comment in the ticket with responses to the mailing list -- that's really annoying and fundamentally counter-productive). But that's not common and can be managed. You might sometimes get asked to start a django-developers thread on the ticket if it looks clean, but appears trickier than that to whichever maintainer reads through it. Basically, though, the idea is to not overwhelm people with content or procedure, but to make sure that as many of the relevant eyes as possible get to see changes before they happen. So just use your best judgement. Nobody gets flamed for trying to do the right thing and listening to feedback (repeat offenders are just auditioning for jobs as Crispy Chicken pieces, obviously, but that's just the Darwin Award in action, really). Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
