While we can speak with some authority on technical and community
issues specific to Eclipse, it feels a bit presumtuous to be
dispensing general software development advice. I'm sure these
different methodologies are a great way for consultants to sell their
services, but I don't think anyone can claim to have found the one
true way to write software. I think the best anyone can say is, "here
is what worked for my team", but for a different team a different
process may be more appropriate. Just my $0.02...

John I agree, but from my understanding is that Eclipse originally was
founded on Agile techniques...you can see this in the current
Development Process, as it specifies Agile ideas, of milestones,
continuous builds. It's not the typical waterfall pattern of gather
requirements....analysis...build....etc over a one year period, this is
supposed to happen every milestone build.

I do think though that with the number of eclipse projects we can come
up with some common recommended best practices, and in particular, that
you shouldn't declare a milestone unless all your tests are passing.
The tests are a key way many adopters can know that the code they are
getting is good and stable, and that there aren't any regressions.

As I said, I brought this topic up at Mike's suggestion, and I do think
it is something that the Architecture Council should address otherwise,
what is the role of the architecture council... (I know that has been
asked many times). We have to be able to have some influence or
purpose in being otherwise we are just another group.