Re: [Wikitech-l] Code review process (was: Status of more regular code deployments)
Thank you for posting this Erik. I initially didn't reply on this thread because to me it just seems to be the same as the 3 or 4 times we've had the same discussion before. No technical or procedural change is going to solve a problem that is ultimately caused by a lack of time assigned to it. I was somewhat disappointed by the suggestion that the onus should be on volunteers to find a reviewer for their code, as this is just as unworkable without staff time assigned to doing it - and perhaps could be even more demotivating than the status quo. Having review be a portion of staff time was always how I assumed it would be arranged. The justification for not assigning time to review has often been that one person or team doing it all the time would result in burn-out, and I agree with this. As a (part-time) developer I certainly wouldn't want to spend all my time doing service work, even for just one or two weeks at a time. The idea of having a single person/team assigned for each deploy/release cycle is nice, but I think that it would lead to burn-outs and conflicts with existing responsibilities those people have. Whatever model is implemented, I hope it can finally be successful. I reject the notion that we need a change in our review processes. Empirical evidence shows that when staff time is assigned to it, our code review system *does* work. (Of course there are always minor changes that would improve efficiency, such as automating some of the reporting tasks that have traditionally been done manually.) Updates on how this is going would be nice, as again it took MZMcBride to bring it up before anyone senior posted about it - and this is still the big issue for volunteer developers. Cheers, Robert On 2011-06-01, Erik Moeller wrote: On Wed, Jun 1, 2011 at 4:50 PM, Brion Vibber br...@pobox.com wrote: This is one of the reasons I tend to advocate shorter development/review/deployment cycles. By keeping the cycle short, we can help build up regular habits: run through some reviews every couple days. Do a deployment update *every* week. If you don't think your code will be working within that time, either work on it outside of trunk or break it up into pieces that won't interfere with other code. With a long cycle, review gets pushed aside until it's no longer habit, and gets lost. Right. And just to weigh in quickly on the resources issue -- the review/deploy/release train is clearly not moving at the pace we want. This does affect WMF staffers and contractors as well, but we know that it's especially frustrating for volunteers and third party committers. We kicked around the idea of a 20% rule for all funded engineers (IMO not just senior staff) in Berlin and in the office yesterday, and I think Roan mentioned it earlier in this thread: i.e. ensuring that every WMF-funded engineer spends one day a week on service work (code review, design/UX review, deployment, shell bugs, software bugs, bug triaging, etc.). An alternative model is to have rotating teams that do this work. I personally prefer the 20% model because it gives more consistency/predictability and less churn, but I'm curious what other folks think, and I'm comfortable with us continuing this discussion openly on this list. Whether that would get us to a healthier balance remains to be seen, but I think there's pretty broad agreement that adding more support to the review/deployment/release process is a necessary precondition for any other process changes like moving towards pre-commit review. Clearly what's been said in this thread is true -- there are lots of things that can be done to reduce our technical debt and make it easier to accommodate and manage new changes, but without added dedicated capacity, the train won't move at a speed that we're happy with. We can't change that overnight (because we need to figure out the right rhythm and the right processes together), but we will change it. Erik -- 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Converting to Git?
On 2011-03-23, Neil Kandalgaonkar wrote: On 3/22/11 6:05 PM, Rob Lanphier wrote: Our code review tool is pretty nice, but we can't let it be the tail that wags the dog. At the risk of being impolite -- our code review tool is not that nice. (I don't expect that anyone who worked on it would even disagree with me here.) It happens to be our home grown tool, and it uses a framework that more of us are familiar with. But it's not such an overwhelming asset that we should consider staying on SVN because of it. In 2011 there are lots of code review frameworks out there to choose from. There's nothing stopping a Git backend being created for the code review extension. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] WMF and IPv6
I believe the WMF intends to participate in World IPv6 Day [1], additionally they publish some IPv6 statistics [2]. See also the IPv6 deployment page [3]. [1] http://isoc.org/wp/worldipv6day/ [2] http://ipv6and4.labs.wikimedia.org/ [3] http://wikitech.wikimedia.org/view/IPv6_deployment Robert On 2011-02-03, George Herbert wrote: I just checked and determined that there appear to be no records yet for the WMF servers. I have to admit to having been negligent in examining the IPv6 readiness of the Mediawiki software. Is it generally working and ready to go on IPv6? Does the Foundation have a IPv6 support plan ready to go? The importance of this is going to be high in the Asia-Pacific region within a few months: http://www.potaroo.net/tools/ipv4/rir.jpg (APNIC runs out of IPv4 space to give to providers somewhere around August, statistically; RIPE in Feb or March 2012, ARIN in July 2012). In each region, ISPs then will start running out of IPv4 to hand out within a month to three months of the registry exhaustion. We have a few months, but by the end of 2012, any major site needs to be serving IPv6. Out of curiosity, is anyone from the Foundation on the NANOG mailing lists? -- -george william herbert george.herb...@gmail.com ___ 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] Inclusion request for the Validator extension
On 2011-01-13, Jeroen De Dauw wrote: Hey, Although the tag name issue is a valid point, it has nothing to do with my original email. So please start a separate discussion rather then hijacking this thread. It is entirely to do with your originl e-mail, as it is a valid reason why your original request (inclusion of Validator in core) should not be carried out at this time, and discussion of it is important (at least if you intend to improve the extension to overcome this issue). Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
On 2010-12-03, Rob Lanphier wrote: Hi everyone, On IRC, Trevor lead the charge to Etherpad!, and some of us followed. This was the result: http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.17 It is unclear to me whether the plan is to branch from the latest reviewed code or trunk HEAD, assuming the latter then I think that code review needs to be a part of the schedule as it is by far the most time consuming part of the process and presumably needs to be complete before a deployment. The schedule suggests an intial deployment in January, but my understanding is that even if there were no further commits it would still take until March for it to catch up with HEAD. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Draft plan for 1.17 branch next week (Code review and making it to 1.17)
On 2010-12-04, Roan Kattouw wrote: 2010/12/4 Robert Leverington rob...@rhl.me.uk: The schedule suggests an intial deployment in January, but my understanding is that even if there were no further commits it would still take until March for it to catch up with HEAD. March has been mentioned by a few people now, and now you're even suggesting that /even with no further commits/ it would take that long. To me that seems overly pessimistic. The code review backlog in /trunk/phase3 was 775 revisions last time I checked (Saturday around 01:15 UTC). It shouldn't take 3 months to catch up with that. The pessimism was not intentional, just noting my understanding of what others said. What you say sounds reasonable. Of course less than 3 months doesn't necessarily mean it'll be a manageable amount of time, and there's WMF-deployed extensions to consider too. So I do think we should look at where the unreviewed revs are concentrated; if it turns out they're mostly recent, that'd be a strong case for moving the branch point into the past. On the other hand this creates a huge amount of work in identifying and backporting any essential bug fixes between the branch point and HEAD at branching - I imagine probably more than it alleviates (albeit for different people). Either way this is something that needs to be considered prior to branching as it will change the schedule and allocation of resources (to me the current schedule seems overly optimistic in this respect). Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] recursiveTagParse makes data vanish
On 2010-11-17, Dmitriy Sintsov wrote: What if my ajax call PHP function is required for extension's client scripts only and is meaningless to bots? (On-page interactivity). Why should everything to be an API, ajax is more than bots? Because it provides a consistent, clean framework for making and handling requests with the potential to reduce duplication in a lot of cases. The API is not just for bots. Adding an API module is fairly trivial and is the correct way to provide AJAX interactivity. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On 2010-11-02, Rob Lanphier wrote: We'd then pick off the keywords as we step through the process (e.g. once it's reviewed, remove the need-review keyword). We could then generate three queries to get us the three queues I alluded to above: 1. Issues with all three keywords. These are features that someone would like to see deployed and launched, but needs to be reviewed first. 2. Issues with need-deploy and need-enabled. These are extensions that have been reviewed, but need to be checked into the production branch 3. Issues with need-enabled only. These are extensions/features that just need action from ops. Does this make sense? If so, I'll add the keywords and start documenting the process and retrofitting existing feature requests into this system. This sounds like a good idea, however I think it would be better to only use a single keyword per state - and as each state is completed it is replaced by the next keyword. Otherwise you cannot just do a keyword search for need-enabled or need-deploy and find just the ones that can actually be processed. Additionally, since this system seems to be targetted at extensions, I think it might be more intuitive to have them labelled as such, i.e.: - extension-need-review - extension-need-deploy - extension-need-enabled Currently I believe the need-review keyword is used for patches that need review aswell as extensions, so using a conflicting namespace could become confusing. Finally, some extensions have a bug report open purely for their review and several open for being enabled/deployed - so this might be a good time to consolidate extension review/enable bugs. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On 2010-11-02, Trevor Parscal wrote: The idea of dividing deploy and enable seems strange to me. Only in the case of a feature-flagged bit of core code or extension which has not been deployed yet would this even work, in all other cases deployment is enabling because you've just updated active code. Additionally, the idea of having a division between need-review and need-deploy is counter to the arguments made in D.C. which were that essentially review is a by-product of deployment, not the other way around. Marking something as need-deploy shows reviewers what should be reviewed and merged into the deployment branch. So essentially all we need is a single queue or tag, which indicates this is a revision that affects deployed/to-be-deployed software. I wasn't present in D.C. so can't comment on the arguments made there, but it is my understanding that there are people who are responsible for reviewing code who aren't able/willing to deploy it - so this isn't something that has a binary state. Also, I think it would be useful to document the movement between review, deployment, and enabling - as even if this is done by a single person they might not be able to complete it in one session, and the transparency is nice. An even in this case where I've reduced it to a single tag, someone has to actually mark revs with that tag, but the nature of the tag isn't really based on any single revision, it's based on a resource. Code-review needs a way to tag files and directories rather than just revisions. These resource-tags would be persistent between revisions, allowing us to say show me 'new' revisions that affect 'deployment' files and directories or some such. This would likely be core + some extensions. The more work we have to do over and over (such as adding and managing tags on revisions) the less likely we are to keep it up. Correct me if I'm wrong, but I believe we're talking specifically about completely unreviewed extensions that need looking at entirely - not incrementally. Certainly once an extension has been initially reviewed and deployed, the existing code review system would come in to effect - and I don't think we need to change anything with that at the moment. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Vector extension naming
On 2010-10-13, Trevor Parscal wrote: Thank you, everyone, for responding so far (not trying to stop you here). Here's where it seems we're at. 1. Having an extension called Vector is neither descriptive or clear, and it is anticipated to cause confusion. 2. System administrators are not enjoying things being switched around on them, and would prefer the name either not change or for the extension to be merged into core. 3. 3 out of 5 code reviewers are voting that it should be merged into core (Brion and Tim have not weighed in yet). I did not realise decisions were now being voted on by code reviewers, this is very concerning. My original hesitation to merge Vector (not to be lumped together with WikiEditor) into core was always that we were going to be extremely lean on CodeReview prior to 1.17 due to Tim Starling's limited availability right now. Since then we've added Roan, Chad, and me, and even brought Brion back for a bit part time to help out, thus increasing our capacity beyond what was originally expected. I think under these new circumstances, if we have Roan and Chad willing to help me integrate it into core and sign off on it, it will likely be of very little additional effort for our release manager (Tim Starling) to sign off as well, thus alleviating my apprehension about merging it prior to 1.17. Since it has been deployed to the Wikimedia cluster, has it not already had more than sufficient review that we would be comfortable including it in a release? So, unless there's any objection, I will go ahead and merge the Vector extension into core as part of the Vector skin immediately, rather than waiting until after 1.17. That would be great. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Is the $_SESSION secure?
On 2010-09-24, Dmitriy Sintsov wrote: One probably can rename it to another temporary name? Then move to final location during the next request, according to previousely passed cookie? Speaking of cookies, there are millions ways of looking at them, FF's WebDeveloper extension, HTTP headers extension, Wireshark application to name just few. Absolutely non-secure, when unencrypted. Session data is not stored in cookies, only a unique session identifier is passed to the client. 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 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] Community vs. centralized development
On 2010-09-07, Ryan Kaldari wrote: I am both a long-time community member and a new WMF paid developer (in the SF office) so I think I'm in a unique position to clear up some misconceptions. First of all, all this talk of secret listservs and IRC channels is malarkey. Yes, there are private listservs and IRC channels. All of them are private for very specific and well-established reasons. Most of them are only used in very specific circumstances (for example if there was a security breach that needed to be discussed privately) and tend to be very low traffic. They are not the places where important decisions are made. This has been repeated several times in this thread. But from a volunteers perspective it is difficult to imagine where discussion between staff members is going on then. Until after this topic started I have seen very little discussion of staff projects on this mailing list, no discussion on the IRC channel, and very little on the MediaWiki wiki. These are three of the main enshrined development channels, and up until this discussion of staff activity on them was minimal. I find it difficult to believe that this is all the discussion that is going on, or is everything else in face to face meetings - if so where are the minutes and notes for these, because MediaWiki.org seems the obvious place to put them? And furthermore where is all the project documentation that you say has been produced? Sorry, but from the point of view of a volunteer the only logical reason there is/was no activity in any of these development channels is that there must be various private ones. Secondly, the idea that developers here in the office don't interact with the community is absurd. The developers here interact with the community constantly. We discuss community opinion and ideas, we talk with community members all day long on IRC, listservs, and on-wiki. I'm amazed that the developers here ever get anything done considering how much time they spend documenting what they are working on and interacting with the community about it. The problem is they can't interact with everyone everywhere: Code Review, IRC, listservs, the Tech Blog, meta, Signpost, etc. So no matter what, someone is going to feel like they are out of the loop. This may well be true for the community in general, but this discussion is specifically about the volunteer developer community, which is clearly being left out of the loop in a large respect - otherwise this discussion would not exist. They are arguably the most important members of the community from a technology perspective as volunteer developers have the time and initiative to actively improve MediaWiki, and development cannot survive on ideas and feedback alone. By readily involving the dev. community the WMF creates an environment where there is the potential (not everything will recieve a community response, but the potential for it then exists) for more ideas are implemented cost-free, and paid development time can be focused more on what it needs to be to maximise gain for all stakeholders. The WMF is extremely interested in new developers interacting with the community, indeed they try to hire developers from within the community when possible. The notion that the foundation is hiring corporate drones who are only going to listen to their task masters is completely unfounded. Yes, there have been situations where the foundation has been given grant money for very specifically defined projects and those projects have been implemented without adequate community involvement. Everyone (including the foundation) knows that that's not how we want to do development in the future. As has been discussed throughout the past year, the foundation wants to move away from accepting any money with strings attached and away from relying on grants in general. Hopefully, if this year's fundraiser goes well, we won't have to worry about these issues in the future. There is nothing wrong with recieiving technology grants for specific projects, and with the correct transparency and integration I think they can be a good thing as they are likely to improve areas that were previously ignored and bring new developers, and their insight, on to the paid staff. Transparency and integration were the main things the usability initiative lacked, but on their whole the contribution to MediaWiki and the WMF projects is undoubtedly very large. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 2010-09-02, Aryeh Gregor wrote: Over the last couple of years, MediaWiki development has moved from being almost entirely volunteer-based to having a large contingent of paid developers. A lot of people have noted that this has led to a lot of work being done without much community involvement. Just for a basic statistic, in July, I estimate that about 90% of non-localization commits to extensions/UsabilityInitiative/ were by paid employees. (I use employee loosely in this post, to include all paid staff, such as contractors.) By contrast, about 25% (ballpark figure) of non-localization commits to phase3/ were by paid employees, and the number of volunteer commits to phase3/ was much higher than the total number of commits to UsabilityInitiative, so this isn't just a matter of community members not doing as much work overall. ... I'd just like to repeat what others have said, and note that I agree with Aryeh's comments and replies 100%. It's very dissapointing to see many of the suggestions discarded almost immediatley by most of the staff members replying as unrealistic. These are well thought out points and I think a decent amount of consideration should be given to all of them, regardless of anyones predispositions. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 2010-09-03, Neil Kandalgaonkar wrote: On 9/3/10 4:55 PM, Robert Leverington wrote: It's very dissapointing to see many of the suggestions discarded almost immediatley by most of the staff members replying as unrealistic. I can't speak for others, but I have to say that the idea of having paid developers without a space for them to work together in person is very unrealistic. In the past all paid developers worked remotely (at least, not in the same office as one another), and there still are paid developers who work remotely. Additionally, all volunteers work remotely. Based on my experience with MediaWiki I would say that development in the past was significantly more efficient and community involved than it is currently. I can understand how this suggestion in particular might not be entirely realistic, but it is only one of the suggestions that have been put forward and regardless of whether it is taken as a whole has some amount of merit in the context of this discussion. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
On 2010-09-02, MZMcBride wrote: Aryeh Gregor wrote: What's the alternative? There are *always* going to be many more ideas than implementers. Ideas are cheap. Wikimedia has to decide which features are the most critical to invest developer time in. Their decision is not going to make everyone happy. The only guarantee you can ever have is if you do it yourself. Happily, MediaWiki is open-source, so you *do* have that option! On practically any other major website, you couldn't add a feature no matter how much you wanted to. The current status of Wikimedia code deployment makes this no longer applicable to Wikimedia either. See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=23268 https://bugzilla.wikimedia.org/show_bug.cgi?id=18461 https://bugzilla.wikimedia.org/show_bug.cgi?id=15308 https://bugzilla.wikimedia.org/show_bug.cgi?id=14207 https://bugzilla.wikimedia.org/show_bug.cgi?id=15165 All asking for a feature which has been implemented since April 2008 to be reviewed and installed. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Some suggestions about the edit page.
On 2010-01-13, Tei wrote: %% The Death of Wiki %% Ultimatelly, al wikis lose the war against entropy and are abandoned. This will hit all wikipedia wikis, and all based on mediawiki. While you can't stop that, you can code something so the resulting dead body of wiki is not pure shit. A possible idea could be to auto-protect pages without edit in N years (4 years), and save id of the last know good version, this can be done flagging the pages as dirty after a edit, and flag pages as clean wen a logged editor say so. Something like Page Milestones. Maybe the History view of a page sould list first the last 10 milestones (newer first), then the dump of all edits. There are probably about more than 10 years to think about this issue. The AbsenteeLandlord extension may fulfil this to a certain extent. [1] [1] http://www.mediawiki.org/wiki/Extension:AbsenteeLandlord Robert signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FW: [FOSDEM] News : Call For Developer Rooms
On 2009-10-26, Siebrand Mazeland wrote: Forwarding a post with a call for developer rooms at FOSDEM 2010 (2010-02-06 to 2009-02-07). Last year we made a request for a dev room and it was denied. A question and a proposal, in case the question is to be answered with 'yes': Q: Would we like MediaWiki to be present at FOSDEM 2010? There are many European developers, and the success of the Berlin meetup suggests doing something at FOSDEM would be worthwhile. P: I would like to try and make a proposal with other CMS projects (like Joomla, Drupal, Typo3, Wordpress, etc.) for a dev room. Reason for not applying for a MediaWiki dev room' is that I expect that this will not be honored because it has too tight a scope. I spoke to one of the people of the program committee last year, and I was advised to find a broader scope. Alternatively we could request a dev room with other wiki engines (tikiwiki, docuwiki, etc.). Personally I have no preference on which projects we would cooperate with, just as long as we will make a proposal that will get us the best chance to have a presence at FOSDEM 2010. Open to suggestions... I spent a bit of time discussing this with you and a few of the FOSDEM staff a while ago and this seems like the best way to do it. Additionally, I would like a reply from people interested in coordination of the talks in this event. In case we would get a dev room together with the other CMS/wiki projects, I would expect that we would have slots for ~4 talks on MediaWiki, and possibly one or two talks in cooperation with the other projects on common problems/solutions/whatever. I will be coming to FOSDEM '10 and am interested in helping to coordinate talks. -- Robert Leverington http://rhl.me.uk/ signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announce: Brion moving to StatusNet
On 2009-09-28, Brion Vibber wrote: I'd like to share some exciting news with you all... After four awesome years working for the Wikimedia Foundation full-time, next month I'm going to be starting a new position at StatusNet, leading development on the open-source microblogging system which powers identi.ca and other sites. Good luck. Erik Moeller will be the primary point of contact for WMF tech management issues starting October 12, until the new CTO is hired. I'll support the hiring process as much as I can, and we're hoping to have a candidate in the door by the end of the year. Is the Senior Software Architect position that was originally going to be opened for you to move to still planned, or will the new CTO have a simillar number of responsibilities? -- Robert Leverington http://rhl.me.uk/ signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW test infrastructure architecture
Hi, On 2009-08-11, dan nessett wrote: There is a way to easily add tests, but it requires some community discipline. phpunit has a --skeleton command (actually two variations of it) that automatically generates unit tests. (see http://www.phpunit.de/manual/current/en/skeleton-generator.html). All developers have to do is add assertions (which have the appearance of comments) to their code and call phpunit with the --skeleton flag. If you want even more hand holding, Netbeans will do it for you. This is all wonderful, but there are problems: * Who is going to go back and create all of the assertions for existing code? Not me (at least not alone). This is too big a job for one person. In order for this to work, you need buy in from at least a reasonable number of developers. So far, the number of developers expressing an interest in code quality and testing is pretty small. This doesn't need to be done straight away, providing all new code is has proper unit tests built for it the old stuff will get done eventually or when it breaks. * What motivation is there for those creating new code to do the work to add assertions with good code coverage? So far I haven't seen anything in the MW code development process that would encourage a developer to do this. Without some carrots (and maybe a few sticks) this approach has failure written all over it. We don't do unit tests properly yet, that's probably why. If there is a decent infrastructure in place then it might be possible to encourage developers to do this. * Even if we get a bunch of Unit tests, how are they integrated into a useful whole? That requires some decisions on test infrastructure. This thread begins the discussion on that, but it really needs a lot more. We have started integrating parser tests in to code review, so something like this could be done for the unit tests so they won't stagnate, etc. * MW has a culture problem. Up to this point people just sling code into trunk and think they are done. As far as I can tell, very few feel they have any responsibility for ensuring their code won't break the product. [Perhaps I am being unkind on this. Without any testing tools available, it is quite possible that developers want to ensure the quality of their code, but don't have the means of doing so.] I completely agree, blatant syntax errors are regularly being checked in - and now there is a post-commit review process very few developers actually get someone else to look over their patches before commiting them which is far from ideal IMO. I realize these observations may make me unpopular. However, someone has to make them. If everyone just gets mad, it doesn't solve the problem. It just pushes it out to a time when it is even more serious. I don't think you have anything to worry about, you bring up some valid points that are more often that not, ignored. Dan Please can you properly break your lines in e-mail though, to 73(?) characters per a line - should be possible to specify this in your client. -- Robert Leverington http://rhl.me.uk/ signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A deployment branch for the rest of us
On 2009-07-30, Brian wrote: Can we please have a the WMF deployment branch be a branch of an untainted branch of the particular revision that is considered stable? This is, and always has been, the latest release (e.g. MediaWiki 1.15.1). If you want to run beyond-stable you cannot expect developers who already don't have enough time to spoon feed you information they don't have. The WMF deployment branch is already well beyond what end users should expect. -- Robert Leverington http://rhl.me.uk/ signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A deployment branch for the rest of us
On 2009-07-30, Brian wrote: The versioning interactions between mediawiki and its extensions are so complicated that it is simply not feasible to run the latest release while simultaneously using a variety of extensions. Please can you explain more; last time I tried, branched versions of extension generally worked with branched versions of MediaWiki? If this isn't the case then it should be fixed. Additionally, I strongly disagree with your definition of the code being used on Wikipedia as beyond stable. Code in trunk is under development, that is what defines trunk - it hasn't been tested to the same level as releases. Although I think this is case where everyone will have different opinions, I'm not sure of the current official stance. -- Robert Leverington http://rhl.me.uk/ signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A deployment branch for the rest of us
On 2009-07-30, Brian wrote: You seem confused, perhaps you should re-read the thread. I never asked anyone to do anything except make a branch. That *is* non-trivial. Someone will have to maintain that branch. Someone will have to make a judgement about when to update that branch. Generally these aren't things that a single person can answer, which is one reason why we have a multiple release canidate policy when declaring versions stable. -- Robert Leverington http://rhl.me.uk/ signature.asc Description: Digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal: switch to HTML 5
On Wed, Jul 08, 2009 at 10:58:43AM -0400, William Allen Simpson wrote: My thought is that the 5 tags that are marked as well-supported could be used, but be very cautious about abandoning 4. There are a lot of old machines out there, and many cannot upgrade to newer browsers, because they cannot upgrade their underlying operating systems. For example: schools, already heavy *pedia users. And political campaigns often use cast-off machines. Win98 or 2K means no upgrades. I don't think there is any suggestion that backwards compatibility should be broken. MediaWiki is a project which has strived to keep full compatibility with most browsers since its creation. Robert ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
