Candidate bugs for the EclipseCon Europe 2015 Hackathon

Alternate title: What I saw at the EclipseCon Europe Hackathon made my jaw drop!

I’m pretty excited about the hackathon we’re running at EclipseCon Europe.

Hacker's Keyboard

In past hackathons, we’ve let attendees pick the bug that they want to work on. We’re going to encourage this sort of thing this time around, but want also to provide some help for those potential contributors who want to help, but don’t already have an idea.

We need some candidate bug reports.

It occurred to me that we have many open bugs reports annotated with helpwanted, indicating that committers feel that the issue addressed by the report is valid, but that they have no plans to resolve it. Some of these reports, however, are relatively large problems that could day hours, days, and weeks to resolve.

We also have many bug reports annotated with bugday. This keyword was originally used to flag reports that were candidates for a Bug Day event, but has grown to represent issues that committers feel can be addressed by a new contributor with modest effort (e.g. one or two hours).

The bugday bugs seem like a reasonable subset of candidates for the hackathon. As of this moment, there are 54 open bug reports annotated with bugday. That number drops to 40 if you include helpwanted in the search (i.e. there are 40 helpwanted bugday bugs). Both of these numbers are a little large, but are a pretty good starting point. I’m thinking that a list of 20 would be ideal.

I’m hopeful that committers will step up and annotate more bugs. Should an embarrassment of riches result, we’ll have to sort out a reasonable means of whittling this list down to a manageable size (e.g. an age limit).

I’m curious to hear if anybody has thoughts on how we select good candidates.

The EclipseCon Europe 2015 Hackathon runs from noon on Tuesday, November 3rd until the end of the day on Wednesday, November 4th. We’re setting up office hours where you can meet and work with Eclipse committers (more on this later).

Posted in EclipseCon, Hackathon | Leave a comment

Introducing the EclipseCon Europe 2015 Hackathon

Alternate title: I Went to EclipseCon Europe and What I Saw There Blew My Mind…

EclipseCon has great tutorials and sessions. The speakers are second-to-none, and the networking opportunities are fantastic. if you’re looking for it, you’ll find software developers doing amazing things together. For EclipseCon Europe 2015, we’re going to formalize this a bit. At very least, we’re going to give it a nice home and a lot of love.

10553673244_84713e4157_z We’re extending our usual notion of a hackathon: instead of just having a single evening session, we’re going to host a hacking area for two full days during the conference. We’ll have a few things happening in this hacking area.

There will be multiple tables arranged in perfect order for pair programming. The tables will have wired connections so that participants don’t have to wrestle with the wifi. We’re going to set up a server with mirrors of our Git and Mars p2 repositories so you don’t have to make the long trip back to our servers in Ottawa to get started (once you’ve cloned, you can connect to the master repository to get updates and push patches).

We’ll have Eclipse Foundation staff and others there to help. We can help with things like creating Eclipse Foundation accounts, setting up Contributor License Agreements (CLA), configuring development environments, understanding the development and intellectual property (IP) processes, and more. We can even help you find a problem to solve and a partner to solve it with (if you need that sort of help). We’ll have a little presentation area set up where we’ll run short how to contribute sessions throughout the day.

You are most certainly welcome to work on your own problem. Or, you can select from our short list of issues that we feel can be solved with up to two hours of effort: pick something from the list and we’ll help you get started and sort through the development process. If you’re not quite ready to submit patches, you can help us test by downloading one of the packages, the installer, or a feature; we’ll help you create bug reports for issues that you find. Or we can help you just create a bug report for some aspect of Eclipse that’s been driving you batty.

We’re going to set up some office hours: specific times set aside when we’ll have subject matter experts on hand to help with specific sorts of problems. Use the office hours to connect with experts on topics such as building Oomph configurations, testing your plug-ins, or using the Common Build Infrastructure; and committers from specific Eclipse projects.

Eclipse committers are, of course, welcome to use the hacking area to collaborate with fellow committers that you don’t normally get to work with directly.

I think that you’ll find that we have a little something for everybody.

EclipseCon Europe 2015

Posted in EclipseCon, EDP, Hackathon | Leave a comment

Technology Behind the new Eclipse Project Handbook

I’ve been asked about the technology used in the new Eclipse Project Handbook.

Editing the Eclipse Project Handbook

The content itself is specified in Asciidoc format and rendered into HTML using Asciidoctor. I started off using Asciidoc for rendering, but changed after I ran into a couple of bugs and problematic licensing.

The content is represented as a collection of documents that are combined via master documents for each of the separate forges; I decided to do this to make the content more manageable and easier for contribution, and make it more easy to mix and match content. Forge-specific parameters are specified in the master document.

Many of the images are specified using Graphviz and rendered as hierarchical images using dot. For this style of graphic, the very simple text format permitted by Graphviz means that I have very good version control for these images. I also really hate pushing pixels around.

To render the documents as PDF, I’m using Asciidoctor to render the content in Docbook format and Apache FOP to take it the rest of the way. I think that my challenges with the graphics in the rendered PDFs are a issue with FOP, but haven’t quite concluded my investigation. As I mentioned yesterday,  I consider the PDF versions a nice-to-have, so I haven’t made sorting this out a very high priority.

I’m pulling all the pieces together using a make build. Given the nature of the project, this was, frankly, the easiest solution. It works well and is easy to maintain (there are, however, a few hard-coded file paths that I’m not at happy about).

