On Tue, Jul 26, 2011 at 2:08 PM, Daniel Friesen <[email protected]> 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 _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
