>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.