[fdo-internals] Development guidelines 1.0

[Jason Birch]

Mateusz wrote:

> I think it would be reasonable and right in time to
> discuss FDO development process in some details and
> describe it.

I agree.

I know that you defined internal and external in your message, but I
think that we should stay away from using those terms.  It reinforces
the difference between the core ADSK team that wrote the majority of the
code, and new developers coming on, leading to a division that
eventually needs to be reduced in moving to a truly open development
model.

Not being a developer, I don't have many comments on the rest of your
questions, but I have some opinions (I have a reputation in my office
for having too many opinions).

I haven't seen too many (any?) successful open source projects with
pre-commit reviews.  Code stability can be maintained by initiating code
freezes or bug-only periods at various points in the release cycle with
more scrutiny applied to changes during this time.  And every developer
should be practicing conspicuous code review, subscribing to the commits
list and forwarding constructive criticism to the -devel list.

Of course, this doesn't mean that there's a free-for-all.  Changes to
code should be done through an RFC process, unless it's a bug fix or,
during initial implementation of a provider, planned phased enhancement.
And any changes other than obvious bug fixes should be floated to the
list first.  Until some of the non-ADSK folks get a full understanding
of the code base, "obvious" should have a fairly high bar (all changes
should be double-checked).

It would be worth codifying this stuff and the release procedures (once
agreed on) on the website/wiki.

Just my opinions :)

Jason