On Tue, Jul 26, 2011 at 2:08 PM, Daniel Friesen
<lists(a)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