Just to let everyone know, some members of the eclipse.org community recently voted on naming the next simultaneous release after Juno gets released in June 2012. Taking input from the community, the Eclipse Planning Council finalized the name to be Kepler.
Personally, I think it’s a great choice and a nod to Johannes Kepler.
It’s that time of year, please help choose a name for the next eclipse.org simultaneous release!
There are some interesting options this year, it’s even hard for me to vote:
So, please go vote by January 15th, let’s get a name in time for EclipseCon 2012.
The EGit and JGit teams are happy to announce the 1.2 release, just in time for the holidays!
The precise release version is 1.2.0.201112221803-r
It can be downloaded from the Eclipse Marketplace or the p2 repository.
There’s a lot of new improvements, including better performance and stability. If you’re interested in the details of what’s new, check out the JGit New and Noteworthy and the EGit New and Noteworthy.
We hope you find the release useful and please enjoy the holidays!
The Eclipse Planning Council is going to try to name the Juno+1 release a bit earlier than usual.
If you have suggestions, please make them on this bug. Of course, preference will be given to names that start with “K” (e.g., Kepler). Furthermore, preference will be given to names that fit the traditional Eclipse themes (moons, heavenly bodies, gods, scientists).
Enjoy coming up with names! The voting should start in early January.
Last week, I read an article entitled, “The personal computer is dead” by Jonathan Zitttrain.
The basic premise of the article is that there’s an unprecedented shift of power from end users and software developers to operating system vendors on the other. If you’re a software developer, this shouldn’t be a surprise since if you have been developing mobile applications, you should have noticed the walled gardens popping up around you. To distribute applications, you have to go through a vendor like Apple and use their App Store… each individual application has to be vetted and meet a set of standards that isn’t fully transparent. Your application gets a distribution channel and Apple gets to take a cut of your profits. This model was extremely successful for Apple and has now “boomeranged back to the PC.”
There’s now an App Store for the Mac to match that of the iPhone and it carries the same restrictions essentially. I’m almost 100% sure that Microsoft will replicate this model in their next operating system. As the article states, “today’s developers are writing code with the notion not just of consumer acceptance, but also vendor acceptance.”
I theorize that these typed of wall gardens will slowly start taking advantage of what is going on in the development tooling space. With the advent and eventual maturity of online development tools (see Ace or Eclipse Orion), I envision companies forcing you to write software with tools hosted on their server and then finding a way to “tax” you for the usage. Imagine Google Chrome becoming the worlds most popular browser. Google starts integrating “apps” more prominently in their browser and the way the apps are written are fully online using their web-based tool-chain. To get an app in the browser, you have to go through some control point Google sets up.
Imagine writing software for say the blackfin processor, fully hosted on their infrastructure since that’s the way Analog Devices likes it. The company gets a new control point and potentially another revenue stream. In the end, the tools may even be more convenient for developers but what path are we heading down…?
I’m not sure if the trend is good or bad yet, but there’s definitely a shift of power from end users and software developers to vendors. I feel there’s a definitive trend in the software industry to build walled gardens. Will we start losing the power to tinker and use our own tools to do development? Will I start having nightmares that involve RMS screaming at me (while wearing some crazy costume) about free software and saying he was correct all along?
To end my diatribe, here’s a final quote from the article to mull over, “… if we allow ourselves to be lulled into satisfaction with walled gardens, we’ll miss out on innovations to which the gardeners object, and we’ll set ourselves up for censorship of code and content that was previously impossible. We need some angry nerds.”
Maybe I should have had more coffee this morning, thoughts?
Yesterday, I had the opportunity to present at the EclipseDay at the Googleplex event which hosted around 100 eclipse enthusiasts. Shawn Pearce and I gave an update on the work going on in the EGit and JGit projects as we prepare for the 1.2 release later this month.
I’m very proud of the progress the two projects have made since we fought to have the projects move to eclipse.org and build a community there. It’s amazing to see JGit being used on Android via Agit and even have some crazy folks automagically port JGit to C# (NGit) to enable Git usage on the .NET platform. Shawn even talked about how JGit is being used within the walls of Google to power the android.googlesource.com git repositories by stuffing git objects into BigTable. Heck, there are some instances that JGit is even faster than native cgit.
In the end, it was nice to catch up with some old friends and even make some new ones this time around. A special thank you to the Google Open Source Program Office for hosting the event and providing some delicious birthday cake to commemorate ten years of the eclipse project.
There was a question on the linuxtools-dev mailing list recently about how to follow the commits of the project. While you can certainly create a git commit hook to email a mailing list after each commit, you can also easily follow eclipse.org projects on Github if you’re interested in them.
If you don’t want to watch the project and just focus on the commits, you can do that via RSS…
On top of that, you can even follow your favorite eclipse.org committer! Getting mirrored on Github is one of the benefits of moving to Git at eclipse.org, so please try to do it soon as the eclipse.org SCM countdown is on its way… only 395 days until CVS/SVN will no longer be an option!
As a reminder, the deadline for EclipseCon 2012, North America edition is tomorrow.
So please submit your proposals, the Program Committee is going to select a program in the next couple weeks. It was difficult enough choosing the early-bird picks:
It was nice to attend EclipseCon Europe 2011 this year and give a packed git tutorial with some colleagues. Here are the slides and tutorial notes in case you missed it.
We covered information from basic git usage within Eclipse to all the exciting integration with Gerrit, Mylyn and Github. It seems like it went well since Ed Merks mentioned that he learned some new things (he’s lately been shaving a lot of yaks when using git).
As a reminder, the Eclipse Foundation is moving to git and it would be great if existing projects migrated earlier than later. At the moment, a little over a third of the projects have fully migrated to Git.
If you need help migrating, please subscribe to git@eclipse.org to ask for help and check the git migration information on the wiki.
The JGit and EGit project teams are proud to announce our 1.1 release in time for Indigo SR1!
To see what’s new, check out the respective JGit new and noteworthy and EGit new and noteworthy documents. In terms of new features, some of my favorites are the new reflog view which I had a hand in putting together.
If you ever wanted to know where a commit went, git-reflog can save you. In terms of other features, I’m really happy with the improvements to the synchronize view which just screams now in terms of performance (thank you Dariusz Luksza). I’m confident now that we should handle the majority of repositories with reasonable performance when trying to compare refs.
The other highlight of the release is the improvements to the GitHub Mylyn Connector.
GitHub Pull Requests can now be added as a Mylyn Task Repository type and you can now open pull requests with an editor (supports opening commits in the commit viewer). This is fantastic productivity boost (thanks Kevin Sawiciki) if you had to work with github pull requests via the command line before. On top of that, there’s a full implementation of the GitHub v3 API available via the EGit project.
Enjoy the release and thanks for your patience while we improve the Git support within Eclipse!
Recent Comments