On Tue, Jul 26, 2011 at 2:08 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:
RequestContext WAS an RFC. No one commented on it...
An e-mail to the list announcing the RfC would've been nice ;-) Also waiting for more than 1 other person to edit it would've been nice too. If you're not getting responses: pester people for them.
When it was originally committed it was a small change. It just grew as people improved it.
It started out small enough, yes...but it quickly grew to permeate a good chunk of core code. And then the architecture was changed halfway through, leading to the crap with __get(). Having more eyes on the RfC would've avoided this, IMHO.
Frankly if RequestContext and features of similar size had been committed to a branch instead of core, they would have bit-rotted there and never made it into core. Not to mention the relative size compared to things like ResourceLoader and Installer makes the negatives of svn branches relatively worse. Dozens of med-small changes getting shoved into branches and atempted to be merged into core?
Medium to small changes should still be done in trunk, and at no point in my original e-mail did I say otherwise. What I'm asking for here is for large refactors/rearchitecturings to be done in branches. RequestContext may not have *started out* as a large refactor, but the architecture implications are huge in the long run.
I'd love to do work in branches, have everyone actually try the branches out and add their improvements there, then get them reviewed into trunk. But that workflow... that's really git, not this svn mess we have now.
Let's please not turn this into a Git v. SVN debate again. Git is cool, and will perhaps solve some of our problems, but it's not a magic bullet to review/merging. I believe first and foremost the debt of currently unreviewed code should be near-zero before we even consider a migration. It would be very easy to work ourselves into a very similar situation using Git (tons of unreviewed pull requests--waiting in their branches for some love), and anyone who thinks we couldn't get backlogged in Git is kidding themselves.
Even if we kept this in the environment of svn and tried to use RFCs... people would have to actually discuss those RFCs... looking over the RFCs we have it looks like only 10% of them even get anyone discussing them. The rest just bit rot... So we're supposed to move from having a volunteer willing to code a feature and putting it into trunk, to having them putting up an RFC or putting it into a branch, and letting the code bit rot or RFC just sit there forever, and neither ever get into core?
I would rather people take the time to do it right than have a constantly unstable trunk that makes backporting damn near impossible. For example, you landing your Skin overhauls a day or two after branching REL1_17 was a poor decision on your part...and made backporting stuff and releasing 1.17 a huge pain.
This kind of comes back to the idea of code freezes (boo, I know...). I don't want to ever completely freeze trunk; that discourages contributions as we've discussed before. I'm just asking for a little bit of common sense from all around so we can keep trunk stable and push for more regular deploys and releases.
-Chad