The sources are all in the /projects Git repository if you’d like to take a closer look. I’m thinking that I will move these to a separate repository to make it easier for folks who want to contribute patches (so that you don’t need to clone all the other junk stuff in that repository).

Naturally, I’m using Eclipse to edit content and invoke the makefile as an external tool. Adding Mylyn Docs Wikitext support for Asciidoc to my Eclipse configuration is on my to-do list this month.

I’m pulling all of the tools from the Fedora software repository.

Posted in Other | 3 Comments

New Eclipse Project Handbook

For a very long time, I’ve wanted to completely rewrite our documentation for projects and committers. I finally gave it a big push last quarter and have completed a first big revision. There’s still more work to do, but I believe that the new document is very close to being the more-or-less complete “how to run an Eclipse project” document that we’ve needed for a while.

https://www.eclipse.org/projects/handbook/

I decided to compose the document using Asciidoc. I honestly can’t remember specifically why I selected Asciidoc over, say, Markdown, but using this format affords me some options that just aren’t available in the wiki or in traditional HTML.

For one, Asciidoc lets me do variable substitution and conditional inclusion. I’ve used these abilities to use one set of source materials to generate three different forms for the content: one for each of Eclipse, PolarSys, and LocationTech (note that I’ll likely move the PolarSys and LocationTech versions closer to their respective forges). Further, technology exists that makes it easy to turn each of these forms into PDFs (though, I’m still wrestling with some challenges regarding the images being rendered too large in PDFs). PDF support is more of a nice-to-have thing for those among us who really love printed documentation.

I’ll be spending time this quarter identifying and redirecting our existing content to the new document. My intent is to have this new documentation completely take over the old by the end of September.

If you notice problems with the content of the handbook, please open a bug against Community > Process prefixed with [handbook].

Posted in Eclipse 101, EDP, Education, Project Management | Tagged , , | 11 Comments

Eclipse Screenshot of the Week: Gerrit

It’s easy to get caught thinking that Mylyn only provides access to traditional issue trackers like Bugzilla and Jira. It also features integration with Gerrit.

This screenshot shows the Planning perspective being used to work directly with Gerrit reviews.

Working with Gerrit in the Planning Perspective

Working with Gerrit in the Planning Perspective

You can manipulate the review directly from within Eclipse, browse changes, fetch a patch set (and clone the source repository if necessary), cherry pick, abandon, and more.

Naturally, it also includes the standard sort of great Mylyn support like the ability to schedule when you’re going to do the work and the task focused UI.

Posted in ALM, Mars, Screenshots | Tagged , | Leave a comment

It’s Time to Revise the Eclipse Development Process: 2015 Edition

20150630_112837

Every couple of years, I work with the Eclipse Architecture Council to revise the Eclipse Development Process (EDP). The EDP is the document that describes the structure of projects, relationships between projects and committers, and the sorts of activities that projects are expected to engage in.

After many years and many revisions, it’s past time for a complete (or near complete) rewrite. That’s an exhausting thought, frankly, but it’s my hope that we’ll be able to do just that.

I’ve started gathering ideas for how the EDP can change on Bug 463857; this is an umbrella bug to collect the issues that need to be addressed. I’ve already added a few blocker bugs for some issues that I feel need to be addressed. Feel free to add your comments and other blockers as you see fit. Please do join in the discussion.

The first thing on my list is release reviews. Originally, a release review was an event: a conference call on which the project was required to defend their release to the community (or at least that subset of the community that joined the call). In those days, review materials needed to be prepared and disseminated a week in advance of the call to allow the community to prepare. But as community participation dropped, so to was the conference call and we turned the week of review material availability into the review itself.

I’m not at all convinced that there’s much value in the formal week of waiting to release. The community rarely–if ever–comments on release review documentation and since we set reviews up to succeed, they never fail. Further, I’m of the mind that anybody who is interested in an open source project is either already following the progress of the project or should be. If you’re waiting for the release review to be notified that something new is coming from your favourite open source project, it may be time to consider getting more directly involved with project discussion.

For releases, I’m thinking:

  • Get IP Team approval of the IP Log;
  • Get Project Management Committee (PMC) Approval of the release; and
  • Ship it.

Documentation requirements are the PMC’s call. Personally, I think that it’s totally reasonable to require that projects produce at least a single paragraph that describes the nature of the release in broad terms. And planning needs to happen in some form: either as a formal plan or more informally via target milestones on Bugzilla records.

Add your thoughts on Bug 415620.

Posted in Community, EDP, Project Management | Leave a comment

Eclipse Mars New and Noteworthy: Java 9 Beta

Java™ 9 support has not yet landed in our standard download packages. But you can add an early access preview to your existing Eclipse Mars install.

The Eclipse Java™ 9 Support (BETA) contains the following:

  • ability to add JRE and JDK 9 as installed JRE;
  • support for JavaSE-1.9 execution environment; and
  • ability to create Java and Plug-in projects that use a JRE or JDK 9.

At the moment Eclipse must be run with Java™ 9 if you want to use Java™ 9 in your workspace. You can download from http://www.oracle.com/technetwork/articles/java/ea-jsp-142245.html.

This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP.

Install the Java 9 Beta via the Eclipse Marketplace:

Drag to your running Eclipse workspace to install Eclipse Java™ 9 Support (BETA) for Mars

Posted in Java, New and Noteworthy | Leave a comment