OK, now that I have some more time, I will expand on what I’ve already said in the Gerrit patch.
== Introduction == The WMF does not have that many developers. And it’s not that they haven’t hired enough or anything like that. It’s just they do not have that many people in general. As of last year, they had under 200 employees, total. I work at an enterprise software company, and we have 200 developers alone on the app/dev team, let alone the additional people (including myself) in the architecture group, in the business analyst team, in management, etc. To think that under 200 people can develop a 400,000+ line codebase is insane. That’s why the WMF gets help from the open source community. Not only because people love to work on open source projects that benefit the world and humanity, but because such projects *need* volunteers because they simply do not have the billion-dollar operating revenue necessary to develop an enterprise product. With that said, it is absolutely necessary that the WMF get as much help as it can. Right now it has a lot of help: numerous volunteer developers working on core, working on translatewiki, etc. However, it’s not easy convincing people to join an open source software project. I’m sure Quim and Sumana can attest to this. What we can do, however, is “export” the work. == Third-party libraries == === How they can help? === Third-party libraries, i.e., other open-source software projects, are helpful in that: 1) They have existing communities of interested volunteer (and sometimes even paid) developers. 2) They are structured in an abstract manner, meaning they can be used inside MediaWiki without having extensive knowledge of the library’s internals. 3) They help to remove possibly hundreds if not thousands of lines of code from MediaWiki core that does not need to be there. The premise is: why reinvent the wheel? Or, to be more specific, why reinvent the wheel by carving a square stone rock? There are libraries out there (such as SwiftMailer, which I’ll get to) that do certain tasks that MediaWiki needs to do. However, they are ten times as comprehensive as MediaWiki’s make-shift implementations, and are maintained a lot more. === The qualifications === Obviously, we cannot just start throwing in third-party libraries willy-nilly. There are major implications, specifically: * Possible security issues introduced by the library * Having to submit patches upstream when bugs are discovered These are real issues. However, if the third-party library we are thinking of including is: 1) popular, i.e., used by other projects, especially commercial and/or commercially-backed projects; 2) uses a sane and reliable code review process and release process; and 3) is stable and unlikely to change drastically, then the library is reliable, and we do not really have to worry about issues. One argument that people seem to be making is that since the code did not go through *our* review process, the code might be vulnerable or insecure. That is a fallacy. To say that code going through our own review process is more secure than others is ridiculous. Doing a security review of code requires security knowledge, and those with security knowledge (i.e., Chris) are not reviewing every line of code that goes into core. Long story short, we do need to evaluate what libraries we put in, but if they are reliable it will not be a problem. == SwiftMailer == Now we get to SwiftMailer. Some are calling it a new shiny toy, and like Daniel said, this is a bit insulting to anybody who has even looked at the UserMailer.php code. With SwiftMailer, the only mail code that will be in MediaWiki will be what is necessary to get the e-mail address of a user. Everything else is handled inside the library. We no longer have to maintain mail-sending code at all. Putting PEAR aside, considering the major annoyances in using PHP’s mail() function, including differences in handling between operating systems, it is a big success if we do not have to deal with the mail() function inside MediaWiki. -- Tyler Romeo 0xC86B42DF From: Tyler Romeo [email protected] Reply: Tyler Romeo [email protected] Date: June 11, 2014 at 7:21:46 To: Wikimedia developers [email protected] Subject: Re: [Wikitech-l] Making a plain MW core git clone not be installable On Wed, Jun 11, 2014 at 4:28 AM, Antoine Musso <[email protected]> wrote: - depends on upstream to incorporate our patches - might not be used as-is on Wikimedia cluster I would just like to point out that you can override where Composer finds packages using the composer.json file. In other words, if we wanted to force Composer to use WMF's git repositories to check out dependencies, that is entirely possible. In the end, Composer uses git to check out the packages anyway. https://getcomposer.org/doc/04-schema.md#repositories -- Tyler Romeo Stevens Institute of Technology, Class of 2016 Major in Computer Science
signature.asc
Description: Message signed with OpenPGP using AMPGpg
_______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
