Aryeh Gregor wrote:
On Wed, Oct 20, 2010 at 11:56 PM, Rob Lanphier robla@wikimedia.org wrote:
- 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).
- 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.