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.
--
Guillaume Paumier