This is extraordinarily discouraging. This is the second time that I have devoted tremendous energy to a patch, trying to coordinate with core developers, not doing any work until I get the green light from core developers regarding an implementation plan (trying to avoid this very same eventuality), only to be told, after working code + tests + docs have been attached to the ticket, after several iterations of feedback: nope, this is not the way that we want to do this policy- wise, there's this other approach we want to take, so never mind.
I can understand going through the bureaucratic rigmarole that comes with contributing to Django--in fact, I support it--but to go through all of the discussion, justification, and *time* required to get a simple bug fix checked in (no, this really *is* a bug--look, there are five other tickets filed. sure, let's analyze the problem from every angle. sure, I'll rewrite it so it matches exactly your specifications.), only to be told that someone who wasn't even involved in this ticket and discussion *at all* until now thinks it isn't worth it, makes a guy like me want to tear his hair out. You say that this is "in the best interests of Django", but you must know that Django will suffer if people like me stop wanting to contribute because of things like this. I accept your apology, truly, but can I ask something else of you? Don't treat your contributors' time as something so easy to throw away. You and I (and others) have been talking about this for days. I have spent at least a day coding and analyzing. When the whole thing gets thrown away because of an IRC discussion, I don't know what to think. Carl, I asked you specifically in this very thread whether your new idiom would prevent this fix from getting checked in, before I started coding, and you answered that you "didn't think so". Should I have read that differently, more in the negative than in the affirmative? Perhaps, and I certainly will ask for clarification from you in the future. But you also gave me the green light to go ahead an write the patch in a manner that we discussed. Even if sometimes in the final event your original decision to pursue a certain path might prove not to be optimal, can I ask you to stick with it, so that people like me don't have to worry about the rug being pulled out from underneath us at the last moment? To place this in perspective: this is a *small* bug fix that adds six (6) lines of code to the file and prevents exceptions being raised to the user in the admin (and elsewhere). The "problematic" special case here is a rare edge case that, conceivably, could even be left out from the implementation. And yet, as someone who is still trying to figure out what kind of effort to put into contribute to Django, for me it is seriously discouraging for the work to be discarded. > In terms of what's best for Django, I think Alex is right on this one, so I > plan to just work on the better fix How often has it been the case that some really cool new feature gets delayed because the core developer who was working on it was unable to dedicate the time they thought they would be able to? Can I help move it along, can you work with me to write it? Why can't we check this one in, close two tickets (as well as satisfying three or four duplicates) and then move on to the more definitive fix? Regards, Eduardo PS I wrote much of this in anger, so it is rather more critical than anything I would normally post, but I think that it needs to be said. On Apr 28, 4:28 pm, Carl Meyer <c...@oddbird.net> wrote: > Hi Eduardo, > > On 04/28/2011 12:35 PM, legutierr wrote: > > > I just added a new patch in response to Carl's comments on the ticket. > > >http://code.djangoproject.com/ticket/13091 > > So, in the process of reviewing and tweaking this patch for commit, I > checked in the #django-dev IRC channel for any other core dev opinionsm > since I didn't feel 100% confident that we were doing the right thing > here. I talked through the issue with Alex Gaynor, and he successfully > convinced me that we aren't. Specifically: > > 1. We have an idea in mind, as I mentioned above, for a new > modelform-validation idiom that would solve this problem fully, by > requiring tweaks to the model to happen pre-validation and then > validating the full model. > > 2. If we implement the new idiom, and convert the admin to use it, then > anyone who runs into the problems with the current partial-validation > scheme in their own code can simply switch to the new recommended idiom. > Nobody will be stuck. > > 3. The current proposed patch on #13091 only improves the current > situation very marginally; there are a lot of cases it still wouldn't > catch (anytime a field involved in a unique-together is modified > post-validation and pre-save, and the odd exclusions for default/blank > fields). It's very much an incomplete fix, and yet it introduces new > complexity both to the code and the documentation, when we already have > a better alternative fix in mind. > > So I apologize for leading you to spend time on that patch and then > switching gears. In terms of what's best for Django, I think Alex is > right on this one, so I plan to just work on the better fix rather than > committing the current patch on #13091. > > Carl -- 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.
