[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[linux-distros-dev] 0.2 + agile development


What do people think about an 0.2 release?  If we want to do it before
EclipseCon (23 - 26 March), we need to get started on the process very
soon.  In fact, I'm not even sure we _can_ have something out before
EclipseCon, but we can at least have a release candidate -- which
doesn't have to go through a release review since it isn't an official

I told Kent I'd help plan an agile sprint for Linux Tools.  I have
obviously failed to do this.  I'll see if I can find some time to
organize something later this week or early next week.  We could have a
decent few weeks before EclipseCon where I'm giving a short talk on the
status of the project.

Earlier today I was speaking with Dave Carver of -- among other things
-- XSL Tools (part of WTP) fame about agile methods.  He gave the
following suggestions for us to be a bit more agile:

- continue with the automated builds on SVN change
-- I'm working with Nick Boldt on getting the Common Build
Infrastructure going so we are/will take advantage of this and the
builds in Hudson)

- aim for at least 80% test coverage
-- this is an area that's a bit weak for us
-- hopefully the exposure of code coverage reports as part of the common
builder and in Hudson will help
-- if you're not already using it, EclEmma is a great tool

- take off auto-milestone in bugzilla
-- we should only set one when we're committed to fixing it in a
particular sprint/milestone

- take off auto-assign-to-a-person in bugzilla
-- Dave suggests having things only be in ASSIGNED state and have a
milestone when someone's actually committed to fixing it for that

- this one is obvious, but a build failure in our continuous builder
(will be build.eclipse.org) should take priority over bug fixes and
feature work

- this one is also obvious, but new features and new bug fixes should
have unit tests
-- in an ideal world we'd do test-driven development (TDD) which would
help us have cleaner code, less code, and tighter APIs
-- if we're not doing TDD, we should at least aim to write tests
immediately after bug fixes or feature work

Does anyone have any thoughts here?  I'd love to work together to hone
our development processes and document them on the wiki.