Ed,
Eclipse has a whole heck of a lot of rules
Actually, I don't think it has very many rules (committers must be
voted in, new projects must be announced to the community, IP must be
cleared before release, ...), so perhaps the problem is that we (we,
the EMO, and we, the PMCs, and we, the Architecture Council) have not
done a good job of explaining them to the committer community. I'd like
to fix that, but how? Perhaps I should re-write the development
process guidelines again but this time work on a simple one pager
version? Based on your experience with EMF and Modeling and all the
sub-projects and the various Bjorn-as-a-policeman issues you've dealt
with, what would you suggest I put in that one-pager? Could you suggest
an outline?
that tend to change rather frequently.
I disagree. They change once a year when the Board approves a new
version of the rules. Seriously, look at the CVS history around the
development process documents and you'll see that they just don't
change frequently (unless you consider once a year frequently)...
However, you believe they do change often, so I'm guessing that what's
happening is that each time you find something that you didn't know,
you make the assumption that the rules have changed when in fact the
rules have been the same but that nobody noticed the incorrect
situations before. So what's really happening is that the EMO is
becoming more efficient and thus has more time to spend making sure the
constraints that we (collectively, the Board, including the committers)
set are being followed.
- Bjorn
|