Aryeh Gregor wrote:
On Wed, Oct 20, 2010 at 11:56 PM, Rob Lanphier
<robla(a)wikimedia.org> wrote:
1. Is the release cadence is more important
(i.e. reverting features
if they pose a schedule risk) or is shipping a set of features is
important (i.e. slipping the date if one of the predetermined feature
isn't ready)? For example, as pointed out in another thread + IRC,
there was a suggestion for creating a branch point prior to the
introduction of the Resource Loader.[1] Is our priority going to be
about ensuring a fixed list of features is ready to go, or should we
be ruthless about cutting features to make a date, even if there isn't
much left on the feature list for that date?
IMO, the best release approach is to set a timeline for branching and
then release the branch when it's done. This is basically how the
Linux kernel works, for example, and how MediaWiki historically worked
up to about 1.15. We'd branch every three months, then give it a
while to stabilize before making an RC, then make however many RCs
were necessary to stabilize. This gives pretty predictable release
schedules in practice (until releases fell by the wayside for us after
1.15 or so), but not anything that we're forced to commit to.
(Actually, Linux differs a lot, because the official repository has a
brief merge window followed by a multi-month code freeze, and actual
development occurs in dozens of different trees managed by different
people on their own schedules. But as far as the release schedule
goes, it's "branch on a consistent timeframe and then release when
it's ready", with initial branching time-based but release entirely
unconstrained. So in that respect it's similar to how we used to do
things.)
I don't think it's a good idea to insist on an exact release date, as
Ubuntu does, or even to set an exact release date at all.
+1. Fuzzy dates are good, but setting a fixed date is not.
This doesn't mean that WMF shouldn't be more lazy in allocating
resources for the release, though.
Does anyone care exactly when MediaWiki is released?
If so, why can't
they just use RCs? The RC tarball is just as easy to unpack as the
release tarball.
Because RC have that unstable feeling. So many people end up not testing
the RCs, which make wmf deploys much more important.
I also don't think it makes any sense for us to do
feature-based
releases. The way that would work is to decide on what features you
want in the release, then allocate resources to get those features
done in time.
We have had too much chaotic releases. I don't think we should aim for
release delaying features for now.
It's fine planning a set of features, or tweaking a bit the dates to
stabilize some feature / release before a branch merge.
Plus, we don't have such big features missing. A normal release wil lbe
just a lot of small fixes and tiny new features.
We have a number of them for 1.17 but that's an anomaly (and due to the
delay).
3. How deep
is the belief that Wikimedia production deployment must
precede a MediaWiki tarball release? Put another way, how tightly are
they coupled?
IMO, it's essential that Wikimedia get back to incrementally deploying
trunk instead of a separate branch. Wikipedia is a great place to
test new features, and we're in a uniquely good position to do so,
since we wrote the code and can very quickly fix any reported bugs.
Wikipedia users are also much more aware of MediaWiki development and
much more likely to know who to report bugs to. I think any site
that's in a position to use its own software (even if it's
closed-source) should deploy it first internally, and if I'm not
mistaken, this is actually a very common practice.
I consider that very important. Specially for a big release such as the
upcoming one. A WMF deployment will get it more tested in a few weeks
than many months by normal third-party users (specially in feedback terms).
I don't oppose to having a wmf branch. It comes from the admission that
there are live patches, and having a branch actually documents them and
allow us to see what is really deployed.
However I completely agree with Aryeh on the importance of wmf running
almost trunk. The process itself could be automated, eg. a cron job
automatically branching from trunk each Tuesday morning, and having the
deploy programmed for Thursday. NB: I'm assuming a model where everyone
can commit to the branch in the meantime.
Beyond that, this development model also gives
volunteers immediate
reward for their efforts, in that they can see their new code live
within a few days. When a Wikipedia user reports a bug, it's very
satisfying to be able to say "Fixed in rXXXXX, you should see the fix
within a week". It's just not the same if the fix won't be deployed
for months.
+10.