Re: [Wikitech-l] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On 21/09/10 23:03, Max Semenik wrote: snip 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. That is actually the aim. The frozen date can be seen as a dead line, a day by wich you must have something 'ready to show'. If it is not ready, you have missed the deadline and the feature will made it in the next release. Keep the feature in your branch. The freeze itself might just last a couple weeks. Some developers don't read wikitech-l, some are weeks behind on reading their mails. Should they keep commit right to trunk ? Maybe some patches could just be sent by emails for review. I personally found it hard to commit anything without being on IRC or I will occasionaly face a silent revert. -- Ashar 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 Wed, Sep 22, 2010 at 4:21 PM, Ashar Voultoiz hashar+...@free.fr wrote: Some developers don't read wikitech-l, some are weeks behind on reading their mails. Should they keep commit right to trunk ? Maybe some patches could just be sent by emails for review. I personally found it hard to commit anything without being on IRC or I will occasionaly face a silent revert. -- Ashar Voultoiz Silent reverting shouldn't happen, anyone with commit access should have allow others to email me activated on their mw wiki account so that code review can send them emails when people comment or take action on code, although some older accounts might not have this enabled it is now a requirement to get access[1] and people don't/shouldn't be reverting without commenting on why anyway. Sending patches via email isn't a really good idea, because it isn't as easy to track them, easily lost/forgotten. Where as when directly submitted/attached to Bugzilla report it means that they can be easily searched and found if required and commented on, then just bugging someone on IRC to get it applied (Yes I know there is a backlog of patches on Bugzilla needing to be looked at[2]). [1]. http://www.mediawiki.org/wiki/Commit_access#Requesting_commit_access [2]. https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=doremremaction=runnamedcmd=Patches%3A%20Open%20and%20Need%20Reviewingsharer_id=9593 ___ 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 2:59 PM, Rob Lanphier ro...@wikimedia.org wrote: So, let's assume that the existing trunk (ResourceLoader and all) is a required part of 1.17. What's the earliest reasonable time we could expect to branch point for 1.17? Whenever the code is all reviewed. If Wikimedia deployed enough resources to reviewing code, I don't know, maybe that could be a month or two from now. If the status quo on code review is kept, it will probably be never. Of course, we could just accept that review won't keep up with trunk, if we want to just give up on ever getting volunteer code deployed in a timely fashion again. In that case, we could branch from the last reviewed revision, and base both production and 1.17 off that. But I'm kind of hoping that's not necessary or desired by the powers that be. ___ 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 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] 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
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] 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] 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] MediaWiki 1.17 release target (Re: UsabilityInitiative extension...)
On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride z...@mzmcbride.com wrote: Quite a few people are under the impression that MediaWiki 1.17 will be released in October or November of this year. I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. 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). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. 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 Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier ro...@robla.net wrote: I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. 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). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. 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. 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. ___ 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...)
I think someone (RobLa) is planning on populating these areas of the wiki as more meetings take place - so I'm not sure we should be so critical of the number of links in [[Meetings/Release]] - but yeah, you've got a fair point, if we are going to be keeping meeting notes in a public place (a big thank you should go to RobLa here!) some links to the meetings page would help make the public notes a little more public. I would add some myself, but I'm not sure I know where the link to [[Meetings]] should go. I sometimes wonder if we are better at talking about things than doing them. How easy would it be to just add a link the [[Meetings]] and be done with it. Yet, here we all are typing away about it... Not sure if this is all bad... but it doesn't seem all good. - Trevor On 9/20/10 5:01 PM, Guillaume Paumier wrote: Hi, Le lundi 20 septembre 2010 à 16:47 -0700, Rob Lanphier a écrit : I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 The only incoming link for [[Meetings/Release/2010-07-14]] is [[Meetings/Release]], whose only incoming link is [[Meetings]], which doesn't have any incoming link. Discussions involving as major a decision as a release date should probably be a little more advertised :) ___ 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 lundi 20 septembre 2010 à 17:08 -0700, Trevor Parscal a écrit : I think someone (RobLa) is planning on populating these areas of the wiki as more meetings take place - so I'm not sure we should be so critical of the number of links in [[Meetings/Release]] - but yeah, you've got a fair point, if we are going to be keeping meeting notes in a public place (a big thank you should go to RobLa here!) some links to the meetings page would help make the public notes a little more public. I would add some myself, but I'm not sure I know where the link to [[Meetings]] should go. I sometimes wonder if we are better at talking about things than doing them. How easy would it be to just add a link the [[Meetings]] and be done with it. Yet, here we all are typing away about it... Not sure if this is all bad... but it doesn't seem all good. Oh, I'm not specifically criticizing the number of links. I actually think it's great the notes are being posted publicly. I'm just generally commenting on the fact that it's difficult to find the information if you don't know it's even there. Adding a link to [[Meetings]] is easy, but probably not much more helpful in attracting eyeballs. I guess my main general point was Keeping people informed is as easy as sending an email to wikitech-l. -- 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 Mon, Sep 20, 2010 at 8:08 PM, Trevor Parscal tpars...@wikimedia.org wrote: I sometimes wonder if we are better at talking about things than doing them. How easy would it be to just add a link the [[Meetings]] and be done with it. Yet, here we all are typing away about it... Not sure if this is all bad... but it doesn't seem all good. We're not always sure where or how something should be done, so we talk about it and look for ideas. Take this issue for example, we're not sure where something should be linked, but mention it here knowing that someone else probably has some ideas -- that person is then free to be bold and add a link wherever he thinks would be good. Speaking more generally, the reason that people might be better at talking about doing things rather than doing them themselves could be because they're afraid they'll just get reverted if they try to be bold. -- Casey Brown Cbrown1023 ___ 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 4:53 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: On Mon, Sep 20, 2010 at 7:47 PM, Rob Lanphier ro...@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 ___ 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...)
Rob Lanphier wrote: On Mon, Sep 20, 2010 at 4:01 PM, MZMcBride z...@mzmcbride.com wrote: Quite a few people are under the impression that MediaWiki 1.17 will be released in October or November of this year. I don't think there's been many public references to this, but that is more or less the timeframe many of us have discussed. There is at least one public reference here: http://www.mediawiki.org/wiki/Meetings/Release/2010-07-14 Thank you for this. I'm sure a lot of people will be watching the root page with a lot of interest. I agree with a lot of the other posters in this thread that publicly posting notes like this is a really good step in the right direction. :-) Several of us have a desire to get back on a more regular release cadence with MediaWiki releases generally, and MediaWiki 1.17 seemed like a good place to start. I think there's a much greater desire for the live Wikimedia sites to be updated more regularly, far more than MediaWiki being released more regularly. Not that they're mutually exclusive, though with the current branch system, I suppose they could be, which raises further questions. 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). We really haven't had an organized discussion of the topic since that one meeting above, but maybe this email thread can be that conversation. Nothing about the schedule is carved in stone, so now is as good a time as any to bring up any objections to that timeline. 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? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
