Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
On Tue, Apr 20, 2010 at 9:20 AM, orokusaki wrote: > Q: Why do folks turn away constructive criticism with a sarcastic > snicker? > A: "None but the well-bred man know how to confess a fault, or > acknowledge himself in an error." Careful there, some devs might tweet-call troll while you're not watching. It's not like anyone warned them about the attitude ;) J -- 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.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
Thanks a lot for standing by your list policy here BTW. On Apr 19, 8:23 pm, Russell Keith-Magee wrote: > On Tue, Apr 20, 2010 at 7:23 AM, Bitrot McGee wrote: > > Q: When will Django finally have every feature I want? > > A: "Ambition has its disappointments to sour us, but never the good > > fortune to satisfy us." > > > Q: What the fuck is taking so long? > > A: "As we enjoy great advantages from the inventions of others, we > > should be glad of an opportunity to serve others by any invention of > > ours; and this we should do freely and generously." > > > Q: Should certain Trac fields only be editable by commiters? > > A: "Those who would give up Essential Liberty to purchase a little > > Temporary Safety, deserve neither Liberty nor Safety." > > > -- > > > I hope this attempt to lighten the mood isn't too distracting. > > You, good Sir, win the internets. :-) > > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
Since you have a PhD in computer science and you're seven years older than me, and you work for me, for free, while I have exactly zero computer science credits (or anything related), I think "the internets" award goes to you. On Apr 19, 8:23 pm, Russell Keith-Magee wrote: > On Tue, Apr 20, 2010 at 7:23 AM, Bitrot McGee wrote: > > Q: When will Django finally have every feature I want? > > A: "Ambition has its disappointments to sour us, but never the good > > fortune to satisfy us." > > > Q: What the fuck is taking so long? > > A: "As we enjoy great advantages from the inventions of others, we > > should be glad of an opportunity to serve others by any invention of > > ours; and this we should do freely and generously." > > > Q: Should certain Trac fields only be editable by commiters? > > A: "Those who would give up Essential Liberty to purchase a little > > Temporary Safety, deserve neither Liberty nor Safety." > > > -- > > > I hope this attempt to lighten the mood isn't too distracting. > > You, good Sir, win the internets. :-) > > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
I think I can play this: Q: Why is so much valuable time wasted on insulting other people, instead of making money? A: "We are all born ignorant, but one must work hard to remain stupid." Q: Why do folks turn away constructive criticism with a sarcastic snicker? A: "None but the well-bred man know how to confess a fault, or acknowledge himself in an error." Finally: Q: Why are there those who micro manage, those who play follow the leader, and those who have a vacation home in Juno Beach FL, a boat, a Jaguar XKR, 2-3 months of vacation per year, and a wife who is quitting her job to spend time on helping endangered loggerhead sea turtles, just because she can? A: "All mankind is divided into three classes: those that are immovable, those that are movable, and those that move." Giving money to sign holders is never a good idea, but when I handed a filthy bum a dollar fifty or so in change once without his solicitation, and he threw it on the ground in prideful ignorance, I realized then what separated him from me. On Apr 19, 5:23 pm, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so long? > A: "As we enjoy great advantages from the inventions of others, we > should be glad of an opportunity to serve others by any invention of > ours; and this we should do freely and generously." > > Q: Should certain Trac fields only be editable by commiters? > A: "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > > -- > > I hope this attempt to lighten the mood isn't too distracting. > > To the core team: your efforts are so, so appreciated. Benjamin > Franklin (et al.) know that you have a lot of other things you could > be doing, and that working on Django is too often thankless. Thank > you! You all deserve many, many IRL ponies. A herd of ponies. > > To everyone: I'd like to close with a quote by Richard Penn: "We must, > indeed, all hang together, or assuredly we shall all be forced to use > Rails separately." Please keep that in mind. It seems relevant for > some reason. > > ~Bitrot > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
On Mon, 2010-04-19 at 15:44 -0500, Richard Laager wrote: > In the end, *my* requirement is that I have *some place* to put > validation code that 1) can see the whole model instance, 2) will be run > from the admin interface, and 3) will return nice validation failures to > the user (not throw exceptions that will give the user a 500 error and > send me an email). It's looking like this is a case of user error. I think my Django 1.2 checkout is simply too old. As I went to build a test case with HEAD, I found it works to define clean(), as documented. Sorry for the noise. I'll come back if I find a real bug. Richard signature.asc Description: This is a digitally signed message part
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
his thread will be a very good overview of the thread Re Re Re Re Benjamin Franklin Re Re Benjamin Franklin High Level Discussion about the Future of Django. class reboot(High_Level_Discussion_about_the_Future_of_Django): pass :/ On 19 abr, 23:58, rebus_ wrote: > On 20 April 2010 01:23, Bitrot McGee wrote: > > > > > > > Q: When will Django finally have every feature I want? > > A: "Ambition has its disappointments to sour us, but never the good > > fortune to satisfy us." > > > Q: What the fuck is taking so long? > > A: "As we enjoy great advantages from the inventions of others, we > > should be glad of an opportunity to serve others by any invention of > > ours; and this we should do freely and generously." > > > Q: Should certain Trac fields only be editable by commiters? > > A: "Those who would give up Essential Liberty to purchase a little > > Temporary Safety, deserve neither Liberty nor Safety." > > > -- > > > I hope this attempt to lighten the mood isn't too distracting. > > > To the core team: your efforts are so, so appreciated. Benjamin > > Franklin (et al.) know that you have a lot of other things you could > > be doing, and that working on Django is too often thankless. Thank > > you! You all deserve many, many IRL ponies. A herd of ponies. > > > To everyone: I'd like to close with a quote by Richard Penn: "We must, > > indeed, all hang together, or assuredly we shall all be forced to use > > Rails separately." Please keep that in mind. It seems relevant for > > some reason. > > > ~Bitrot > > /thread > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
On 20 April 2010 01:23, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so long? > A: "As we enjoy great advantages from the inventions of others, we > should be glad of an opportunity to serve others by any invention of > ours; and this we should do freely and generously." > > Q: Should certain Trac fields only be editable by commiters? > A: "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > > -- > > I hope this attempt to lighten the mood isn't too distracting. > > To the core team: your efforts are so, so appreciated. Benjamin > Franklin (et al.) know that you have a lot of other things you could > be doing, and that working on Django is too often thankless. Thank > you! You all deserve many, many IRL ponies. A herd of ponies. > > To everyone: I'd like to close with a quote by Richard Penn: "We must, > indeed, all hang together, or assuredly we shall all be forced to use > Rails separately." Please keep that in mind. It seems relevant for > some reason. > > ~Bitrot > /thread -- 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.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
Brilliant! Absolutely brilliant! - Gabriel On Apr 19, 4:23 pm, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so long? > A: "As we enjoy great advantages from the inventions of others, we > should be glad of an opportunity to serve others by any invention of > ours; and this we should do freely and generously." > > Q: Should certain Trac fields only be editable by commiters? > A: "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > > -- > > I hope this attempt to lighten the mood isn't too distracting. > > To the core team: your efforts are so, so appreciated. Benjamin > Franklin (et al.) know that you have a lot of other things you could > be doing, and that working on Django is too often thankless. Thank > you! You all deserve many, many IRL ponies. A herd of ponies. > > To everyone: I'd like to close with a quote by Richard Penn: "We must, > indeed, all hang together, or assuredly we shall all be forced to use > Rails separately." Please keep that in mind. It seems relevant for > some reason. > > ~Bitrot > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Wherein Benjamin Franklin answers questions pertaining to the Django development process
On Tue, Apr 20, 2010 at 7:23 AM, Bitrot McGee wrote: > Q: When will Django finally have every feature I want? > A: "Ambition has its disappointments to sour us, but never the good > fortune to satisfy us." > > Q: What the fuck is taking so long? > A: "As we enjoy great advantages from the inventions of others, we > should be glad of an opportunity to serve others by any invention of > ours; and this we should do freely and generously." > > Q: Should certain Trac fields only be editable by commiters? > A: "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > > -- > > I hope this attempt to lighten the mood isn't too distracting. You, good Sir, win the internets. :-) 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.
Re: Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
Realizing my original statement I was regarding this thread, in this thread, it's obvious that this has gone completely off track. I might have to take back everything I thought about this being useful. If you want to address a SPECIFIC concern, it makes sense to do that under its own topic. Think of this mailing list like a forum, as, after all, many of us browse it just like one. When a "thread" happens to have 12 different topics it loses its value fast. On Apr 19, 3:44 pm, Richard Laager wrote: > In the end, *my* requirement is that I have *some place* to put > validation code that 1) can see the whole model instance, 2) will be run > from the admin interface, and 3) will return nice validation failures to > the user (not throw exceptions that will give the user a 500 error and > send me an email). > > A) Is this an unreasonable pony? If so, why? > B) If not, how can I implement this such that it will get accepted? > > I'd like to have it in for 1.2 if possible, as the model validation > interfaces are new. Once released, there will be more > backwards-compatibility guarantees to maintain. > > > > > > On Mon, 2010-04-19 at 10:53 -0500, James Bennett wrote: > > On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > > > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > > >> With all respect, you still haven't addressed my main concern: You > > >> told me that it was because of backward compatibility that this simple > > >> change couldn't be put in the trunk. It is backward compatible. If I'm > > >> wrong, it would suffice to have a simple explanation of what it > > >> breaks. > > > > I'd like to second this question. orokusaki suggested a couple of things > > > in ticket #13100, but I'm seconding specifically this comment: > > >http://code.djangoproject.com/ticket/13100#comment:8 > > > The difference between how ModelForm works and how Model works is > > that, if you're overriding clean() on a ModelForm subclass, you don't > > automatically get uniqueness validation -- you have to call up to the > > parent clean(), or manually apply the uniqueness validation in your > > own clean(). > > Thank you for this explanation. > > orokusaki noted in ticket #13100: > "The only difference between its implementation and > ModelForm?._post_clean() is the internal check it makes before running > validate_unique()." > > So is the actual issue here that naively calling Model.full_clean() will > always run Model.validate_unique(), when the existing > ModelForm._post_clean() code only calls Model.validate_unique() when > self._validate_unique? > > If so, Model.full_clean() is new in 1.2. So, could we just add a kwarg > like this (or similar)? > def full_clean(self, exclude=None, validate_unique=True) > > Then, it would be modified to only call Model.validate_unique if the > validate_unique argument was True. > > Then, you could call Model.full_clean() from ModelForm._post_clean(), > passing self._validate_unique and preserve the same behavior. > > Alternatively, could we add another function to Model that allows for > whole-model validation but does not call Model.validate_unique() and > then call that from ModelForm._post_clean() instead of calling > Model.full_clean()? Of course, Model.full_clean() would have to call > this new validation function as well. > > Richard > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Process discussion: reboot
The DVCS conversation has been had many times over the last year or two on this list and in other places. I mention this not to say that you should know already as it isn't clearly documented, but as a suggestion that you should make sure that you are bringing something new and concrete to the discussion before starting it again. The current view of the core team is that the combination of a central, authoritative, Subversion server with semi-official mirrors for Git, Mercurial, and Bazaar is sufficient for the foreseeable future. All of the benefits of the distributed systems are available via the mirrors and there's no disruption to users who are used to the current workflow/infrastructure. If you would like to make a contribution to Django, you can work with whichever of the three most common DVCSs and there will be several core devs able to accept your changes without any problems. Sean O'Connor http://seanoc.com P.S. I am not a core dev so any of the core devs should feel free to correct me on this. That being said this view has been clearly expressed several times on this list and in other venues. On Mon, Apr 19, 2010 at 8:35 PM, Jerome Leclanche wrote: > If you contribute to open source projects, at one point you'll be > faced with the forced choice to use git. It is extremely popular (I > believe it's the most popular after svn), and unlike svn it's popular > for a good reason. > However, hg is decent as well; whatever the django team chooses, as > long as it's not cvs it can't really be worse than svn. > > (bzr fan, personally, but I'd prefer it if django moved over to git) > > J. Leclanche / Adys > > > > On Tue, Apr 20, 2010 at 2:58 AM, VernonCole wrote: > > Not to start a flame war --- but PLEASE! don't use git. I already > > have to use the other two leading DVCS's and all three are one too > > many. > > I personally prefer bazaar, but python itself and pywin32 are both > > committed to mercurial. I suspect that hg would be a better choice > > for most people. > > -- > > Vernon Cole > > > > On Apr 19, 10:05 am, Dennis Kaarsemaker > > wrote: > >> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote: > >> > >> > >> > >> > >> > >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: > >> > >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry > wrote: > >> > >> One suggestion that jumped out at me (which I admittedly know very > little > >> > >> history about with regards to Django or other projects) was the > "trunk > >> > >> ready" branch(es) [1]. Perhaps an effort to outline what that > process might > >> > >> entail in detail, to determine if it would address any concerns? > >> > >> > > FTR, I think this is a fine idea, and I think most (all?) of the > other > >> > > Django core developers do, too. It's just waiting on someone to Just > >> > > Do It. > >> > >> > > Anyone -- preferably a group -- who wants to start such a branch > could > >> > > go ahead and start one using the DVCS tool of their choice (Django > has > >> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me > and > >> > > I'll start watching it; show some continued motion and I'll spend > some > >> > > time getting a buildbot going against the branch; show high quality > >> > > and I'll start pulling from it more and more frequently; show > >> > > incredibly quality and I'll suggest that the maintainer(s) get > commit. > >> > >> > >> For my part, I see that it could be helpful to let some > patches/ideas get a > >> > >> shot at integration without having to endure the (necessarily) more > rigorous > >> > >> core commit trails. > >> > >> > > Quality is important, and if this branch is created it needs to > >> > > maintain that quality. If this hypothetical branch is low-quality > it's > >> > > just a different tool for a queue of un-reviewed patches, and I've > >> > > already got one of those. I'm not willing to compromise on quality: > if > >> > > patches don't meet our standards, they don't go in. > >> > >> > > Jacob > >> > >> > I fully agree regarding quality, my point being that this branch > itself may > >> > not be "trunk ready" at any given time, but patches/pulls from it > would be; > >> > quality of patches would obviously need to meet existing standards. > Perhaps > >> > that distinction isn't helpful, necessary, or desirable. > >> > >> I've been thinking of starting a proper contribution in django in a > >> similar way: a github repo with per-ticket branches that are trunk-ready > >> and regularly updated (rebased) against trunk until they are applied. > >> > >> So far I've only done so for a pony of mine as a test, but as soon as > >> the ash cloud clears, I will look at existing tickets. Would this > >> approach be useful for core committers to pull patches from? > >> > >> -- > >> Dennis K. > >> > >> They've gone to plaid! > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "Django developers" group. > >> To post to
Re: Low-Hanging Fruit
On Tue, Apr 20, 2010 at 5:20 AM, Don Guernsey wrote: > How do I sign up to help? Is there an overall schematic for how django > works? There's no official signup process; just dig in and get your hands dirty. General guidance on how to get started can be found here [1]. As for overall schematics - we don't really have any formal design documentation; historically, we have relied on our extensive regression test suite, the user-space documentation and the readability of Python as a language to communicate the design message. However, I can see how some high level design documentation could help newcomers get started. If you want to take this on as a project, it sounds like a good way to become familiar with Django's internals and help others do the same. [1] http://docs.djangoproject.com/en/dev/internals/contributing/ 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.
Re: Process discussion: reboot
If you contribute to open source projects, at one point you'll be faced with the forced choice to use git. It is extremely popular (I believe it's the most popular after svn), and unlike svn it's popular for a good reason. However, hg is decent as well; whatever the django team chooses, as long as it's not cvs it can't really be worse than svn. (bzr fan, personally, but I'd prefer it if django moved over to git) J. Leclanche / Adys On Tue, Apr 20, 2010 at 2:58 AM, VernonCole wrote: > Not to start a flame war --- but PLEASE! don't use git. I already > have to use the other two leading DVCS's and all three are one too > many. > I personally prefer bazaar, but python itself and pywin32 are both > committed to mercurial. I suspect that hg would be a better choice > for most people. > -- > Vernon Cole > > On Apr 19, 10:05 am, Dennis Kaarsemaker > wrote: >> On ma, 2010-04-19 at 15:47 +, Peter Landry wrote: >> >> >> >> >> >> > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: >> >> > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry >> > > wrote: >> > >> One suggestion that jumped out at me (which I admittedly know very >> > >> little >> > >> history about with regards to Django or other projects) was the "trunk >> > >> ready" branch(es) [1]. Perhaps an effort to outline what that process >> > >> might >> > >> entail in detail, to determine if it would address any concerns? >> >> > > FTR, I think this is a fine idea, and I think most (all?) of the other >> > > Django core developers do, too. It's just waiting on someone to Just >> > > Do It. >> >> > > Anyone -- preferably a group -- who wants to start such a branch could >> > > go ahead and start one using the DVCS tool of their choice (Django has >> > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and >> > > I'll start watching it; show some continued motion and I'll spend some >> > > time getting a buildbot going against the branch; show high quality >> > > and I'll start pulling from it more and more frequently; show >> > > incredibly quality and I'll suggest that the maintainer(s) get commit. >> >> > >> For my part, I see that it could be helpful to let some patches/ideas >> > >> get a >> > >> shot at integration without having to endure the (necessarily) more >> > >> rigorous >> > >> core commit trails. >> >> > > Quality is important, and if this branch is created it needs to >> > > maintain that quality. If this hypothetical branch is low-quality it's >> > > just a different tool for a queue of un-reviewed patches, and I've >> > > already got one of those. I'm not willing to compromise on quality: if >> > > patches don't meet our standards, they don't go in. >> >> > > Jacob >> >> > I fully agree regarding quality, my point being that this branch itself may >> > not be "trunk ready" at any given time, but patches/pulls from it would be; >> > quality of patches would obviously need to meet existing standards. Perhaps >> > that distinction isn't helpful, necessary, or desirable. >> >> I've been thinking of starting a proper contribution in django in a >> similar way: a github repo with per-ticket branches that are trunk-ready >> and regularly updated (rebased) against trunk until they are applied. >> >> So far I've only done so for a pony of mine as a test, but as soon as >> the ash cloud clears, I will look at existing tickets. Would this >> approach be useful for core committers to pull patches from? >> >> -- >> Dennis K. >> >> They've gone to plaid! >> >> -- >> 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 >> athttp://groups.google.com/group/django-developers?hl=en. > > -- > 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. > > -- 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.
Re: Process discussion: reboot
Not to start a flame war --- but PLEASE! don't use git. I already have to use the other two leading DVCS's and all three are one too many. I personally prefer bazaar, but python itself and pywin32 are both committed to mercurial. I suspect that hg would be a better choice for most people. -- Vernon Cole On Apr 19, 10:05 am, Dennis Kaarsemaker wrote: > On ma, 2010-04-19 at 15:47 +, Peter Landry wrote: > > > > > > > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: > > > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry > > > wrote: > > >> One suggestion that jumped out at me (which I admittedly know very little > > >> history about with regards to Django or other projects) was the "trunk > > >> ready" branch(es) [1]. Perhaps an effort to outline what that process > > >> might > > >> entail in detail, to determine if it would address any concerns? > > > > FTR, I think this is a fine idea, and I think most (all?) of the other > > > Django core developers do, too. It's just waiting on someone to Just > > > Do It. > > > > Anyone -- preferably a group -- who wants to start such a branch could > > > go ahead and start one using the DVCS tool of their choice (Django has > > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and > > > I'll start watching it; show some continued motion and I'll spend some > > > time getting a buildbot going against the branch; show high quality > > > and I'll start pulling from it more and more frequently; show > > > incredibly quality and I'll suggest that the maintainer(s) get commit. > > > >> For my part, I see that it could be helpful to let some patches/ideas > > >> get a > > >> shot at integration without having to endure the (necessarily) more > > >> rigorous > > >> core commit trails. > > > > Quality is important, and if this branch is created it needs to > > > maintain that quality. If this hypothetical branch is low-quality it's > > > just a different tool for a queue of un-reviewed patches, and I've > > > already got one of those. I'm not willing to compromise on quality: if > > > patches don't meet our standards, they don't go in. > > > > Jacob > > > I fully agree regarding quality, my point being that this branch itself may > > not be "trunk ready" at any given time, but patches/pulls from it would be; > > quality of patches would obviously need to meet existing standards. Perhaps > > that distinction isn't helpful, necessary, or desirable. > > I've been thinking of starting a proper contribution in django in a > similar way: a github repo with per-ticket branches that are trunk-ready > and regularly updated (rebased) against trunk until they are applied. > > So far I've only done so for a pony of mine as a test, but as soon as > the ash cloud clears, I will look at existing tickets. Would this > approach be useful for core committers to pull patches from? > > -- > Dennis K. > > They've gone to plaid! > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Low-Hanging Fruit
On 19 April 2010 22:20, Don Guernsey wrote: > How do I sign up to help? Is there an overall schematic for how django > works? Overview of the process. docs.djangoproject.com/en/dev/internals/contributing/ Signup for trac. www.djangoproject.com/accounts/register/ -- 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.
Re: Process discussion: reboot
On Apr 19, 2010, at 5:16 PM, Mike wrote: > For the project of such exposure as Django the number of _active_ core > members that actually do work on trunk and are participating in the > decision making process is extremely small. Quick and dirty statistic > on > trunk commits shows that more than 75% of the work in _trunk_ is done > by just 4 developers [1] and from this list it seems that not much > more are > really involved into design decision making either. It does appear true that we're a little light on active core devs right now. Can I propose Alex Gaynor for commit bit? Seriously, why hasn't someone else proposed this already? :) 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.
Re: Process discussion: reboot
Once I understand what I am doing I would have no problem putting together
an "ebb and flow" diagram with pointers to codesomething like...Step 1
Request Made--When a request is made the first thing that happens is def
AutoStart is activated, next, def SecondStart is fired (with pictures).
On Mon, Apr 19, 2010 at 2:32 PM, Giuseppe Ciotta wrote:
> On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss
> wrote:
>
> > So: here's your chance. You have suggestions about Django's
> > development process? Make them. I'm listening.
>
> My understanding is that write access to triage stage and tickets
> details is granted to everybody (even to anonymous users), and
> everybody can change everything, thus making this data not 100%
> reliable.
>
> Having an additional field{s} in the ticket, only accessible to core
> developers, where they would put the "official" (as in: approved by a
> core developer) triage status of the ticket, could improve the
> efficency of the tickets review.
>
> --
> 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.
>
>
--
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.
Re: Low-Hanging Fruit
How do I sign up to help? Is there an overall schematic for how django works? On Mon, Apr 19, 2010 at 3:53 PM, Gabriel Hurley wrote: > I just want to second this suggestion from Russell: > > On Apr 19, 8:11 am, Russell Keith-Magee > wrote: > > > Lastly, pick anything to do with documentation. This isn't a coding > > problem, obviously, but writing up a documentation patch to clarify > > some issue will help you get to know Django's Sphinx markup > > extensions, and it's good practice for when you submit a bigger ticket > > that does requires documentation > > Even beyond that, taking on documentation tickets will take you into a > broad range of areas and have you digging into the codebase to figure > out what the correct documentation ought to be. It's a great way to > find out what you weren't aware that you didn't know. (that's kind of > like preparing for the unexpected...) > > - Gabriel > > -- > 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. > > -- 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.
Re: Process discussion: reboot
On Apr 19, 10:19 am, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to try to reboot the discussion that's been going on about > Django's development process. > > I'm finding the current thread incredibly demoralizing: there's a > bunch of frustration being expressed, and I hear that, but I'm having > trouble finding any concrete suggestions. Instead, the thread has > devolved into just going around in circles on the same small handful > of issues. > > So: here's your chance. You have suggestions about Django's > development process? Make them. I'm listening. > I'm new in Django so you can just ignore my opinion but probably due to a fresh eye I think I see _one_ important reason why such discussions pop up over and over again. For the project of such exposure as Django the number of _active_ core members that actually do work on trunk and are participating in the decision making process is extremely small. Quick and dirty statistic on trunk commits shows that more than 75% of the work in _trunk_ is done by just 4 developers [1] and from this list it seems that not much more are really involved into design decision making either. At the same time the requirements for any new proposal are extremely high. You and Russ have explained them many times on this list. in short it should be perfect from the core view to be included. I'm not saying it is good or bad. No judgment at all. Just pure observation. These two things simply mean that for the core team it is just _physically_ impossible to cope with the rising flow of requests/patches/bug reports. IMHO there are two ways out of this : 1. Share responsibility and ownership with more developers even if their views are not exactly match yours. 2. Just ignore such discussions, they are inevitable, unless you'll make this list moderated. Regards, Mike [1] Number of commits and changed lines per developer for the tr...@13001: # #Comm %Cum% #Lines %Cum% developer --- 1. 2612 31.48 31.48 2626 17.53 17.53 adrian 2. 1814 21.86 53.34 5595 37.34 54.87 mtredinnick 3. 1026 12.37 65.71 1400 9.34 64.21 russellm 4. 818 9.86 75.57 1235 8.24 72.46 jacob 5. 335 4.04 79.61 760 5.07 77.53 gwilson 6. 202 2.43 82.04 402 2.68 80.21 hugo 7. 201 2.42 84.46 472 3.15 83.36 kmtracey 8. 186 2.24 86.71 779 5.20 88.56 lukeplant 9. 185 2.23 88.94 285 1.90 90.46 ubernostrum 10. 183 2.21 91.14 398 2.66 93.12 jbronn 11. 170 2.05 93.19 183 1.22 94.34 jezdez 12. 144 1.74 94.93 209 1.39 95.74 brosner 13. 73 0.88 95.8199 0.66 96.40 telenieko 14. 68 0.82 96.6394 0.63 97.02 ikelly 15. 67 0.81 97.4379 0.53 97.55 jkocherhans 16. 44 0.53 97.9675 0.50 98.05 wilson 17. 39 0.47 98.4378 0.52 98.57 zgoda 18. 34 0.41 98.8464 0.43 99.00 mboersma 19. 32 0.39 99.2360 0.40 99.40 tekNico 20. 25 0.30 99.5325 0.17 99.57 simon 21. 14 0.17 99.7024 0.16 99.73 toxik 22. 11 0.13 99.8318 0.12 99.85 ramiro 23.8 0.10 99.9315 0.10 99.95 aljosa 24.5 0.06 99.99 7 0.05 99.99 garcia_marc 25.1 0.01 100.00 1 0.01 100.00 jtauber -- 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.
Re: Process discussion: reboot
I have to agree with Gabriel here as I to have only recently been trying to actively participate in the growing experience that is Django. Though I haven't quite yet made the jump into actually contributing code yet as I'm still coming to terms with understanding the internals of both the code and the community. Though I am not a contributor to Django I watch the mailing lists closely and try to use the discussions to help me build up my own knowledge of the internals of both how the community works as well as how Django itself evolves. This may be a developers discussion list but there are some of us actively watching these threads who find it quite scary when a 'policy change' discussion becomes a main focus on a framework that holds a lot of peoples futures in the balance. My 2 cents. I too will close with the very same Benjamin Franklin quote that Gabriel previously posted, as it is a very relevant situation: "We must hang together or assuredly we shall hang separately."" On Mon, Apr 19, 2010 at 1:34 PM, Gabriel Hurley wrote: > Before I even say anything: I think the core team does a great job, > they're as fair as humanly possible in their decisions, and Django's > stability is amazing. > > My disclaimer out of the way, I'd like to share my own experience of > being a new contributor just to add another perspective. > > I only started submitting patches during the 1.2 release cycle, so I'm > still a relative newbie. In 4 months I've learned *a lot* about > Django's process and the history of thought behind many of the issues > in both the codebase and the development process. But that knowledge > wasn't easy to come by. > > I read the contributing docs twice before I even opened my first > ticket. Twice more before I submitted a single patch. > > When I finally did submit my first patch, I was terrified of getting > it wrong and having it rejected. I'd seen it happen on other tickets. > It wasn't until I got *more involved* and started keeping up with the > trac timeline--watching the ebb and flow of tickets--that I started to > understand how the tone on trac had a reason. Until you get that > perspective, it's hard to know what's right or wrong, and easy to take > things personally. The core devs can seem imposing or scary simply > because you don't know them. > > Even after reading the contributing docs and all the internals several > times, there was still a large portion of knowledge that I found only > existed outside those docs. Spending hours reading through this list's > history and through the #django-dev IRC logs have answered a lot more > of my questions. While it might seem obvious to say "go add that > information to the docs" the truth is that a lot of what new > contributors need to learn is subjective, and may not belong in > official documentation. > > I did find that the ambiguity of ticket statuses in trac made it hard > to dive right in and understand what was going on. But that's been > discussed at length. When someone has an idea for a solution there, > I'll be the first to jump in and work on it. > > If anything, my point is that getting started as a Django contributor > *can* be difficult, and the core team just being aware of that fact is > a good thing. > > That said, I have no sympathy for the malcontents. I would really > rather have seen 1.2 get released than 80+ messages on these two > threads. If complaints were patches, we'd be halfway to 1.3 by now. > > Divisiveness and ill-willed argument is stifling to creativity and > progress. I hope this post doesn't contribute to it. > > I'll close with Benjamin Franklin: "We must hang together or assuredly > we shall hang separately." > > - Gabriel > > > > On Apr 19, 7:19 am, Jacob Kaplan-Moss wrote: > > Hi folks -- > > > > I'd like to try to reboot the discussion that's been going on about > > Django's development process. > > > > I'm finding the current thread incredibly demoralizing: there's a > > bunch of frustration being expressed, and I hear that, but I'm having > > trouble finding any concrete suggestions. Instead, the thread has > > devolved into just going around in circles on the same small handful > > of issues. > > > > So: here's your chance. You have suggestions about Django's > > development process? Make them. I'm listening. > > > > Jacob > > > > -- > > 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 athttp:// > groups.google.com/group/django-developers?hl=en. > > -- > 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
Re: Low-Hanging Fruit
I just want to second this suggestion from Russell: On Apr 19, 8:11 am, Russell Keith-Magee wrote: > Lastly, pick anything to do with documentation. This isn't a coding > problem, obviously, but writing up a documentation patch to clarify > some issue will help you get to know Django's Sphinx markup > extensions, and it's good practice for when you submit a bigger ticket > that does requires documentation Even beyond that, taking on documentation tickets will take you into a broad range of areas and have you digging into the codebase to figure out what the correct documentation ought to be. It's a great way to find out what you weren't aware that you didn't know. (that's kind of like preparing for the unexpected...) - Gabriel -- 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.
Cross-field Model Validation and Ticket #13100 (Was: Re: High Level Discussion about the Future of Django)
In the end, *my* requirement is that I have *some place* to put validation code that 1) can see the whole model instance, 2) will be run from the admin interface, and 3) will return nice validation failures to the user (not throw exceptions that will give the user a 500 error and send me an email). A) Is this an unreasonable pony? If so, why? B) If not, how can I implement this such that it will get accepted? I'd like to have it in for 1.2 if possible, as the model validation interfaces are new. Once released, there will be more backwards-compatibility guarantees to maintain. On Mon, 2010-04-19 at 10:53 -0500, James Bennett wrote: > On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > >> With all respect, you still haven't addressed my main concern: You > >> told me that it was because of backward compatibility that this simple > >> change couldn't be put in the trunk. It is backward compatible. If I'm > >> wrong, it would suffice to have a simple explanation of what it > >> breaks. > > > > I'd like to second this question. orokusaki suggested a couple of things > > in ticket #13100, but I'm seconding specifically this comment: > > http://code.djangoproject.com/ticket/13100#comment:8 > > The difference between how ModelForm works and how Model works is > that, if you're overriding clean() on a ModelForm subclass, you don't > automatically get uniqueness validation -- you have to call up to the > parent clean(), or manually apply the uniqueness validation in your > own clean(). Thank you for this explanation. orokusaki noted in ticket #13100: "The only difference between its implementation and ModelForm?._post_clean() is the internal check it makes before running validate_unique()." So is the actual issue here that naively calling Model.full_clean() will always run Model.validate_unique(), when the existing ModelForm._post_clean() code only calls Model.validate_unique() when self._validate_unique? If so, Model.full_clean() is new in 1.2. So, could we just add a kwarg like this (or similar)? def full_clean(self, exclude=None, validate_unique=True) Then, it would be modified to only call Model.validate_unique if the validate_unique argument was True. Then, you could call Model.full_clean() from ModelForm._post_clean(), passing self._validate_unique and preserve the same behavior. Alternatively, could we add another function to Model that allows for whole-model validation but does not call Model.validate_unique() and then call that from ModelForm._post_clean() instead of calling Model.full_clean()? Of course, Model.full_clean() would have to call this new validation function as well. Richard -- 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.
Re: Process discussion: reboot
Before I even say anything: I think the core team does a great job, they're as fair as humanly possible in their decisions, and Django's stability is amazing. My disclaimer out of the way, I'd like to share my own experience of being a new contributor just to add another perspective. I only started submitting patches during the 1.2 release cycle, so I'm still a relative newbie. In 4 months I've learned *a lot* about Django's process and the history of thought behind many of the issues in both the codebase and the development process. But that knowledge wasn't easy to come by. I read the contributing docs twice before I even opened my first ticket. Twice more before I submitted a single patch. When I finally did submit my first patch, I was terrified of getting it wrong and having it rejected. I'd seen it happen on other tickets. It wasn't until I got *more involved* and started keeping up with the trac timeline--watching the ebb and flow of tickets--that I started to understand how the tone on trac had a reason. Until you get that perspective, it's hard to know what's right or wrong, and easy to take things personally. The core devs can seem imposing or scary simply because you don't know them. Even after reading the contributing docs and all the internals several times, there was still a large portion of knowledge that I found only existed outside those docs. Spending hours reading through this list's history and through the #django-dev IRC logs have answered a lot more of my questions. While it might seem obvious to say "go add that information to the docs" the truth is that a lot of what new contributors need to learn is subjective, and may not belong in official documentation. I did find that the ambiguity of ticket statuses in trac made it hard to dive right in and understand what was going on. But that's been discussed at length. When someone has an idea for a solution there, I'll be the first to jump in and work on it. If anything, my point is that getting started as a Django contributor *can* be difficult, and the core team just being aware of that fact is a good thing. That said, I have no sympathy for the malcontents. I would really rather have seen 1.2 get released than 80+ messages on these two threads. If complaints were patches, we'd be halfway to 1.3 by now. Divisiveness and ill-willed argument is stifling to creativity and progress. I hope this post doesn't contribute to it. I'll close with Benjamin Franklin: "We must hang together or assuredly we shall hang separately." - Gabriel On Apr 19, 7:19 am, Jacob Kaplan-Moss wrote: > Hi folks -- > > I'd like to try to reboot the discussion that's been going on about > Django's development process. > > I'm finding the current thread incredibly demoralizing: there's a > bunch of frustration being expressed, and I hear that, but I'm having > trouble finding any concrete suggestions. Instead, the thread has > devolved into just going around in circles on the same small handful > of issues. > > So: here's your chance. You have suggestions about Django's > development process? Make them. I'm listening. > > Jacob > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 4:19 PM, Jacob Kaplan-Moss wrote:
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
My understanding is that write access to triage stage and tickets
details is granted to everybody (even to anonymous users), and
everybody can change everything, thus making this data not 100%
reliable.
Having an additional field{s} in the ticket, only accessible to core
developers, where they would put the "official" (as in: approved by a
core developer) triage status of the ticket, could improve the
efficency of the tickets review.
--
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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:24 PM, orokusaki wrote: > Jacob, I just refreshed. Please don't kick me. I'm trying to have a > dialogue, and I'm not trolling. Django is my life, and I want to help. Then prove it. Ball's in your court. Jacob -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:23 PM, orokusaki wrote: > -- No matter what industry you're in, or what your title is, your > real job is "Sales Person". Your second job is "Customer Service", and > finally your third job is "[Insert Job Title Here]". Dammit, this isn't my job -- it's my fucking hobby. The only way anything gets done here is if people volunteer and do it. > I'm not saying that the core developers should think of their free, > public contributions as a paying client, but it might be good to > exercise a little restraint when you feel "annoyed". You have absolutely no idea the level of restraint I'm showing. > If I didn't feel > so pushed back by the core team, I'd become a big contributor, but > instead of writing code, I spend all of my free time arguing, Than STOP ARGUING AND WRITE SOME CODE! Jacob -- 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.
Re: Process discussion: reboot
Jacob, I just refreshed. Please don't kick me. I'm trying to have a dialogue, and I'm not trolling. Django is my life, and I want to help. On Apr 19, 11:20 am, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 12:09 PM, orokusaki wrote: > > Firstly, thanks to Jacob for the highly hostile nature of his bedside > > manor. > > Please, just stop. This doesn't help. > > > Secondly, I didn't assert anything. I merely referenced the docs (I > > suppose this will be another case where you simply adjust the docs to > > mirror your recent assertion) > > Now you're trolling - we've never done this. The documentation is in > SVN and there's a complete historical record. Point to one instance > where we've done this. > > This is your last warning. Keep this up and I'm going to have no > choice but to kick you off this list. > > Jacob > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Process discussion: reboot
On a broader note, let me give you a bit of history. I started my career as a customer service person. I managed Staples Business Services department in my local Staples. Before I decided to learn programming a couple years ago at 24, I learned a valuable lesson: -- No matter what industry you're in, or what your title is, your real job is "Sales Person". Your second job is "Customer Service", and finally your third job is "[Insert Job Title Here]". When my clients come to me and say "MY SITE SHOULD DO THIS!" my first response isn't "YOU'RE WRONG!". I understand that they're my clients, and they are always right in their own eyes. It's my job to find out where their pain point is, and see if there is a better remedy than what they're suggesting. If there is not, then it's my job to decide if they're truly wrong. If I find out they're not wrong, and I don't have a better remedy, I typically cave to their request rather than going back and changing my proposal to exclude their current request. I'm not saying that the core developers should think of their free, public contributions as a paying client, but it might be good to exercise a little restraint when you feel "annoyed". If I didn't feel so pushed back by the core team, I'd become a big contributor, but instead of writing code, I spend all of my free time arguing, if just to get somebody to level with me and give me a good reason why they're turning my away. I don't claim to be an expert, but in my own eyes, my ideas are gold until somebody can give me a good explanation of why they're not. In the team development process, this constructive feedback is called problem solving. Look at what I was able to achieve in 5 minutes with James' feedback: http://groups.google.com/group/django-developers/browse_thread/thread/f8c747a26aa5d8ed/1397a0785cb09a36 (bottom). If my new version is still bad, take 30 seconds for some more feedback. repeat this across a slough of tickets, and before you know it you have hundreds of problem solvers like me, with vested interests, developing Django piece by piece. -- 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.
Re: High Level Discussion about the Future of Django
On Mon, Apr 19, 2010 at 12:03 PM, orokusaki wrote: > Ok, problem solved: When I apply this patch I get six test failures. Jacob -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:09 PM, orokusaki wrote: > Firstly, thanks to Jacob for the highly hostile nature of his bedside > manor. > > Secondly, I didn't assert anything. I merely referenced the docs (I > suppose this will be another case where you simply adjust the docs to > mirror your recent assertion) Strike one was your behavior in this thread: http://groups.google.com/group/django-developers/browse_thread/thread/b888734b05878f87/ Your behavior in this thread is now strike two. Be thankful that America's national pastime allows for three strikes, because if I weren't a baseball fan I'd be all for you being out already. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:09 PM, orokusaki wrote: > Firstly, thanks to Jacob for the highly hostile nature of his bedside > manor. Please, just stop. This doesn't help. > Secondly, I didn't assert anything. I merely referenced the docs (I > suppose this will be another case where you simply adjust the docs to > mirror your recent assertion) Now you're trolling - we've never done this. The documentation is in SVN and there's a complete historical record. Point to one instance where we've done this. This is your last warning. Keep this up and I'm going to have no choice but to kick you off this list. Jacob -- 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.
Re: Process discussion: reboot
Firstly, thanks to Jacob for the highly hostile nature of his bedside manor. Secondly, I didn't assert anything. I merely referenced the docs (I suppose this will be another case where you simply adjust the docs to mirror your recent assertion) http://docs.djangoproject.com/en/dev/misc/api-stability/#api-stability On Apr 19, 10:48 am, David Zhou wrote: > On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss > wrote: > > On Mon, Apr 19, 2010 at 10:38 AM, David Zhou wrote: > >> The specific number of point releases to remain compatible with can > >> probably be quibbled over, but I think the point is that maintaining > >> across the entirety of 1.x releases when point releases take this long > >> can be untenable for good forward momentum. > > > I'm pretty annoyed that you think that the policy is to maintain > > backwards compatibility "across the entirety of 1.x releases" because, > > well, that's not the policy. This is documented; see > >http://docs.djangoproject.com/en/dev/internals/release-process/. > > You're right, of course, and I should've fact checked orokusaki's > assertion that that was the current policy. So I'll retract my > previous statements -- those are only applicable given the policy > stated in orokusaki's email. > > -- dz > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: High Level Discussion about the Future of Django
Ok, problem solved:
``Model.full_clean()``
def full_clean(self, exclude=None, validate_unique=True):
"""
Calls clean_fields, clean, and validate_unique, on the model,
and raises a ``ValidationError`` for any errors that occured.
"""
errors = {}
if exclude is None:
exclude = []
try:
self.clean_fields(exclude=exclude)
except ValidationError, e:
errors = e.update_error_dict(errors)
# Form.clean() is run even if other validation fails, so do
the
# same with Model.clean() for consistency.
try:
self.clean()
except ValidationError, e:
errors = e.update_error_dict(errors)
# Run unique checks, but only for fields that passed
validation.
for name in errors.keys():
if name != NON_FIELD_ERRORS and name not in exclude:
exclude.append(name)
if validate_unique:
try:
self.validate_unique(exclude=exclude)
except ValidationError, e:
errors = e.update_error_dict(errors)
if errors:
raise ValidationError(errors)
``ModelForm._post_clean()``
def _post_clean(self):
exclude = self._get_validation_exclusions()
opts = self._meta
# Update the model instance with self.cleaned_data.
self.instance = construct_instance(self, self.instance,
opts.fields, opts.exclude)
# Clean the model instance and catch any and all fields.
try:
self.instance.full_clean(exclude=exclude,
validate_unique=self._validate_unique)
except ValidationError, e:
# Add the field errors in and NON_FIELD_ERRORS here (I
don't know the ins and outs of how `ValidationError` works).
This single change allows for so much more to be done in the model
layer instead of repetitive views. It allows you to actually do what
the docs say and use `Model.clean()` to do necessary additions to an
instance before it's saving, and without regards to data integrity,
because **this allows for you to wrap `Model.full_clean()` in a
transaction** and trust that it will always be used. I'm no RoR fan,
but Rails' policy of keeping data related logic inside of models is a
very wise one.
On Apr 19, 9:53 am, James Bennett wrote:
> On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote:
> > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote:
> >> With all respect, you still haven't addressed my main concern: You
> >> told me that it was because of backward compatibility that this simple
> >> change couldn't be put in the trunk. It is backward compatible. If I'm
> >> wrong, it would suffice to have a simple explanation of what it
> >> breaks.
>
> > I'd like to second this question. orokusaki suggested a couple of things
> > in ticket #13100, but I'm seconding specifically this comment:
> >http://code.djangoproject.com/ticket/13100#comment:8
>
> The difference between how ModelForm works and how Model works is
> that, if you're overriding clean() on a ModelForm subclass, you don't
> automatically get uniqueness validation -- you have to call up to the
> parent clean(), or manually apply the uniqueness validation in your
> own clean().
>
> In Django 1.0 and 1.1, this is documented behavior:
>
> http://docs.djangoproject.com/en/1.0/topics/forms/modelforms/#overrid...http://docs.djangoproject.com/en/1.1/topics/forms/modelforms/#overrid...
>
> As such, changing ModelForm to always behave identically to, or to
> always call, Model.full_clean() would have to change documented
> behavior. We can't do that in the 1.1 -> 1.2 jump, and for future
> consideration trying to force them to behave identically is probably
> unworkable (better would be to come up with API that lets you
> explicitly control uniqueness validation).
>
> This is why that ticket has been changed to a documentation issue: the
> wording of the documentation with respect to ModelForm and model
> validation is pretty bad right now, and needs to be cleaned up for the
> 1.2 release. And this is why for a month now multiple committers have
> been saying that the proposed code changes are backwards-incompatible:
> ModelForm.clean() and Model.full_clean() *cannot* be made to function
> identically right now without changing documented behavior.
>
> And for the record, my own frustration on that ticket boils down to a
> simple thing: Joseph pointed out there was a backwards-compatibility
> issue, and opted to salvage the most workable solution by changing it
> to a documentation issue. The reporter reverted that. Russell chimed
> in and pointed out that Joseph was probably right and set the ticket
> back to a documentation issue. At that point our intrepid bug reporter
> could've gotten all the discussion he wanted by paying attention to
> something he'd been told multiple times, and which is clearly pointed
> out in the contributing docs we encourage everyone to re
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 12:14 PM, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 10:38 AM, David Zhou wrote: >> The specific number of point releases to remain compatible with can >> probably be quibbled over, but I think the point is that maintaining >> across the entirety of 1.x releases when point releases take this long >> can be untenable for good forward momentum. > > I'm pretty annoyed that you think that the policy is to maintain > backwards compatibility "across the entirety of 1.x releases" because, > well, that's not the policy. This is documented; see > http://docs.djangoproject.com/en/dev/internals/release-process/. You're right, of course, and I should've fact checked orokusaki's assertion that that was the current policy. So I'll retract my previous statements -- those are only applicable given the policy stated in orokusaki's email. -- dz -- 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.
Re: High Level Discussion about the Future of Django
Jacob, With respect, If I simply "trusted" folks, I would be: 1) making exactly 120k less per year, as my previous employers told me to "trust" them right before they went out of business and fired everyone 2) a lot less intelligent than I am 3) ignoring the advice of Benjamin Franklin "it is the first responsibility of every citizen to question authority." 4) committing a fallacy of defective induction. I'll stick to the broad advice of those who created the country I live in by convention, and ignore the other reasons. On Apr 19, 10:16 am, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 9:55 AM, orokusaki wrote: > > With all respect, you still haven't addressed my main concern: You > > told me that it was because of backward compatibility that this simple > > change couldn't be put in the trunk. It is backward compatible. If I'm > > wrong, it would suffice to have a simple explanation of what it > > breaks. > > You've been told by three separate developers now that it's not > backwards compatible. It's time for you to trust that we know what > we're talking about and move on. > > Jacob > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: High Level Discussion about the Future of Django
On Mon, Apr 19, 2010 at 9:55 AM, orokusaki wrote: > With all respect, you still haven't addressed my main concern: You > told me that it was because of backward compatibility that this simple > change couldn't be put in the trunk. It is backward compatible. If I'm > wrong, it would suffice to have a simple explanation of what it > breaks. You've been told by three separate developers now that it's not backwards compatible. It's time for you to trust that we know what we're talking about and move on. Jacob -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 11:05 AM, Dennis Kaarsemaker wrote: > I've been thinking of starting a proper contribution in django in a > similar way: a github repo with per-ticket branches that are trunk-ready > and regularly updated (rebased) against trunk until they are applied. > > So far I've only done so for a pony of mine as a test, but as soon as > the ash cloud clears, I will look at existing tickets. Would this > approach be useful for core committers to pull patches from? If the quality's good, yes -- very much so. Jacob -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 10:38 AM, David Zhou wrote: > The specific number of point releases to remain compatible with can > probably be quibbled over, but I think the point is that maintaining > across the entirety of 1.x releases when point releases take this long > can be untenable for good forward momentum. I'm pretty annoyed that you think that the policy is to maintain backwards compatibility "across the entirety of 1.x releases" because, well, that's not the policy. This is documented; see http://docs.djangoproject.com/en/dev/internals/release-process/. Quoting from there: """ Minor release (1.1, 1.2, etc.) [...] will contain new features, improvements to existing features, and such. A minor release may deprecate certain features from previous releases. If a feature in version A.B is deprecated, it will continue to work in version A.B+1. In version A.B+2, use of the feature will raise a DeprecationWarning but will continue to work. Version A.B+3 will remove the feature entirely. So, for example, if we decided to remove a function that existed in Django 1.0: Django 1.1 will contain a backwards-compatible replica of the function which will raise a PendingDeprecationWarning. This warning is silent by default; you need to explicitly turn on display of these warnings. Django 1.2 will contain the backwards-compatible replica, but the warning will be promoted to a full-fledged DeprecationWarning. This warning is loud by default, and will likely be quite annoying. Django 1.3 will remove the feature outright. """ So, yes, we're really *are* just quibbling over the specific number of releases that Django will be compatible with. A few people want just one stable release, but the core committers want two. So here's where I put on by BDFL hat: Django's backwards-compability policy will remain as quoted above. You think I'm wrong, and that's fine, and I don't expect to convince you otherwise. But ultimately it's my decision to make, and I'm making it. But for the record, I will explain why I feel so strongly about this: The best part of my job is that I get to talk to and meet so many people who're using Django. These folks span the glove, and they also span the gamut of software developers. In the last year, I've spoken to design agencies, data visualization companies, cloud computing experts, Enterprise IT developers, web 2.0 developers, web 1.0 developers, new media, old media, startups, Fortune 500 CTOs, venture capitalists, angel investors, bankers, attorneys, financial advisors, firemen, and more. The recurring theme -- the thing I hear over, and over, and over again -- is how much they love Django's stability and predictability. Over and over again I hear that software maintenance is a pain in the ass, and that Django makes it easier. If upgrades from 1.1 to 1.2 aren't easy, these developers tell me, then they won't be able to take advantage of new features. My evidence goes beyond anecdotal. Studies have shown that as much as 80% of software work is in maintenance, and, further, that much of that maintenance work is non-corrective (i.e. adding features). When software changes dramatically between releases, people get stuck on old versions, and this means they're unable to develop the features they need. So, once again, the policy will not change unless you can demonstrate overwhelming evidence that I am wrong. Jacob -- 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.
Re: Process discussion: reboot
On ma, 2010-04-19 at 15:47 +, Peter Landry wrote: > > > On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: > > > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry wrote: > >> One suggestion that jumped out at me (which I admittedly know very little > >> history about with regards to Django or other projects) was the "trunk > >> ready" branch(es) [1]. Perhaps an effort to outline what that process might > >> entail in detail, to determine if it would address any concerns? > > > > FTR, I think this is a fine idea, and I think most (all?) of the other > > Django core developers do, too. It's just waiting on someone to Just > > Do It. > > > > Anyone -- preferably a group -- who wants to start such a branch could > > go ahead and start one using the DVCS tool of their choice (Django has > > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and > > I'll start watching it; show some continued motion and I'll spend some > > time getting a buildbot going against the branch; show high quality > > and I'll start pulling from it more and more frequently; show > > incredibly quality and I'll suggest that the maintainer(s) get commit. > > > >> For my part, I see that it could be helpful to let some patches/ideas get a > >> shot at integration without having to endure the (necessarily) more > >> rigorous > >> core commit trails. > > > > Quality is important, and if this branch is created it needs to > > maintain that quality. If this hypothetical branch is low-quality it's > > just a different tool for a queue of un-reviewed patches, and I've > > already got one of those. I'm not willing to compromise on quality: if > > patches don't meet our standards, they don't go in. > > > > Jacob > > I fully agree regarding quality, my point being that this branch itself may > not be "trunk ready" at any given time, but patches/pulls from it would be; > quality of patches would obviously need to meet existing standards. Perhaps > that distinction isn't helpful, necessary, or desirable. I've been thinking of starting a proper contribution in django in a similar way: a github repo with per-ticket branches that are trunk-ready and regularly updated (rebased) against trunk until they are applied. So far I've only done so for a pony of mine as a test, but as soon as the ash cloud clears, I will look at existing tickets. Would this approach be useful for core committers to pull patches from? -- Dennis K. They've gone to plaid! -- 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.
Re: High Level Discussion about the Future of Django
On Mon, Apr 19, 2010 at 10:16 AM, Richard Laager wrote: > On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: >> With all respect, you still haven't addressed my main concern: You >> told me that it was because of backward compatibility that this simple >> change couldn't be put in the trunk. It is backward compatible. If I'm >> wrong, it would suffice to have a simple explanation of what it >> breaks. > > I'd like to second this question. orokusaki suggested a couple of things > in ticket #13100, but I'm seconding specifically this comment: > http://code.djangoproject.com/ticket/13100#comment:8 The difference between how ModelForm works and how Model works is that, if you're overriding clean() on a ModelForm subclass, you don't automatically get uniqueness validation -- you have to call up to the parent clean(), or manually apply the uniqueness validation in your own clean(). In Django 1.0 and 1.1, this is documented behavior: http://docs.djangoproject.com/en/1.0/topics/forms/modelforms/#overriding-the-clean-method http://docs.djangoproject.com/en/1.1/topics/forms/modelforms/#overriding-the-clean-method As such, changing ModelForm to always behave identically to, or to always call, Model.full_clean() would have to change documented behavior. We can't do that in the 1.1 -> 1.2 jump, and for future consideration trying to force them to behave identically is probably unworkable (better would be to come up with API that lets you explicitly control uniqueness validation). This is why that ticket has been changed to a documentation issue: the wording of the documentation with respect to ModelForm and model validation is pretty bad right now, and needs to be cleaned up for the 1.2 release. And this is why for a month now multiple committers have been saying that the proposed code changes are backwards-incompatible: ModelForm.clean() and Model.full_clean() *cannot* be made to function identically right now without changing documented behavior. And for the record, my own frustration on that ticket boils down to a simple thing: Joseph pointed out there was a backwards-compatibility issue, and opted to salvage the most workable solution by changing it to a documentation issue. The reporter reverted that. Russell chimed in and pointed out that Joseph was probably right and set the ticket back to a documentation issue. At that point our intrepid bug reporter could've gotten all the discussion he wanted by paying attention to something he'd been told multiple times, and which is clearly pointed out in the contributing docs we encourage everyone to read as they dive in: if you don't like the decision a committer made on a ticket, start a thread here on the dev list to talk about it. Instead he opened duplicate tickets, ranted in the tracker, insulted people, and generally turned the whole thing into a big radioactive mess that nobody wanted to touch with a ten-foot pole. And with that I'm going to bow out of this thread; Jacob's already posted a separate message to collect concrete suggestions, and that's the discussion I plan to pay attention to, since I think this one's pretty much boiled down to the same people endlessly saying the same things at each other and expecting different results. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- 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.
Re: Process discussion: reboot
On 4/19/10 11:41 AM, "Jacob Kaplan-Moss" wrote: > On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry wrote: >> One suggestion that jumped out at me (which I admittedly know very little >> history about with regards to Django or other projects) was the "trunk >> ready" branch(es) [1]. Perhaps an effort to outline what that process might >> entail in detail, to determine if it would address any concerns? > > FTR, I think this is a fine idea, and I think most (all?) of the other > Django core developers do, too. It's just waiting on someone to Just > Do It. > > Anyone -- preferably a group -- who wants to start such a branch could > go ahead and start one using the DVCS tool of their choice (Django has > semi-official clones on Github, Bitbucket, and Launchpad). Tell me and > I'll start watching it; show some continued motion and I'll spend some > time getting a buildbot going against the branch; show high quality > and I'll start pulling from it more and more frequently; show > incredibly quality and I'll suggest that the maintainer(s) get commit. > >> For my part, I see that it could be helpful to let some patches/ideas get a >> shot at integration without having to endure the (necessarily) more rigorous >> core commit trails. > > Quality is important, and if this branch is created it needs to > maintain that quality. If this hypothetical branch is low-quality it's > just a different tool for a queue of un-reviewed patches, and I've > already got one of those. I'm not willing to compromise on quality: if > patches don't meet our standards, they don't go in. > > Jacob I fully agree regarding quality, my point being that this branch itself may not be "trunk ready" at any given time, but patches/pulls from it would be; quality of patches would obviously need to meet existing standards. Perhaps that distinction isn't helpful, necessary, or desirable. Peter -- 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.
Re: Process discussion: reboot
Yes, thank you David. On Apr 19, 9:38 am, David Zhou wrote: > On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss > wrote: > > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki > > wrote: > >> The release of Django 1.0 comes with a promise of API stability and > >> forwards-compatibility. In a nutshell, this means that code you > >> develop against Django 1.0 will continue to work against 1.1 > >> unchanged, and you should need to make only minor changes for the 1.2 > >> release. > > > So you're proposing that 1.2 be the last backwards-compatible release, > > and that 1.3 be incompatible (if necessary) with 1.2? > > I think he's saying that 1.3 will work with 1.2 but not (necessarily) > with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0. > > The specific number of point releases to remain compatible with can > probably be quibbled over, but I think the point is that maintaining > across the entirety of 1.x releases when point releases take this long > can be untenable for good forward momentum. > > -- dz > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 9:54 AM, Peter Landry wrote: > One suggestion that jumped out at me (which I admittedly know very little > history about with regards to Django or other projects) was the "trunk > ready" branch(es) [1]. Perhaps an effort to outline what that process might > entail in detail, to determine if it would address any concerns? FTR, I think this is a fine idea, and I think most (all?) of the other Django core developers do, too. It's just waiting on someone to Just Do It. Anyone -- preferably a group -- who wants to start such a branch could go ahead and start one using the DVCS tool of their choice (Django has semi-official clones on Github, Bitbucket, and Launchpad). Tell me and I'll start watching it; show some continued motion and I'll spend some time getting a buildbot going against the branch; show high quality and I'll start pulling from it more and more frequently; show incredibly quality and I'll suggest that the maintainer(s) get commit. > For my part, I see that it could be helpful to let some patches/ideas get a > shot at integration without having to endure the (necessarily) more rigorous > core commit trails. Quality is important, and if this branch is created it needs to maintain that quality. If this hypothetical branch is low-quality it's just a different tool for a queue of un-reviewed patches, and I've already got one of those. I'm not willing to compromise on quality: if patches don't meet our standards, they don't go in. Jacob -- 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.
Re: Process discussion: reboot
Absolutely not. I'm saying the following: 1.1 works with 1.0 1.2 works with 1.1 1.3 works with 1.2 and 1.2 works (with slight modifications) with 1.0 1.3 works (with slight modifications) with 1.1 1.4 works (with slight modifications) with 1.2 On Apr 19, 9:31 am, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki wrote: > > The release of Django 1.0 comes with a promise of API stability and > > forwards-compatibility. In a nutshell, this means that code you > > develop against Django 1.0 will continue to work against 1.1 > > unchanged, and you should need to make only minor changes for the 1.2 > > release. > > So you're proposing that 1.2 be the last backwards-compatible release, > and that 1.3 be incompatible (if necessary) with 1.2? > > Jacob > > -- > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 11:31 AM, Jacob Kaplan-Moss wrote: > On Mon, Apr 19, 2010 at 10:19 AM, orokusaki wrote: >> The release of Django 1.0 comes with a promise of API stability and >> forwards-compatibility. In a nutshell, this means that code you >> develop against Django 1.0 will continue to work against 1.1 >> unchanged, and you should need to make only minor changes for the 1.2 >> release. > > So you're proposing that 1.2 be the last backwards-compatible release, > and that 1.3 be incompatible (if necessary) with 1.2? I think he's saying that 1.3 will work with 1.2 but not (necessarily) with 1.1, and 1.2 will work with 1.1 but not (necessarily) with 1.0. The specific number of point releases to remain compatible with can probably be quibbled over, but I think the point is that maintaining across the entirety of 1.x releases when point releases take this long can be untenable for good forward momentum. -- dz -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 10:19 AM, orokusaki wrote: > The release of Django 1.0 comes with a promise of API stability and > forwards-compatibility. In a nutshell, this means that code you > develop against Django 1.0 will continue to work against 1.1 > unchanged, and you should need to make only minor changes for the 1.2 > release. So you're proposing that 1.2 be the last backwards-compatible release, and that 1.3 be incompatible (if necessary) with 1.2? Jacob -- 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.
Re: Low-Hanging Fruit
Thanks, this advice is incredibly helpful, and your response is encouraging. Shawn -- 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.
Re: Process discussion: reboot
CURRENT VERSION OF API STABILITY POLICY: The release of Django 1.0 comes with a promise of API stability and forwards-compatibility. In a nutshell, this means that code you develop against Django 1.0 will continue to work against 1.1 unchanged, and you should need to make only minor changes for any 1.X release. SUGGESTED VERSION OF API STABILITY POLICY: The release of Django 1.0 comes with a promise of API stability and forwards-compatibility. In a nutshell, this means that code you develop against Django 1.0 will continue to work against 1.1 unchanged, and you should need to make only minor changes for the 1.2 release. It seems that this small change alone could dramatically decrease the number of hours spent by you guys. -- 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.
Re: Process discussion: reboot
On Mon, Apr 19, 2010 at 3:54 PM, Peter Landry wrote: > On 4/19/10 10:19 AM, "Jacob Kaplan-Moss" wrote: > >> Hi folks -- >> >> I'd like to try to reboot the discussion that's been going on about >> Django's development process. >> >> I'm finding the current thread incredibly demoralizing: there's a >> bunch of frustration being expressed, and I hear that, but I'm having >> trouble finding any concrete suggestions. Instead, the thread has >> devolved into just going around in circles on the same small handful >> of issues. >> >> So: here's your chance. You have suggestions about Django's >> development process? Make them. I'm listening. >> >> Jacob > > One suggestion that jumped out at me (which I admittedly know very little > history about with regards to Django or other projects) was the "trunk > ready" branch(es) [1]. Perhaps an effort to outline what that process might > entail in detail, to determine if it would address any concerns? > > For my part, I see that it could be helpful to let some patches/ideas get a > shot at integration without having to endure the (necessarily) more rigorous > core commit trails. > > I'm not really comfortable suggesting any concrete plans for how that might > happen though. A single almost-trunk branch? A branch per > lieutenant/component? I'm wary of adding too much bureaucracy and overhead. > I think it's pretty clear that the core Django process is successful, and > this seems like a low impact (though potentially high effort?) way to > involve more of the community. > > Peter > > [1] http://groups.google.com/group/django-developers/msg/ef8ec23d565dd07b > People only talk about a trunk-ready branch if they treat trunk as some sort of continually updated, always correct, release branch. IMHO trunk is where you commit features you want to be released, and you deal with fallout on trunk - you can always revert changes. An example of something that should have been committed to trunk already (immediately following release of django 1.1 imo) is custom FilterSpecs, #5833. This has been pushed from releases for 3 years, first from 1.0, then 1.1, now 1.2 - all for a feature that should be available in the admin. This is a ticket that displays a lot of the issues discussed in the other thread. The patch is feature complete, and community members have been updating it to recent versions of django for 3 years. It has comments of (seemingly) approval from core comitters, but lacks documentation and tests, and so sits, dead in the water, missing another release. A system that works on other projects is a mentorship system. I'm sure you have had lots of applicants to take part in GSoC - how about recruiting some of the rejected proposals and have them work through tickets like this, triaging and polishing to a committable state, at which point they coordinate with their mentor to have it committed. Obviously, they'd have to want to do this for free... One thing is true, the status quo doesn't seem to be resolving these forgotten tickets. Cheers Tom -- 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.
Re: High Level Discussion about the Future of Django
On Mon, 2010-04-19 at 07:55 -0700, orokusaki wrote: > With all respect, you still haven't addressed my main concern: You > told me that it was because of backward compatibility that this simple > change couldn't be put in the trunk. It is backward compatible. If I'm > wrong, it would suffice to have a simple explanation of what it > breaks. I'd like to second this question. orokusaki suggested a couple of things in ticket #13100, but I'm seconding specifically this comment: http://code.djangoproject.com/ticket/13100#comment:8 This is a serious bug/missing feature for my company's application and I don't see an obvious problem, backwards-compatibility or otherwise, with the suggested fix. Richard orokusaki: Instead of copying-and-pasting the function before and after your change, could you generate a diff (ideally against Django SVN's HEAD)? That's a more natural format for developers to review and it makes it easier for them to commit. (For these reasons, it's the normal way to submit patches in most open source projects.) Making life easy for the core developers is a key step in getting your ticket addressed (be it with Django or another project), and it's something Russell reiterated in the video. The basic steps would be: 1) svn co http://code.djangoproject.com/svn/django/trunk/ django-trunk 2) Make the change you listed. 3) svn diff > ~/13100-full-clean-dry.diff 4) Upload 13100-full-clean-dry.diff to the ticket. I could easily do this (and will if it's necessary), but I thought it better to help you to do it. signature.asc Description: This is a digitally signed message part
Re: Low-Hanging Fruit
On Mon, Apr 19, 2010 at 10:26 PM, Shawn Milochik wrote: > > So, I'm asking for anyone in the core (or close to it) to specifically point > out any low-hanging fruit. This may seem on the face of it to be asking for > others to waste time they could be spending supporting proven, trusted Django > contributors. However, I think it's not, because I'm asking someone who > already knows what's coming up in the queue to take a minute or two to say, > off of the top of their head, "These specific tickets are worth working on." > In the long run, this will actually benefit the core because (at least) one > more developer will be contributing to Django. If making it easier to identify low-hanging fruit will help more people get involved, I don't see it as waste of time at all. > Given the current state of the work on 1.2, this can easily wait for 1.2 to > be released. Compiling a list of specific tickets will take a while; I'll put this on my todo list for post 1.2. However, if you're looking for something to work on right now, I would suggest three approaches. Firstly, take a poke through the current Milestone 1.3 list [1]. Not all these issues are guaranteed to be simple, but they have been accepted and been given a mild prioritization. Ignore anything that is Design Decision Needed or appears to be a feature request -- low hanging fruit will almost always be simple bugs. Secondly, pick an area in which you have some interest (say, serialization [2] or testing [3]), and search trac for accepted tickets tagged against that component. Look at the newest issues first - they're the ones most likely to be simple problems with simple fixes. Older bugs may also be simple, but there's also a chance that old ticket == hideously difficult ticket; it may not be obvious until you're knee deep. As with the 1.3 tickets - avoid anything DDN or feature related. Lastly, pick anything to do with documentation. This isn't a coding problem, obviously, but writing up a documentation patch to clarify some issue will help you get to know Django's Sphinx markup extensions, and it's good practice for when you submit a bigger ticket that does requires documentation Also - when you're looking for something to work on, remember that you don't necessarily have to submit a complete fix to make a valuable contribution. Turning a problem report into a test case that is integrated with Django's test suite is often just as valuable as a fix for the problem. The only additional guidance I would provide here is that if your test involves models, try to re-use existing test models instead of adding new models. I hope that is enough to help you find something to chew on. :-) Yours, Russ Magee %-) [1] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&group=component&milestone=1.3&order=priority [2] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Serialization&order=priority [3] http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&component=Testing+framework&order=priority -- 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.
Re: Process discussion: reboot
I think that there is frustration on the part of the core dev team because people are (intentionally or not) demanding more and more of their time in the form of feature requests without understanding what the costs are and what resources exist. There is frustration on the part of some Django users who would like to contribute but feel that anyone not in the core dev team is a third-class citizen with a tiny voice, and think that spending any time working on a ticket is slightly less likely to be worthwhile than writing an iPhone app and hoping Apple approves it for the App Store. In my opinion, the problem lies not at either end, but in the middle. The way Trac is currently being used allows anyone at all to give tickets a status that the individual may not actually have the understanding to judge. To compensate for this, the core developers are each forced to rely on one another and their own small circle of lieutenants (as Linus does) to know whose code to actually take the time to evaluate. Ideally, people who want to contribute to Django should be able to adopt any open ticket in the bug tracker, work on it (with any necessary communication with this list), and see their work accepted if it's done well. At present this is not the case. A potential solution is to treat bug tracker permissions a bit more like the "commit bit," where accepting bugs would be limited to people who understand both the process and the direction/vision of Django. This would cost time, but could alleviate the frustration on both sides and ultimately result in more work getting done, not least because more people would be encouraged to participate. These are just my thoughts based mostly on the demoralizing thread Jacob is addressing with this one. I have also found it demoralizing, because it makes me feel like it's not worth aspiring to contribute to Django because there are too many obstacles. Some of Russell's comments do counter that sentiment, but it still seems like there is no way to have any confidence about what to work on without having the insight of a core developer. Again, this is all my opinion and I could be way off. Shawn -- 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.
Re: Low-Hanging Fruit
Karen, Thanks very much. I appreciate the response. I'll have a look into this (not to discourage anyone else from trying to beat me to it), and post to this list if I can shed light on this issue. Shawn -- 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.
Re: High Level Discussion about the Future of Django
Russell, With all respect, you still haven't addressed my main concern: You told me that it was because of backward compatibility that this simple change couldn't be put in the trunk. It is backward compatible. If I'm wrong, it would suffice to have a simple explanation of what it breaks. On Apr 19, 2:17 am, Russell Keith-Magee wrote: > On Mon, Apr 19, 2010 at 1:27 PM, orokusaki wrote: > > Russell, > > > I apologize for the apparent argumentum ad nauseam. I am not trying to > > be sly. I am just looking for open dialogue about ideas and I feel > > like the door is closed and caucus is frowned upon. This is the only > > way I feel like I can get any floor time. The tickets I create get > > closed quickly, and if I open better, more refined ones, they're > > closed as duplicates. > > > I really am not against, per se, the backwards compatibility > > guidelines, and I understand that there would be just as many folks > > upset if it were too lax. I just think that it ought to be revisited. > > Call this abstract, but that is only because I don't have the > > "correct" solution. > > > The 'full_clean' stuff is the only thing that really got me fired up. > > My change was not backward incompatible. ModelForm._post_clean() > > currently calls nearly the exact same code that is in Model.clean() > > instead of simply calling Model.clean() which would fix the entire > > problem in less than "one hour". > > > If I'm wrong, then explain to me how it breaks backward compatibility > > instead of simply erasing the docs. I can't help but feel like you did > > this to punish me for not following protocol, since you've not given > > my tickets more that 3 minutes. I've spent much more than 18 months > > thinking about a lot of things, but I'm always open to suggestion from > > eager hellers with a vested interest in helping me solve a problem. > > And if you want that answer, you've been told *many* times what you need to > do. > > If you choose to think of this as punishment for not following > protocol, that's up to you. I prefer to think of it as not encouraging > developers to engage in practices that we know (from experience) to be > counterproductive to the development process. > > 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 > athttp://groups.google.com/group/django-developers?hl=en. -- 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.
Re: Process discussion: reboot
On 4/19/10 10:19 AM, "Jacob Kaplan-Moss" wrote: > Hi folks -- > > I'd like to try to reboot the discussion that's been going on about > Django's development process. > > I'm finding the current thread incredibly demoralizing: there's a > bunch of frustration being expressed, and I hear that, but I'm having > trouble finding any concrete suggestions. Instead, the thread has > devolved into just going around in circles on the same small handful > of issues. > > So: here's your chance. You have suggestions about Django's > development process? Make them. I'm listening. > > Jacob One suggestion that jumped out at me (which I admittedly know very little history about with regards to Django or other projects) was the "trunk ready" branch(es) [1]. Perhaps an effort to outline what that process might entail in detail, to determine if it would address any concerns? For my part, I see that it could be helpful to let some patches/ideas get a shot at integration without having to endure the (necessarily) more rigorous core commit trails. I'm not really comfortable suggesting any concrete plans for how that might happen though. A single almost-trunk branch? A branch per lieutenant/component? I'm wary of adding too much bureaucracy and overhead. I think it's pretty clear that the core Django process is successful, and this seems like a low impact (though potentially high effort?) way to involve more of the community. Peter [1] http://groups.google.com/group/django-developers/msg/ef8ec23d565dd07b -- 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.
Re: Low-Hanging Fruit
On Mon, Apr 19, 2010 at 10:26 AM, Shawn Milochik wrote: > So, I'm asking for anyone in the core (or close to it) to specifically > point out any low-hanging fruit. Off the top of my head, a ticket I saw some activity on recently but have not had time to look into making a test/fix for: http://code.djangoproject.com/ticket/10523 Admin raises an exception if the repr of an object that is modified/deleted is greater than 200 characters. Fix is probably to truncate the object's repr to the max length of the field it's being put in. (Note this error will only happen for DBs that actually enforce max_length -- sqlite, for example, will happily let you store >200 chars in a field declared to only hold a max of 200. So the test for this will only fail on current code for certain DBs.) First place I'd likely look to put a test for this would be regressiontests/admin_views. Karen -- 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.
Low-Hanging Fruit
This is partially inspired by the thread that won't die: "High Level Discussion about the Future of Django." I want to contribute something back to Django. Specifically, I've already paid for my hotel and flights for DjangoCon 2010 and I'm definitely going to stay for the sprints. However, since I've only worked with Django and never on Django, I'd like to have some level of familiarity before then. Preferably, I'd like to handle a few tickets, both familiarizing myself with the process and getting in-depth knowledge of the small slices of Django's internals required to do so. Otherwise I probably won't be much use at the sprints. Since looking at a ticket in Trac doesn't indicate whether it passes the filters mentioned in Russell's talk (i.e. not good for Django's design, wrong direction) and I haven't been part of the Django community long enough to know intuitively, I'd just like a little head start on being able to contribute something of value to Django. So, I'm asking for anyone in the core (or close to it) to specifically point out any low-hanging fruit. This may seem on the face of it to be asking for others to waste time they could be spending supporting proven, trusted Django contributors. However, I think it's not, because I'm asking someone who already knows what's coming up in the queue to take a minute or two to say, off of the top of their head, "These specific tickets are worth working on." In the long run, this will actually benefit the core because (at least) one more developer will be contributing to Django. Given the current state of the work on 1.2, this can easily wait for 1.2 to be released. Thanks, Shawn -- 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.
Process discussion: reboot
Hi folks -- I'd like to try to reboot the discussion that's been going on about Django's development process. I'm finding the current thread incredibly demoralizing: there's a bunch of frustration being expressed, and I hear that, but I'm having trouble finding any concrete suggestions. Instead, the thread has devolved into just going around in circles on the same small handful of issues. So: here's your chance. You have suggestions about Django's development process? Make them. I'm listening. Jacob -- 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.
Re: High Level Discussion about the Future of Django
One of the main advantages of Django over other web frameworks is twofold: 1. Almost anything can be overridden with a custom backend (auth, e- mail, context processors, middleware, etc.) 2. Custom backends can be plugged in side-by-side with "stock" backends What functionality do you feel is holding Django back in particular? NoSQL support? Cloud architecture? In my opinion, the best course of action is to write a backend for a desired piece of functionality and then release it as open source. Just because something doesn't make it into trunk doesn't mean that it can't be a popular modular extension to Django in real-world deployments. As for Python 3.x support, I think the #python welcome message sums it up: "It's too early to use Python 3.x" :-) -- 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.
Re: High Level Discussion about the Future of Django
On Monday 19 April 2010 08:50:58 Russell Keith-Magee wrote: > I was going to do a point by point teardown, but then I realized > that I already have, at DjangoCon 2009: > > http://djangocon.blip.tv/file/3043562/ > > The opening is light hearted; the hard details start about 5 > minutes in. By sheer coincidence, I think I addressed almost every > one of the tickets/API areas that you've mentioned in your post, > as well as the general question of why we reject certain ideas, > and what you need to do to get your pony into Django itself. I've never watched that before, but it's extremely good. Could we perhaps link it from the page about contributing to Django, or maybe in the FAQ under "But I’ve reminded you several times and you keep ignoring my patch!" [1]. The material in the latter actually covers some of the material in your talk and in this thread, but seeing a person saying it with concrete examples is very helpful. We can then point to official documentation when this comes up again. Luke [1] http://goo.gl/wF57 -- Luke Plant || http://lukeplant.me.uk/ -- 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.
Re: Import problem starting with r12977
thanks for pointing this out. I attached a symptomatic patch to ticket #13366. best -- erik Am 17.04.2010 um 14:33 schrieb Ramiro Morales: > On Sat, Apr 17, 2010 at 4:38 AM, Erik Stein wrote: >> I'd would definetly consider this a bug in django, but I've no idea how to >> design a regression test for this, sorry. I'll try to understand what these >> app loading changes do. > > I think this has already been reported in ticket 13366, Comment is a > model that inherits from an abstract base class that has fields > (BaseCommentAbstractModel). -- 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.
Re: High Level Discussion about the Future of Django
On Mon, Apr 19, 2010 at 1:27 PM, orokusaki wrote: > Russell, > > I apologize for the apparent argumentum ad nauseam. I am not trying to > be sly. I am just looking for open dialogue about ideas and I feel > like the door is closed and caucus is frowned upon. This is the only > way I feel like I can get any floor time. The tickets I create get > closed quickly, and if I open better, more refined ones, they're > closed as duplicates. > > I really am not against, per se, the backwards compatibility > guidelines, and I understand that there would be just as many folks > upset if it were too lax. I just think that it ought to be revisited. > Call this abstract, but that is only because I don't have the > "correct" solution. > > The 'full_clean' stuff is the only thing that really got me fired up. > My change was not backward incompatible. ModelForm._post_clean() > currently calls nearly the exact same code that is in Model.clean() > instead of simply calling Model.clean() which would fix the entire > problem in less than "one hour". > > If I'm wrong, then explain to me how it breaks backward compatibility > instead of simply erasing the docs. I can't help but feel like you did > this to punish me for not following protocol, since you've not given > my tickets more that 3 minutes. I've spent much more than 18 months > thinking about a lot of things, but I'm always open to suggestion from > eager hellers with a vested interest in helping me solve a problem. And if you want that answer, you've been told *many* times what you need to do. If you choose to think of this as punishment for not following protocol, that's up to you. I prefer to think of it as not encouraging developers to engage in practices that we know (from experience) to be counterproductive to the development process. 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.
Re: High Level Discussion about the Future of Django
On Mon, Apr 19, 2010 at 7:10 AM, David Cramer wrote: > I just want to throw my 2 cents into the ring here. I'm not against a > fork, but at the same time I want to see the Django mainline progress. > However, let me tell you my story, and how I've seen the Django > development process over the years. I was going to do a point by point teardown, but then I realized that I already have, at DjangoCon 2009: http://djangocon.blip.tv/file/3043562/ The opening is light hearted; the hard details start about 5 minutes in. By sheer coincidence, I think I addressed almost every one of the tickets/API areas that you've mentioned in your post, as well as the general question of why we reject certain ideas, and what you need to do to get your pony into Django itself. 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.
