Isn't that what forking is for? A group of folks feel frustrated about not being able to commit, so they make their own copy of the source code available. A few months later they either implode when they realise just how much work it is going to take to do anything remotely sensible, or they come up with some bit of nuggety goodness that can be chopped around and backported.
As long as the forking happens without falling out, that is... On a completely unrelated note, any plans to move Django to git? Ian. Not that I count for jack, but its +1 on API stability and backwards compatibility from me, btw! On Apr 16, 5:23 pm, "Tom X. Tobin" <tomxto...@tomxtobin.com> wrote: > On Fri, Apr 16, 2010 at 10:32 AM, Jacob Kaplan-Moss <ja...@jacobian.org> > wrote: > > I'm not arguing that "stability, maturity, and longevity" are > > "correct" priorities, only that, well, those are the ones we've > > chosen. I'm not saying it's "wrong" to want more rapid improvement, > > only that it's lower on *my* list. > > My priorities overlap, but not completely. > > Stability is very important to me, and should be important to *anyone* > whose livelihood depends on Django. Stability is a large part of the > reason we *can* run our own Django branch and run production sites > based on it, yet not lose our minds in the process. > > Maturity is fairly important; I want solutions that have experience > and judgement behind them. Maturity can become rigidity, though; I > enjoy exploring new ways to solve existing problems, and a new, but > superior, solution isn't — strictly speaking — "mature". > > Longevity is where I part ways; I'd much rather have a clean break > than keep working around a wart. I think my overriding principle here > is correctness; I'm perfectly happy to do the work to fix my code if > it means adopting the *right* solution. > > None of this means that I think the core development process should > change. (Well, besides my fervent desire that they officially adopted > git — and yes, I do believe it *would* make a difference, centralized > "official" branch and all — but that's a discussion for another time > and a few beers.) Django has been very successful with the current > process, and I'd be very wary of tinkering with the foundations of > that success. > > But here's the great part: nothing is stoping anyone from hacking new > paths through the jungle on their own branches. What you *can't* get > — and honestly *shouldn't* get — is automatic recognition that your > branch is somehow officially supported, and all the notions of > stability, maturity, and longevity that go with that recognition. If > you know enough to make significant changes to Django, you also > probably know enough to fix the problems that can crop up due to your > changes — and that's not something we should expect from the average > developer who just wants to Get Work Done. > > So ... who has a GitHub account and some neat code to look at? :-) > > -- > 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.
