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

Great to hear this initiative. Although I'm not part of the linux-tools, I'd like to offer some help and (free advice)

Some tools that may help:
- MoreUnit[1] (Jump between tests, and code)
- hamcrest allows writing DSL'ish tests (available in orbit)
- mocking frameworks, to mock out interfaces and test if listeners are invoked among other things (I recommend mockito[4])
- cobertura/eclemma for coverage reports [3]

I can help with cobertura integration since I've done this for swtbot and also use it extensively at work.

Ensuring that builds are reproducible, developers should be able to do a checkout and build in less 3 steps[2] (or less):
$ svn co http://whatever
$ vi some.developer.specific.properties.file
$ ant

This helps contributors and committers to run the build via ant every time before checking in.

My 2 cents.

-- Ketan

[1] - http://moreunit.sf.net
[2] - http://github.com/ketan/swtbot/blob/master/org.eclipse.swtbot.releng/readme.txt
[3] - http://download.eclipse.org/technology/swtbot/dev-build/coverage/org.eclipse.swtbot.swt.finder.test/
[4] - http://mockito.googlecode.com

On 25/2/09 03:14, Andrew Overholt wrote:

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.


linux-distros-dev mailing list