On Mon, Sep 20, 2010 at 4:53 PM, Aryeh Gregor Simetrical+wikilist@gmail.com wrote:
On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier robla@robla.net wrote:
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). [...]
I think the primary objection would be that we don't want to do a release of code that hasn't run on Wikimedia for a while. We never have before, certainly. Not many people use wikis running RCs or betas compared to the number who use Wikipedia, so we'll get vastly fewer bug reports and thus ship a much buggier release if we don't scap the code well before we release it. It's also kind of sketchy to say that trunk is good enough for release when it hasn't been vetted as suitable for Wikimedia deployment.
This seems like a fine line of reasoning, though not one that I had thought was set in stone. For earlier releases, the MediaWiki releases benefited from deployment being pretty close to trunk, but presumably the reason why that drifted was because it became progressively harder for us to use our production environment as the de facto MediaWiki testbed.
So, 1.16wmf4 and 1.16 shared the same branch point, which was perhaps the start of a tradition. Is this the new rule? I don't have a strong opinion about whether that should be the case, but it does change how I think about 1.17 planning.
My understanding is that we will probably want a new deployment branch soon because of ResourceLoader (at least).
So whatever the timetable is, we need to have "scap" placed somewhere significantly before "branch for release". If we say a month before, then that would be five days ago according to your timetable, so I don't think that's a good idea.
I'm not sure what you mean by this. October 15 would be the branch point, not the release date. Are you saying that we have to release to production one month before even branching off of trunk?
Rob