Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Tue, Sep 21, 2010 at 4:09 AM, Rob Lanphier ro...@wikimedia.org wrote: 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. I would strongly recommend this. Having a running MediaWiki on a top 10 site is a very good form of quality control. And this way we are at least sure that code is pushed to the WMF serves on a regular interval. (Although I would prefer a shorter interval, I'm not sure whether this is feasible at this moment) Bryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
Hoi, At translatewiki.net we have identified the most often used messages. They consist of only core messages. We also keep them the same for as long as possible because they are a requirement for new languages conform the language policy. Because of the Usability Initiative moving into core, it would be extremely useful to know if there is a known agenda for this. It has already been announced that we want to update the composition of the most often used messages and it stands to reason that many of messages of the former Usability Initiative will be among them. Thanks, GerardM On 20 September 2010 22:35, Chad innocentkil...@gmail.com wrote: On Mon, Sep 20, 2010 at 4:12 PM, Trevor Parscal tpars...@wikimedia.org wrote: I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. Is there any sort of timeline for moving this stuff into core? I don't see any (long term) reason to leave these as extensions. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 21.09.2010, 6:09 Rob wrote: 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? Yes, if we really care what we release. Currently, trunk is quite broken due to Resource Loader and other things, which is absolutely understandable: no one can write a major feature that works flawlessly from commit one. Even in best scenario it will take at least a couple of weeks to be ready for Wikipedia. Then, there are lots of other things, and even more will be revealed during a thorough code review. And you shouldn't even try to assume that RL will work smoothly once rolled out to the WMF cluster - more fixes will be needed, as experience with previous JS-heavy Usability Initiative features shows. To summarize: we will have more or less sane code in 6-8 weeks from the time when our next CR begins. Only then it will make sense to branch for at least one month of final bug-squashing before releasing. All schedules faster than this are unrealistic. If WMF wants to keep a predictable release schedule, they should aim for full scaps at least once per month. Of course, everything said above is only my personal opinion and I'm not pretending to say The Absolute Truth(tm), but believe me, even I'm overpessimizing things, I'm not overpessimizing them too much. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] wikimedia commons slow lately?
In the last few days I've noticed sporadically that API calls time out on Wikimedia Commons and also that sometimes file downloads from Wikimedia Commons are really slow. Are there any performance problems going on? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Tue, Sep 21, 2010 at 6:29 AM, Max Semenik maxsem.w...@gmail.com wrote: On 21.09.2010, 6:09 Rob wrote: 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? Yes, if we really care what we release. Doesn't this kinda depend on what our priorities are and what the priorities of people running MediaWiki are? There are many demands placed by Wikipedia that most websites don't have. In the rest of the software world, high traffic websites are the *last* ones to upgrade, not the first. Don't we want to get the benefit of other people using the software more heavily before we put it on Wikipedia? I realize that this isn't how it's traditionally been done, but then again, I think our tradition has drifted. Once upon a time, trunk was very regularly deployed in production. Providing releases was merely an alternative to telling MediaWiki admins just go checkout trunk; that's what we're using. Now that we're a lot more cautious about what we put into production, we should question whether we still need to be even more cautious about what we release as MediaWiki. Currently, trunk is quite broken due to Resource Loader and other things, which is absolutely understandable: no one can write a major feature that works flawlessly from commit one. Even in best scenario it will take at least a couple of weeks to be ready for Wikipedia. Then, there are lots of other things, and even more will be revealed during a thorough code review. And you shouldn't even try to assume that RL will work smoothly once rolled out to the WMF cluster - more fixes will be needed, as experience with previous JS-heavy Usability Initiative features shows. To summarize: we will have more or less sane code in 6-8 weeks from the time when our next CR begins. Only then it will make sense to branch for at least one month of final bug-squashing before releasing. All schedules faster than this are unrealistic. If WMF wants to keep a predictable release schedule, they should aim for full scaps at least once per month. Assuming that ResourceLoader is still in pretty rough shape a month from now, then yeah, there's no point trying to foist that on MediaWiki users, no more than it will make sense pushing it to Wikimedia sites. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 21 September 2010 17:26, Rob Lanphier ro...@robla.net wrote: Doesn't this kinda depend on what our priorities are and what the priorities of people running MediaWiki are? There are many demands placed by Wikipedia that most websites don't have. In the rest of the software world, high traffic websites are the *last* ones to upgrade, not the first. Don't we want to get the benefit of other people using the software more heavily before we put it on Wikipedia? Speaking as someone who installs MW from tarball every now and then ... it feels like there's WMF development, for WMF purposes, and there's also an occasional tarball of variable quality. Arbitrarily declaring release time! from trunk for untested code means development is effectively forked between trunk-to-tarball and the WMF version. (This may then lead to the tarball being volunteer effort and the WMF version being paid effort, per Simetrical's note on the subject. I submit this might also turn out not to be a good idea.) I found really basic bugs in 1.16 betas (e.g. an install bug that made it literally impossible to install on a fresh server) that destroyed my confidence in 1.16 and left me still installing 1.15.x by preference. I submit that making the tarball version even less tested than at present is not going to get more testing achieved, but less. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 2010-09-21, Rob Lanphier wrote: On Tue, Sep 21, 2010 at 6:29 AM, Max Semenik maxsem.w...@gmail.com wrote: On 21.09.2010, 6:09 Rob wrote: 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? Yes, if we really care what we release. Doesn't this kinda depend on what our priorities are and what the priorities of people running MediaWiki are? There are many demands placed by Wikipedia that most websites don't have. In the rest of the software world, high traffic websites are the *last* ones to upgrade, not the first. Don't we want to get the benefit of other people using the software more heavily before we put it on Wikipedia? I realize that this isn't how it's traditionally been done, but then again, I think our tradition has drifted. Once upon a time, trunk was very regularly deployed in production. Providing releases was merely an alternative to telling MediaWiki admins just go checkout trunk; that's what we're using. Now that we're a lot more cautious about what we put into production, we should question whether we still need to be even more cautious about what we release as MediaWiki. It was my impression that production release had slowed down due to a lack of resources, not due to additional caution. Has this changed then? End users have an expectation that the software released by us is of the high standard we have always provided, and this is in part due to it being run on one of the worlds largest websites. End users are not and should not be guinea pigs for Wikipedia. The last release took a year, so I see no reason why we shouldn't delay this one until we are in a position to release reviwed and reasonably tested code. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Tue, Sep 21, 2010 at 12:26 PM, Rob Lanphier ro...@robla.net wrote: I realize that this isn't how it's traditionally been done, but then again, I think our tradition has drifted. Once upon a time, trunk was very regularly deployed in production. Providing releases was merely an alternative to telling MediaWiki admins just go checkout trunk; that's what we're using. Now that we're a lot more cautious about what we put into production, we should question whether we still need to be even more cautious about what we release as MediaWiki. Providing releases not an alternative to telling people to use trunk, it was a mark of actually releasing the software (as opposed to just having the source available). When we release the software we're making a commitment to the end user. The release should be something we're all proud of and are willing to stand behind. Trunk is not something I'm willing to stand behind and release to the public right now. It needs lots of review (over 10k revs since the last branch point) and lots of testing. In my experience, we don't get a whole lot of feedback from 3rd parties on a beta release, probably because people are naturally cautious, and a beta still carries the may have bugs connotation. OTOH, releasing to the sites tends to provide a *lot* of feedback, most of it incredibly valuable. You really can't beat a WMF deployment as the ultimate beta test group for MediaWiki. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Tue, Sep 21, 2010 at 9:36 AM, David Gerard dger...@gmail.com wrote: On 21 September 2010 17:26, Rob Lanphier ro...@robla.net wrote: Doesn't this kinda depend on what our priorities are and what the priorities of people running MediaWiki are? There are many demands placed by Wikipedia that most websites don't have. In the rest of the software world, high traffic websites are the *last* ones to upgrade, not the first. Don't we want to get the benefit of other people using the software more heavily before we put it on Wikipedia? Speaking as someone who installs MW from tarball every now and then ... it feels like there's WMF development, for WMF purposes, and there's also an occasional tarball of variable quality. I've experienced that myself. Arbitrarily declaring release time! from trunk for untested code means development is effectively forked between trunk-to-tarball and the WMF version. No one is suggesting that we be completely arbitrary. (This may then lead to the tarball being volunteer effort and the WMF version being paid effort, per Simetrical's note on the subject. I submit this might also turn out not to be a good idea.) Regardless of who gets paid by whom for what, it seems like further detangling the WMF production release process from the MediaWiki release process might not be a bad idea. I found really basic bugs in 1.16 betas (e.g. an install bug that made it literally impossible to install on a fresh server) that destroyed my confidence in 1.16 and left me still installing 1.15.x by preference. I submit that making the tarball version even less tested than at present is not going to get more testing achieved, but less. I don't think it's a matter of more or less, but rather a question of dependencies. How much testing did the installer get by being deployed to production on Wikimedia sites? There is going to be code that doesn't get tested at all (e.g. installer, sqlite support) solely by virtue of being deployed in WMF production. So, what do we gain by putting an arbitrarily long lead time of sitting in production prior to releasing a MediaWiki tarball? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] UsabilityInitiative extension is going to die
It has not been decided that any UsabilityInitiative code is moving into core, it's only been suggested. - Trevor On 9/21/10 3:35 AM, Gerard Meijssen wrote: Hoi, At translatewiki.net we have identified the most often used messages. They consist of only core messages. We also keep them the same for as long as possible because they are a requirement for new languages conform the language policy. Because of the Usability Initiative moving into core, it would be extremely useful to know if there is a known agenda for this. It has already been announced that we want to update the composition of the most often used messages and it stands to reason that many of messages of the former Usability Initiative will be among them. Thanks, GerardM On 20 September 2010 22:35, Chadinnocentkil...@gmail.com wrote: On Mon, Sep 20, 2010 at 4:12 PM, Trevor Parscaltpars...@wikimedia.org wrote: I'm hoping these extensions, especially WikiEditor and Vector can be examples of how to make use of ResourceLoader in extensions. Please note: if you are working on code that is aimed at deployment this year, you should not depend on ResourceLoader. We hope to have it running live in November, but that's not a guarantee. Is there any sort of timeline for moving this stuff into core? I don't see any (long term) reason to leave these as extensions. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] wikimedia commons slow lately?
On 21.09.2010 17:32, Paul Houle wrote: In the last few days I've noticed sporadically that API calls time out on Wikimedia Commons and also that sometimes file downloads from Wikimedia Commons are really slow. Are there any performance problems going on? In the moment, there are (or were?) API problems, possibly because someone or something flooded it. signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
Hi, Le lundi 20 septembre 2010 à 23:23 -0400, MZMcBride a écrit : Personally, I see a rough parallel between the concept of FlaggedRevs on a wiki and the current code development cycle. Nobody wants to make a contribution if it's going to sit in a queue indefinitely. It's much more satisfying to see your work (bug fix, article fix, whatever) go live in a relatively short amount of time. Has there been any discussion about killing the branch system altogether? From my perspective, the initiation of branching has slowed down code pushes dramatically. This may be a false correlation I'm drawing, but I don't think so. There isn't nearly as much incentive to fix trunk when the branches are stable. But with that stability comes very little code development, aside from high priority Wikimedia Foundation projects being pushed into the branches directly by a few people. It also creates a lot more work (and commit noise) to merge from trunk rather than keeping trunk up and relatively stable (or stable enough to run the live sites). Has it been raised that going back to how things used to be might be better? Alolita and I were chatting informally about this a few days ago. If I understand correctly the way we currently do things, trunk contains the development code, the wmfdeployment branch contains the code that Wikimedia sites run, and releases are branched from trunk. Code updates on Wikimedia sites rarely happen, and when they do happen, they're huge, meaning a lot of small bugs quirks all happen at the same time. Some developers don't want to commit unfinished or broken code to trunk, and yet trunk isn't reliable enough for production use. I can see a number of reasons to have a stable trunk (also used by Wikimedia websites), that contains reviewed tested code, along with a development branch that /can/ be broken: * Developers wouldn't be afraid to commit unfinished work to the development branch fearing they're going to break trunk. * Tarballs for non-Wikimedia MediaWiki users would be more stable. * Updates to Wikimedia sites would happen more often. * Getting to a release would be easier, since it would be the result of many incremental changes already merged into the stable trunk. * Wikimedia users would probably not mind encountering small bugs quirks if it's the downside of benefiting from more regular code updates. That said, I guess there are obvious drawbacks I'm not seeing. -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 21 September 2010 18:48, Guillaume Paumier gpaum...@wikimedia.org wrote: That said, I guess there are obvious drawbacks I'm not seeing. The hard part would be when you turn the dev branch into the production branch. Didn't MediaWiki have this problem before, which led to adopting the idea of trunk being live? Although obviously that's fallen by the wayside. It seems to be completing a cycle. Is there a sweet spot on this cycle, or is it better being a cycle? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 21.09.2010, 21:48 Guillaume wrote: I can see a number of reasons to have a stable trunk (also used by Wikimedia websites), that contains reviewed tested code, along with a development branch that /can/ be broken: Things are currently reversed: stable (but outdated) branch and bleeding-edge trunk broken 99% of the time. It doesn't really matter how we do the development, this or other way around, the only problem here is how often does the stable code gets updated. * Developers wouldn't be afraid to commit unfinished work to the development branch fearing they're going to break trunk. Even unstable trunk/branch is supposed to be runnable at all time, for semi-finished features there are private branches. Several sites (notably, translatewiki.net) run off trunk, so even bleeding-edge code shouldn't contain random chunks. * Wikimedia users would probably not mind encountering small bugs quirks if it's the downside of benefiting from more regular code updates. You got it wrong: the less often the updates go live, the more bugs they contain due to the amount of untested code. Frequent updates actually mean less bugs. That said, I guess there are obvious drawbacks I'm not seeing. The problem here is that our stable code is way *too* stable. Implementation details may vary. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Mon, Sep 20, 2010 at 10:09 PM, Rob Lanphier ro...@wikimedia.org wrote: 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. The reason why that drifted is because our review system was already overloaded before Brion left, and completely collapsed after that, because we failed to decentralize review properly. Today the practice is roughly that most employees get their code reviewed and deployed quickly by other employees or even themselves; volunteers (and maybe some employees) get their code reviewed by (generally) Tim whenever he has time, which he doesn't have enough of, so their code never gets deployed, or only once in a blue moon. This is a terrible situation, and we need to fix it so that all committed code is being reviewed and deployed on a regular basis before we even consider a release, IMO. 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? Yes. There's such a huge deployment backlog that even after careful review, there's going to be a flurry of new problems that are quickly discovered and will have to be fixed. I don't think it makes sense to try backporting the inevitable flood of fixes to a separate branch. Instead, we should wait until deployment and trunk are relatively in sync again (we are aiming for that, right?) and then wait a while for things to stabilize before branching. On Tue, Sep 21, 2010 at 12:26 PM, Rob Lanphier ro...@robla.net wrote: Doesn't this kinda depend on what our priorities are and what the priorities of people running MediaWiki are? There are many demands placed by Wikipedia that most websites don't have. In the rest of the software world, high traffic websites are the *last* ones to upgrade, not the first. Don't we want to get the benefit of other people using the software more heavily before we put it on Wikipedia? No, because other people are in a much worse position to track down bugs. MediaWiki developers are mostly heavy Wikimedia users, and Wikimedia users are much more likely to know about Bugzilla and know where they can complain about problems. Moreover, Wikimedia employs (practically?) all paid MediaWiki developers. If a third-party site has a bunch of serious problems, its sysadmins will probably throw up their hands and revert to an earlier version; if Wikimedia has a problem, it's likely that it can be fixed in minutes by its employees. Incremental deployment is a much better overall development strategy. Back in the days when we had scaps every week or two, as soon as a user reported a problem, we'd sometimes all say Oh, I remember the commit that must have caused that. I remember one time when a user reported a problem in #wikimedia-tech, and Brion and I had a commit conflict due to committing the exact same fix at the same time in (I think) something like two minutes or less -- both of us remembered the commit that touched that problem (me because I had committed it, he because he reviewed it) and the problem was obvious given the bug report. This was standard; whoever did the scap would make sure to hang around for a few hours in #wikimedia-tech to fix any problems, and savvy users who watched that channel would see the scap and know to report any regressions there immediately. There'd be only a handful, so all of them could be fixed quickly. Even if we didn't remember the exact commit, we'd have very few changes to look at in the log for the relevant files before we found the issue. At worst, we could almost certainly just revert the problematic commits with no conflicts. When you have months of old code being deployed at once, you're going to have tons of problems crop up all at once, instead of a few at a time, and they'll be harder to fix -- you won't remember what could have caused them, you'll have to look over more commits to find the problem, and when you do, you probably can't easily revert them. Trying to use third-party sites to test the code before we deploy it isn't feasible. First of all, few of them will test it and fewer still will report bugs, and that will only get worse if we release less-tested code. Second of all, Wikimedia will run into problems that other sites won't, and then all the problems I discuss above are inevitable. I think the correct course of action is to revamp our review structure so that we can return to the status quo ante of keeping deployment roughly in sync with trunk. We should aim for all commits should be reviewed for deployment less than a week after being committed -- perhaps just immediately reverted if they're
Re: [Wikitech-l] wikimedia commons slow lately?
On 21 September 2010 18:43, Robin Krahl m...@robin-krahl.de wrote: On 21.09.2010 17:32, Paul Houle wrote: In the last few days I've noticed sporadically that API calls time out on Wikimedia Commons and also that sometimes file downloads from Wikimedia Commons are really slow. Are there any performance problems going on? In the moment, there are (or were?) API problems, possibly because someone or something flooded it. Is this the problem that broke InstantCommons for pretty much everyone a few days ago? - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
Le mardi 21 septembre 2010 à 22:19 +0400, Max Semenik a écrit : On 21.09.2010, 21:48 Guillaume wrote: * Wikimedia users would probably not mind encountering small bugs quirks if it's the downside of benefiting from more regular code updates. You got it wrong: the less often the updates go live, the more bugs they contain due to the amount of untested code. Frequent updates actually mean less bugs. I thought that was what I said. If not, it's definitely what I meant. -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
2010/9/21 Chad innocentkil...@gmail.com: On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz hashar+...@free.fr wrote: - at T0 : new features frozen (no more new code) - at T1 : i18n frozen (no new message only bug fixes / typos) create an alpha snapshot for people to test new features As mentioned on IRC, i18n tracks development so closely that this is stage probably not needed. I've suggested freezes of varying degrees several times, and have been shot down each and every time. It discourages contributions or something like that It'll discourage people from committing to trunk, yes, and I think that's a bad thing. Branching then freezing the branch to various degrees is fine by me, but trunk should remain open to changes that are neither insane nor necessarily very stable. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 22.09.2010, 0:53 Chad wrote: On Tue, Sep 21, 2010 at 4:44 PM, Ashar Voultoiz hashar+...@free.fr wrote: - at T0 : new features frozen (no more new code) - at T1 : i18n frozen (no new message only bug fixes / typos) create an alpha snapshot for people to test new features - at T2 : freeze non urgent commits. create a beta snapshot I've suggested freezes of varying degrees several times, and have been shot down each and every time. It discourages contributions or something like that -Chad The only viable technical method of feature freeze is branching, otherwise you'll have to come up with messages like Okay, I declare a feature freeze. Whomever commits a new feature to trunk whill have their fingers smashed with a hammer. Not very practical. Some developers don't read wikitech-l, some are weeks behind on reading their mails. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 21/09/10 20:38, Aryeh Gregor wrote: snip I think the correct course of action is to revamp our review structure so that we can return to the status quo ante of keeping deployment roughly in sync with trunk. We should aim for all commits should be reviewed for deployment less than a week after being committed -- perhaps just immediately reverted if they're badly flawed, but still reviewed. snip The code review tool is a good start. Android use a similar system : https://review.source.android.com/ It acts as a purgatory for new patches. Once reviewed by another developer, the patch can be pushed to the release manager for approval. To help the release manager, maybe commits should be made to branches, reviewed and aggregated in one clean patch to be approved and then merged. This is something really easy to do with git, you can even edit your commit history to make it cleaner for review / release manager. The way it works : developer A creates a branch - commit - commit x 20 developer A ask for a review to developer B - more commits by developer A developer B developer A create a patch with test cases, documentation and so on. He then submit it to a special branch such as for-release-manager. Release manager look at the for-release-manager branch history. For each commit in there he either : - delay it for later review - pull approved patches and push them to trunk - reject the commit This tends to raise the signal/noise for other developers as well. I am not sure though how it can be translated to MediaWiki :-/ cheers, -- git clone Ashar://hashar/Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 9/20/10 8:23 PM, MZMcBride wrote: From my perspective, the initiation of branching has slowed down code pushes dramatically. This may be a false correlation I'm drawing, but I don't think so. I do not know enough about the history at Wikimedia to say, but in general, that's why people go to a branching system in the first place -- to introduce a buffer between development and production. Has there been any discussion about killing the branch system altogether? After much experience with branch-based deployment systems -- including designing and implementing some for largish web properties -- I now think branches are a bad idea for most website development. Every time I have worked with a system designed to isolate streams of development (dev, test, production) it has proven to be a net negative. Critical bugs are harder to fix, big refactorings are harder to put into production. Flickr argues that the entire concept of releases is based on an outmoded notion of shrink-wrapped software. For websites, you don't want a system that tries for unattainably perfect releases. Instead you want a system that makes deployment easy, and recovery from problems routine. Flickr deploys 10+ times a day, and does a revert of a deploy probably once a week. Check out this presentation, which explains the radically different development and deployment practices at Flickr: http://velocityconference.blip.tv/file/2284377/ There are pros and cons to this approach. It's not entirely appropriate for us because we do in a sense have a shrink-wrapped product -- MediaWiki -- and its releases ought to be stable. Also, Flickr relies on the entire team being experienced and careful; they can't afford even one bad or naive developer. -- Neil Kandalgaonkar |) ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Balancing MediaWiki Core/Extensions
In response to recent comments in our code review tool about whether some extensions should be merged into core MediaWiki, or not. I would like to try and initiate a productive conversation about this topic in hopes that we can collaboratively define a set of guidelines for evaluating when to move features out of core and into an extension or out of an extension and into core. unintended bias Arguments I have made/observed *against* merging things into core include: 1. Fewer developers have commit access to core, which pushes people off into branches who would have otherwise been able to contribute directly to trunk, inhibiting entry-level contribution. 2. Extensions encourage modularity and are easier to learn and work on because they are smaller sets of code organized in discreet bundles. 3. We should be looking to make core less inclusive, not more. The line between Wikipedia and MediaWiki is already blurry enough as it is. Arguments I have made/observed *for* merging things into core include: 1. MediaWiki should be awesome out-of-the-box, so extensions that would be good for virtually everyone seem silly to bury deep within the poorly organized depths of the extensions folder. 2. When an extension is unable to do what it needs to do because it's dependent on a limited set of hooks, none of which quite do what it needs. 3. Because someone said so. /unintended bias obvious bias I will respond to these three pro-integration points; mostly because I am generally biased against integration and would like to state why. I realize that there are probably additional pro-integration points that are far less biased than the three I've listed, but I am basing these on arguments I've actually seen presented. 1. This is a very valid and important goal, but am unconvinced and merging extensions into core is the only way to achieve it. We can, for instance, take advantage the new installer that demon is working on which has the ability to automate the installation of extensions at setup-time. 2. This seems like a call for better APIs/a more robust set of hooks. Integration for this sort of reason is more likely to introduce cruft and noise than improve the software in any way. 3. Noting that so-and-so said I should integrate this into core is not going to magically absolve anyone of having to stand behind their decision to proceed with such action and support it with logic and reason. /obvious bias If we are to develop guidelines for when to push things in/pull things out of core, it's going to be important that we reach some general consensus on the merits of these points. This mailing list is not historically known for its efficacy in consensus building, but I still feel like this conversation is going to be better off here than in a series of disjointed code review comments. - Trevor ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Sites using InstantCommons (was: wikimedia commons slow lately?)
2010/9/21 David Gerard dger...@gmail.com: Is this the problem that broke InstantCommons for pretty much everyone a few days ago? Unless there's another obvious source of this information, I think it would be useful for folks using the InstantCommons feature to be included in a public list somewhere -- I just started such a list here: http://www.mediawiki.org/wiki/Sites_using_InstantCommons I think this would help to create more visibility and awareness for this functionality, and greater sensitivity to accidental breakage. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Balancing MediaWiki Core/Extensions
On 22 September 2010 06:34, Trevor Parscal tpars...@wikimedia.org wrote: In response to recent comments in our code review tool about whether some extensions should be merged into core MediaWiki, or not. I would like to try and initiate a productive conversation about this topic in hopes that we can collaboratively define a set of guidelines for evaluating when to move features out of core and into an extension or out of an extension and into core. I'm generally against adding random extensions to the core, and there are many things I would like to rip of the core code if possible. I don't think we can come up with any clear rules. I'd imagine the rule would just be: * if it's useful to most users (=installations) of mediawiki, add it to the core With the most users getting a slightly less important if the feature is small but useful. I think that for example the new edit toolbar or one-button search are clearly such usability improvements, that only enhance existing core features and thus should be in the core, replacing the poor original ones where possible. Maybe also code quality and stability plays a role, since making an extension is kind of like making a branch - you can develop mostly freely and nobody cares. On the other hand the extension code might also need extensive rewriting if merged to the core. We have a quite free access policy even to the trunk code, so I do not see it as a limitation for including code in the core. On the other hand putting code in the trunk seems to be the only sure way to get your code reviewed even a little and deployed into WMF (it may still take a year). In short: I agree keeping the core slick and clean, but I think the case is clear for (at least part of) the usability enhancements. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
