On Sat, Apr 17, 2010 at 7:30 AM, George Sakkis <george.sak...@gmail.com> wrote: > On Apr 15, 8:57 pm, Kevin Howerton <kevin.hower...@gmail.com> wrote: > >> The level of resistance I see to change or outsider code contribution >> is an enormous de-motivator for people (like me) to want to make any >> contributions in the first place. Why should I contribute a patch to >> your flawed architecture if I'm going to be talked down to, ridiculed, >> then eventually have the patch rejected because it breaks code in some >> edge-use-case? > > Good luck pushing backwards incompatible patches when as we speak > there are almost 400 open tickets with patches at accepted [1] and > "ready for checkin" [2] stage. Under these circumstances, backwards > compatibility is almost a red herring; the bigger issue IMO is the > increasing pile of bug fixes and solid, backwards compatible patches > languishing for months or years. > > A fork that encouraged and achieved a faster submit-review-accept- > commit lifecycle, even with the same stability, maturity, and > longevity policies, could be a breath of fresh air.
As I have said *many* times in the past - I would *love* for someone to do this. "Fork" is an extreme way of describing it -- I'd prefer to think of it as a "trunk-ready branch", in the same way that Linus relies on his lieutenants as a source of vetted patches for Linux trunk -- but I have no problem with the basic idea. If such a branch were to exist, and the person (or people) maintaining the branch (or branches) maintained the same levels of quality that Django's trunk expects - good architectural style, extensive documentation, testing, good commit messages, etc - I would use that branch as a source of material to commit to trunk *in a heartbeat*. Examining a small number of branches that have been curated by people I trust would be a much more effective use of my bug-fixing time than trolling the entirety of Trac. However, at this point, I would like to tell you a story about four people named Everybody, Somebody, Anybody, Nobody. Everybody agreed that a trunk-ready branch was needed. Somebody should have worked on the trunk-ready branch. Anybody could have worked on the trunk-ready branch. However, Nobody actually worked on the trunk-ready branch. It's *really* easy to stand on the sidelines and say "there are too many open tickets" or "progress isn't fast enough". It's another thing entirely to actually put the time and effort into doing the work. It's yet another thing to *still* be doing that same work 3 months (or, in my case, 4 years) later. So - if you want Django to progress faster - pitch in. If anyone wants to put the effort into maintaining a trunk-ready branch, go right ahead. Personally, I have the ability to merge branches from both git and hg, so you can't claim that the lack of an official DVCS is hampering you. Once you've got something worth merging, post to django-dev describing what you've got, and we'll take a look. 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.
