Rob Lanphier wrote:
On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride
<z(a)mzmcbride.com> wrote:
Quite a few people are under the impression that
MediaWiki 1.17 will be
released in October or November of this year.
I don't think there's been many public references to this, but that is
more or less the timeframe many of us have discussed. There is at
least one public reference here:
http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14
Thank you for this. I'm sure a lot of people will be watching the root page
with a lot of interest. I agree with a lot of the other posters in this
thread that publicly posting notes like this is a really good step in the
right direction. :-)
Several of us have a desire to get back on a more
regular release
cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed
like a good place to start.
I think there's a much greater desire for the live Wikimedia sites to be
updated more regularly, far more than MediaWiki being released more
regularly. Not that they're mutually exclusive, though with the current
branch system, I suppose they could be, which raises further questions.
The goal, as I recall, was branching October 15 or
thereabouts, with
first beta in November, and a release sometime after that (perhaps as
late as January, depending on how well we do with the first beta). We
really haven't had an organized discussion of the topic since that one
meeting above, but maybe this email thread can be that conversation.
Nothing about the schedule is carved in stone, so now is as good a
time as any to bring up any objections to that timeline.
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?
MZMcBride