Re: platform compatibility policy

[Colm Smyth <Colm Smyth ireland sun com>]

>From: Havoc Pennington <hp redhat com>
>
>Colm Smyth <Colm Smyth ireland sun com> writes: 
>> There was some discussion earlier about which interface enhancements
>> should be allowed in micro and minor version changes. I think that
>> so long as the enhancement in no way breaks compatibility, it does
>> not matter what changes arise. 
>
>I would say the issue is not the relationship of interface
>enhancements to the version numbers, but rather the relationship of
>them to the release cycles. i.e. any large changes need to be
>thoroughly peer-reviewed, the APIs tried out in apps, and we need them
>to go through a QA process. At the moment we put out bugfix releases
>with very little QA, and rely on making only tiny bugfix-size changes
>to ensure stability.

QA and review are two ways to ensure that the enhancement in no
way breaks compatibility. I like the idea of short release cycles,
so I really like having automated test scripts and an ABI tester
to assure confidence in each release.

>So the real issue for me is to be sure interfaces don't get added
>without going through a release process. We don't have any way to make
>sure an interface is high-quality and stable otherwise, at least not
>for now. The release process for bugfix releases isn't long enough or
>rigorous enough to QA major code changes.

You're making a distinction between a code change that adds an
interface and a code change that doesn't. To me, any significant
set of code changes needs to have some kind of review. If
you "release" without some kind of testing and/or review, I would
see it that you've just checked in some new code.

This is really an aside, but I don't know how many people have
come across the concept of 'extreme programming'; I think some
of the most important concepts in this style of development
are:

- pair programming
- automated tests to provide confidence for each set of new changes
- just-in-time design

Developing on the internet doesn't allow for true 'pair programming',
but it is a good idea to find someone to partner with when making
code changes. If both developers are working on a module and review
each other's code changes, bugs get found earlier but even better
the number of design flaws is reduced. All that's needed is to
send a short description of the changes along with the diffs to
the mail alias for the module. Anyone on the alias may offer feedback,
but your chosen partner should definitely do a rapid code and design review.

Automated tests are a pain to write, but a joy to run. There's nothing
like the feeling of making a lot of complicated code changes to your
module, running your test suite and coming up with the result 'everything
worked'.

Just-in-time design is basically designing and writing code only
when you are ready to implement a feature. If you have big plans
for your module, write them in a design document. Trying to design
too far ahead and writing code to support that design sometimes ties
you in. This doesn't mean that there's no benefit in writing stub
functions or scaffolding code that doesn't completely implement a
feature; it just means that you shouldn't complicate your code
too early. Most of the developers I've seen on the GNOME project
are focussed on creating good features, so I don't think this
is something new to GNOME.

Now back to your regularly scheduled compatibility discussion...!

>Havoc
>

Colm.


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers