For the past month, I’ve been piloting Gnome 3 and Fedora 15.
I’m pretty happy with the state of things now. I have to admit that in the beginning, I was cursing loudly asking for my desktop and panel back, but I’m used to the dash area and window picker now. The search feature (which is similar to Spotlight in OSX) is really useful and I end up using that for the majority of my tasks. I also find the notification system very well done along with the ability of dealing with messages without changing windows. In the end, all I can say is I find myself using Fedora more over my pretty MacBook Air for the majority of my tasks. I’m almost as productive as I was with Gentoo and Rat Poision back in the day 🙂
On a side note, when will “desktop Linux” realize that no one wants to write applications in Gtk, Qt or Python. And by no one, I mean there’s just a small slice of developers capable of writing applications in those languages (I don’t care how many Python snippets you provide). The first one to allow applications be developed in a more popular and saner language, preferably a combination of HTML/JS/CSS will do wonders to their respective communities. I think the direction Gnome is going with Seed but they need to still make things easier for folks.
Anyways, if you want to learn more about the Gnome 3 changes, check out this wiki page. The final release of Fedora 15 should be out in a couple of weeks, but if you can’t wait, grab the pre-release which has been working great for me.
The Jenkins community had a meeting yesterday, here are the minutes. As part of the meeting, there was discussion to see if there could be any reconciliation with the Hudson proposal at eclipse.org, they started a wiki page with their requirements.
I was mostly at the meeting to dismiss any false knowledge with how we operate at the Eclipse Foundation. There seems to be a lot of confusion that Eclipse is controlled by IBM and whatever evil companies you want to name, but that’s so almost a decade ago when Eclipse wasn’t a Foundation but a Consortium. If you take a peak at this year’s commit information so far, you see that individuals make up the most commits at eclipse.org so far (with IBM as a close second). Eclipse.org is a very professionally run open source organization that understands the line between commercial and open source offerings well, you won’t find many freetards here. You’ll find people who care deeply about developing quality open source software for companies and individuals alike. Just take a look at the eclipse.org membership rolls and you’ll see the amount of diversity. There’s an established development process called the Eclipse Development Process which gets refined every year or so and helps guide projects in the right direction to releasing quality software. In the end, each eclipse.org project is individually run by the committers and project leadership.
I have a selfish reason to have a great CI system at eclipse.org… we already are fanatical users of an older Hudson version for a lot of our eclipse.org projects (http://hudson.eclipse.org/) and having a project within the eclipse.org walls would allow for some nice dogfooding. On top of that, we have a great set of Mylyn Builds tools (see Mik Kersten’s blog entry) that allow developers to interact with their Hudson/Jenkins instances from within the Eclipse IDE. On top of that, the Eclipse community also has a lot of advice to share when creating a plug-in based ecosystem, from technology (e.g., OSGi) decisions to infrastructure to licensing.
In the end, it’s pretty comical that the Java ecosystem is large enough to damage itself like this. A prolonging fork of Hudson/Jenkins is a not an ideal solution for the future and having the projects reunited would be better in my humble opinion. Regardless of the decision, I hope people from both sides can put the politics and hard feelings aside and do what is right for your adopters, because at the end, you need to keep them happy, whether they are individuals or companies.
As part of our upcoming 1.0 release, JGit will feature some Git Ant tasks. This is great news if you want Ant tasks that are portable and don’t rely shelling out to call the Git command line interface. If you want to take a peak at the, check out the org.eclipse.jgit.ant module.
A special thank you to Ketan Padegaonkar from ThoughtWorks for the initial contribution. If you want more Ant tasks available, please feel free to contribute by looking at our contributor guide.
The EGit and JGit teams are proud to announce the 0.12 release!
If you’re interested in what’s new, please checkout the respective new and noteworthy documents…
This is the last release before we wrap up development in early June and declare 1.0 in time for the Eclipse Indigo release. There’s a lot of stuff in the pipeline that didn’t make the 0.12 release so if you want to get anything in for the 1.0 release, please consider contributing by following our contributor guide. As always, if you have any questions in using the tools, please checkout the thorough EGit User Guide. Also, if you want the JGit maven repository, you can find more information here.
Enjoy!
Do you recall the recent now mirrored at GitHub? Well, I have good news, within the EGit project at eclipse.org, we have started creating some tooling to integrate GitHub. At the moment, we only support working with GitHub Issues and Gists…
In the future, we’re looking at integrating with other parts of the GitHub API, but for now we are targetting solid Gist and Issues support from within Eclipse for the Indigo release in June 2011. I can only imagine how cool it would be to work with GitHub pull requests from within Eclipse, but good things come to those who wait (or contribute). To test out the tooling, please add this repository to Eclipse:
http://download.eclipse.org/egit/github/updates-nightly
It’s important to note that the tooling should be considered alpha-level and we’re really seeking people to test and contribute to the project. You will run into issues using the tooling and you should keep that in mind. You can find more information on the contributor guide or take a peak at the code at its GitHub mirror. If you find any bugs or have enhancement ideas, please file them here.
I would like to thank Kevin Sawicki from GitHub and Christian Trutz who pushed me a bit to get the initial tooling contribution in place at eclipse.org so people can contribute. In open source, sometimes it takes having a frosty beverage with someone to move things along…
If you ever have any issues with the p2 dropins directory (which you shouldn’t be using in the first place), there are some handy tracing options you can use…
org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true
Just create a .options file at the root of the Eclipse installation directory and pass -debug when you start Eclipse. You should see some debug output from p2 in the log…
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] Repository created file:/usr/share/eclipse/dropins/pydev/
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] com.python.pydev.codecompletion 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.parser 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.feature.feature.jar 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.help 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.debug 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] com.python.pydev.fastparser 1.6.1.2010080312
[p2] Mon Apr 04 08:36:19 CDT 2011 - [Start Level Event Dispatcher] [reconciler] [dropins] org.python.pydev.feature.feature.group 1.6.1.2010080312
Happy debugging!
Last weekend, I had the opportunity to introduce Git and Gerrit to folks at the Texas LinuxFest 2011.
From a quick poll in the members in the audience, there were about 60% of folks using Git, while only a few have used Gerrit before. From conversations I had with folks after the talk, there seems to be a lot of interesting in migrating to Git from their existing systems (which ranged from Perforce to SVN). Anyways, it was fun and I enjoyed the experience of being able to walk to a conference venue from my home office.
I’m happy to announce we finally setup mirroring of eclipse.org repositories on GitHub.
I think this is an important step to making the eclipse.org codebase more accessible for people to fork and contribute changes. If you’re an eclipse.org project accepting changes from someone on GitHub, please check the official policy on handling Git contributions. If you’re an eclipse.org project and you don’t see yourself on the mirrored repository list at GitHub, you have to:
If you need more information, please check out the wiki for more information about GitHub. I also want to thank Wayne Beaton for his portal metadata wrangling and Ketan Padegaonkar for helping out with this effort.
Enjoy!
