>Eclipse Development Process: Addressing Bugs

>The Eclipse Development Process has a “Development Process” section, but this is misleading in many ways. When a developer thinks of a development process, they typically think about what technical practices that they need to address. The “Development Process” described in Section 6 of the EDP is all about the various phases that a project has to go through before a “release”. So a suggestion would be to retitle section 6 as “Project Release Management”.

The EDP does not specify in any way how a project itself is to implement it’s technical practices and project management (i.e the Development Process). It leaves this to the individual projects to discover and determine on their own. The method that was originally created by the “Eclipse Project” and it’s sub-projects of Platform, Platform UI, JDT, and PDE has been used as a model for many eclipse projects. However when looking at bug triaging and addressing the bugs there is a possible problem in the overall process.

As shown, the EPDP (Eclipse Project Development Process), devotes one Milestone to bug fixes. The very last milestone before the release candidates. The release candidates are supposed to be stable releases…bugs fixed in a release candidate should be only those that would stop shipment of the product. There are a couple of problems I have seen with this process, especially as the project becomes more popular:

  • Bug backlog goes unaddressed and soon overwhelms the committers working on the project.
  • Features are given higher precedence and importance than fixing bugs in the backlog (there are 6 milestones that are feature driven milestones).
  • Technical Debt grows…making it harder to had more features.
  • Contributions greater than 250 lines of code can’t be triaged in time due to IP cut off date of January 31st (M7 typically starts in March).
  • Bugs are assigned to an owner, giving the appearance that it will actually be addressed.

The Eclipse Platform UI team is starting to address the later process, by not assigning it to a person, but to a bug-triage in box. The other items though are more fundamental to the technical and management process outlined by the EPDP.

Not addressing bugs as they are received and giving them higher priorities than adding new features, causes the backlog to grow. It can also make it much more difficult to add new features later. Contributions from contributors need to be given a higher priority than they currently appear to be in the process. If you wait to only work on bugs with patches until M7, then you are running into some potential issues:

  • Bugs with patches greater than 250 lines of code have to go through the eclipse IP process. This can take a while depending on the number of other items the IP team is reviewing. Addressing these items earlier allows the potential of getting the contributors change in sooner rather than later.
  • Part of recruiting new contributors/committers to a project is responding to those contributions in a timely fashion. It shows that you are truelly interested in their help. It encourages them to keep contributing to the project. Many times contributions for bug fixes go years before being addressed, in those cases the contributor probably has moved on to other items.
  • Bugs not addressed just are a problem waiting to happen. If the bug backlog starts getting too big, then the committers may feel that it will take too much time to address the issues. Keeping the backlog manageable helps to make sure that the bugs are addressed quicker and sooner.

Regardless of the technical and management processes you choose for your project, it’s important to give the bugs the priority they deserve. Adding features without addressing the backlog is asking for more trouble and manageability issues down the line. The Platform UI team has started on a good rework of their triaging efforts, however, I think the overall focus needs to change to address the technical debt that has incurred from all the features that have been added over the years.

Next in the series: Using Scrum and XP with the Eclipse Development Process.

This entry was posted in agile, eclipse. Bookmark the permalink.

2 Responses to >Eclipse Development Process: Addressing Bugs

  1. Eric Rizzo says:

    >I could not agree more. As I think you pointed out in a previous post, the EMF project is a good role-model in this area; they make a visible and conscious effort to keep the bug backlog tiny.This reminds me of how I keep my email inbox (in contrast to how I see most people keep their inbox); I make conscious efforts to keep my inbox at around 20 messages or less, and with nothing older than a week or two. Everything else was either deleted, replied/forwarded, or filed into a folder within a few minutes of arrival. By following this strategy nearly religiously, my (many) inboxes are always manageable; I always “know,” at a glance, what is in there. Hence, email is still a very effective tool for me.Contrast that with how most people treat their email…I’d bet money that 90% of people can’t review their inbox in under 30 seconds, and that a majority have so much and such old stuff that their inbox is essentially useless beyond the most recent 5 or so messages. I think that is why you hear so much “email is dead” talk these days (IMO it is not, as many believe, just because of rampant spam); they simply have let the “debt” get so large that they can’t manage it any more.I see a big similarity between the typical email user’s inbox and the typical Eclipse project’s bug “inbox” and I agree, Dave, that this is possibly the single biggest problem facing Eclipse projects. The worst part is, I suspect many of the committers don’t even realize it is their biggest problem.

  2. David Carver says:

    >@Eric: The problem we run into is the commercial nature of eclipse projects. Unless the commercial interests that provide most of the committers make a concious effort to have the bug fixed before adding new features, then nothing is really going to change.They complain about not having enough resources but are slow to respond to contributors that have take time to submit patches for bugs. Not responding is a sure way not to get new committers. Time is the thing I hear the most as for why it isn’t done, if it’s important enough people find the time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s