Hi,
Le lundi 20 septembre 2010 à 23:23 -0400, MZMcBride a écrit :
Personally, I see a rough parallel between the concept of FlaggedRevs on a wiki and the current code development cycle. Nobody wants to make a contribution if it's going to sit in a queue indefinitely. It's much more satisfying to see your work (bug fix, article fix, whatever) go live in a relatively short amount of time.
Has there been any discussion about killing the branch system altogether? From my perspective, the initiation of branching has slowed down code pushes dramatically. This may be a false correlation I'm drawing, but I don't think so. There isn't nearly as much incentive to fix trunk when the branches are stable. But with that stability comes very little code development, aside from high priority Wikimedia Foundation projects being pushed into the branches directly by a few people. It also creates a lot more work (and commit noise) to merge from trunk rather than keeping trunk up and relatively stable (or stable enough to run the live sites). Has it been raised that going back to how things used to be might be better?
Alolita and I were chatting informally about this a few days ago. If I understand correctly the way we currently do things, trunk contains the development code, the wmfdeployment branch contains the code that Wikimedia sites run, and releases are branched from trunk.
Code updates on Wikimedia sites rarely happen, and when they do happen, they're huge, meaning a lot of small bugs & quirks all happen at the same time. Some developers don't want to commit unfinished or broken code to trunk, and yet trunk isn't reliable enough for production use.
I can see a number of reasons to have a stable trunk (also used by Wikimedia websites), that contains reviewed & tested code, along with a development branch that /can/ be broken: * Developers wouldn't be afraid to commit unfinished work to the development branch fearing they're going to break trunk. * Tarballs for non-Wikimedia MediaWiki users would be more stable. * Updates to Wikimedia sites would happen more often. * Getting to a release would be easier, since it would be the result of many incremental changes already merged into the stable trunk. * Wikimedia users would probably not mind encountering small bugs & quirks if it's the downside of benefiting from more regular code updates.
That said, I guess there are obvious drawbacks I'm not seeing.