[fdo-internals] Development guidelines 1.0

[Mateusz Loskot]

Jason Birch wrote:
> 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.

Thank you, Jason!

> I know that you defined internal and external in your message, but I 
> think that we should stay away from using those terms.

You are perfectly right.
I just used external/internal words in technical manner, to only refer
inside my post. I'm not going to keep using these terms officially.

> 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.

Certainly, this was/is not my goal.
I believe the stronger integration of the team is the right direction.

> 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.

I agree with your opinion in 100%.
I understand, that if someone gets commit access to the FDO SVN, then
such person is trusted (ie. after some trial period).
Second, we use a few self-controlling tools like:

- commits mailing list

- Trac with its clear analysis of subsequent changests

- we should set up a Buildbot instance building and running tests
automatically

- it's not uncommon that something will get broken in the SVN, and we
can *not* avoid such situation in live project, but we are a team, so
there is always someone who will detect problem. The SVN trunk is a
living organism.


Buildbot helps to find problems in minutes after something got broken.
Just to give an example, yesterday night, one of commits broke the GDAL
in SVN so it stopped building, when I woke up, I always check the
Buildbot and I saw GDAL doesn't compile. I took a look at the Trac and
identified where is the problem rapidly:
http://bugzilla.remotesensing.org/show_bug.cgi?id=1522

Certainly, I could revoke changes myself, but I decided to submit a bug
report and leave it for Frank.

IMO, this example shows that the team (and the development cycle) is
self-reviewing enough, and there is no need to take any additional steps
to do pre-submission reviews, away from the SVN.
We just need to set up and use some tools, like Buildbot, automated
tests etc.

One note about trusted developers.
When I started contributing to the GDAL project, I didn't jump to the
deep water from the beginning. Before every commit, I gave a notice to
Frank like "I'm ready to commit fix XXX, do you want to check it before
I'll submit?" and Frank answered "please go on" or "yes, I'd like to
check it first". This was a kind of trial period, and after a few weeks,
we put away these announcements.

I believe that the FDO project could collect and follow some of
experiences from mature projects like GDAL.

> 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).

Right.
There are a few categories of changes:
- refactoring - no logic and behaviour of code is changed
- bug fixes
- new features

Bug fixes and new features may or may not introduce compatibility loss.

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

Yes, that's the main thing I'm asking for.

> Just my opinions :)

Very valuable opinions and thank you very much for all them.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net