[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [linux-distros-dev] 0.2 + agile development
Andrew Overholt wrote: 
Hi,

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
release.
I would like to start the process next Monday.
Having a release before EclipseCon would allow us to gain even more publicity. 
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
Another tool that can help a lot is moreUnit.
I think we should start with lower aim than 80% and increasing the level for every release with 5 or 10%.
Just FYI specfile editor had around 45% coverage but after I started looking at tests so much unneeded code was removed that the coverage is now below 40. So it really worth it.
Rpmstubby has no unit tests at all.
I would propose putting some coverage level as a guideline to every release. Of course this is not going to hold any release but it will allow us to at least have some plan.
I'm not going to propose any such level before others said the state of the other tools. I know this is depending on the specific tool/plugin but if we are producing a common release we should have common goals.

- 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
+1
- this one is also obvious, but new features and new bug fixes should
have unit tests
I think we should at least try :)
-- 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
I don't have hopes for doing test-driven development for now. This puts too much burden on the planning page which is not exactly the way we(at least me) work, we fix/add features when needed.

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

Andrew

_______________________________________________
linux-distros-dev mailing list
linux-distros-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linux-distros-dev