Aryeh Gregor wrote: > On Wed, Oct 20, 2010 at 11:56 PM, Rob Lanphier <[email protected]> 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. _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
