On Mon, Sep 20, 2010 at 4:53 PM, Aryeh Gregor
<Simetrical+wikilist(a)gmail.com> wrote:
On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier
<robla(a)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