Happy birthday to me.
What’s twenty-four?
Nifty.
Since I’m about to present the topic, I’m making the presentation slides available for all. There will indeed be video of the talk, which I will post as soon I can afterwards.
The slides are hosted directly on Google Docs: http://docs.google.com/Presentation?id=dffhxmhs_1273ct3kc8
Context: BarCamp Rochester — Anyone and everyone is invited to attend, and everyone is highly encouraged to present something of their own, no matter what it is. It’s happening this weekend at RIT, where I’m studying (and graduating in about a month!) for Software Engineering.
I’ll be attending it to give a presentation on MantisBT and the Source Integration framework. Specifically, I’ll be covering the myriad of new features that have made it into the project over the past week and a half. I plan to walk through setting up a project in Mantis, creating a new repository on GitHub, linking the Source Integration framework to that, and showing how the branch mapping and auto-resolving features work. Should be interesting.
After the presentation, I plan to post the slides, along with my presentation notes, up here. If anyone decides to video the talk, I’ll also make sure I can get a copy of that as well, but no promises.
Cheers!
Considering that my last post on Integrating Git and SVN has garnered a fair amount of attention, I thought that it would be useful to discuss my Source Integration framework in more detail. Specifically, I’ll be covering topics such as the design and implementation of the framework and, more importantly, how developers can go about implementing support for other version control tools.
The point of this is to show that it’s quite possible to integrate just about any type of version control tool with the Source Integration system; indeed I planned from the beginning to create a generalized framework that would support many different types and paradigms for version control. This should at least be evident in that I have already created extension plugins for Git and Subversion - it should be quite possible to extend the concepts further to Mercurial, Bazaar, CVS, or any other tool.
For the point of brevity, I’ll make the assumption that the developer at least has a fair understanding of PHP, their version control tool, and how events and plugins work in MantisBT. If you are not yet familiar with the plugin system, there is currently a basic introduction in the MantisBT Developer’s Guide, which I’ll hopefully be adding more information to in the near future.
This is how I like to answer these types of questions.
Thank you Explosm, you’ve just made my day! 
With the ongoing work towards a 1.2 release, the Mantis Bug Tracker features a brand new plugin and event system, which will allow users to implement entirely new features for MantisBT without ever needing to touch any of the core codebase. It’s a very extensible system, and allows plugin authors to implement only what they need, while still allowing advanced plugins as much flexibility as possible. Plugins can be as small as a single file with 20 lines of code, or as large as entire hierarchies of files, pages, with their own API’s.
As the core developer of the new plugin system, I have been working on a variety of plugins. In particular, I have created a vastly improved method of integrating source control repositories within MantisBT. The plugin package is named, aptly enough, Source Integration, and implements a generic framework that will allow integration with multiple repositories, each potentially using any source control systems available, simply by creating an extension plugin for each new tool. Currently, I have implemented integration packages for both Git and Subversion, my two source control tools of choice.
The Source Integration package tracks repository information based on a series of changesets, each of which may have a list of affected files. The data representation is generic enough to cover version control concepts used by all types of tools, from the ubiquitous CVS and Subversion, to modern distributed tools like Git and Hg. However, the system takes the stance of implementing as few details as possible, so it relies on existing repository-viewing tools for tasks such as viewing commit diffs, file contents, tree browsing, etc. Extension plugins handle translating tool-specific information, like history logs or checkin data, into the generalized data objects used by the framework. Extensions also generate URL’s for viewing files and diffs, but everything else is handled automatically by the core framework.
The true benefit of the Source Integration package lies in the amount of repository integration that it implements within MantisBT. When importing changesets from your repository, Source looks at the commit message of each changeset for references to bug numbers in your tracker, and sets up links in the database for any bugs mentioned. When viewing bugs mentioned in commit messages, a new section is displayed after the bugnotes called “Related Changesets”, giving a list of linked changes, including information about the changeset, such as the branch, author, timestamp, and a list of changed files.
Merry Christmas everyone, happy holidays, and a happy New Year. Cheers!
As a well-seasoned PHP developer for MantisBT and other projects, but at the same time a seasoned developer in Python, C++, Lua, etc, I found this interesting article on Hacker News, Yet, a short piece on the “history” and development of PHP as a language.
A few choice quotes that I most enjoyed:
I don’t know anyone who programs in PHP and hasn’t … become much more acquainted with the concept of “haystack” and “needle” than any one person should have to in a lifetime.
With time, an experienced developer learns that the only reason why any particular functionality is not in PHP is that it’s not there—yet.
Invariably, PHP developers who try to settle into a framework have the (often irresistible) urge to simply drop it and write their own, because, you see, there is no framework that does things the way he or she wants—yet.
I really like working on the PHP projects that I’m a part of, but every time I write a Python script to do something, it just reminds me of how unsophisticated PHP really is as a language. Perhaps that’s OK; it certainly hasn’t stopped me… yet.
John Gruber recently talked about how he deals with email on the iPhone, where Apple’s Mail tool lacks the ability to do something even as simple as flag a message in the inbox. He has go through a convoluted process of moving email to a specially-named folder, and then running a bit of AppleScript on his desktop that will take all the mail from the special folder, flag them, and move them back to the desktop. Good grief.
Why again does John need to go through this long, redirection process? Why not just use a different email client on the iPhone? Because Apple is anti-competitive, and third party apps can’t run in the background, straight from John Gruber himself.
Isn’t this a bit absurd? Why do people let Apple stifle competition like this? Am I the only one that thinks this situation is far worse than anything presented in the huge anti-trust cases against Microsoft in the past decade? Apple is specifically denying competition on the iPhone, and all the groupies think that it’s perfectly acceptable, even good for the consumer! But shame on Microsoft for bundling Internet Exploder and a Media Player; how dare they allow anyone to choose a different browser even!
People ask me why I purchased my Neo Freerunner instead of an iPhone. Even disregarding that I’d lose my choice of carrier, I don’t see why people are rushing to a company that depends on anti-competitive practices to maintain the ‘best’ apps on the phone. If Apple’s browser, mail reader, etc, don’t suit the customers’ needs (as is apparent from Gruber’s post), why are they trying to stop them choosing a better option? It’s not like Apple’s revenues depend on users choosing Safari or Mail.app; hell, wouldn’t they get even more revenues from the App Store if people could buy a superior browser for even $1 a pop?
Sounds to me like Apple cares more about maintaining control than providing their users with the best experience….
How about rather than asking web designers, server owners and IT staff everywhere to add some hack tag to their code, you force IE8 into compatibility mode unless a designer specifically enables IE8 rendering on their page by adding said tag? That mediates the issue pretty easily.
They [Microsoft] were originally planning to require a special tag to enable standards compliance in IE8, but there was a gigantic backlash from the web development and standards community.
Why? Because then we get nowhere; all the clueless web designers never find out about the special tag to make IE8 comply with internet standards, and continue making web pages for the broken IE rendering model for the next 10 years.
We need to make all those old websites break, because otherwise they’ll never comply with modern standards. We need to have standards based rendering be the default because then the designers that test against IE8 will be making sites that work better with other browsers.
By forcing developers to realize that their websites are non-compliant (either from angry users or specifically forcing quirks mode) and by defaulting to standards-based rendering, we make the web design future a much nicer place to be.
