Re: [Libxmlplusplus-general] libxml++ evolution

[Stefan S. <se...@sy...>]

Murray Cumming wrote:
> On Thu, 2003-01-30 at 17:47, Stefan Seefeld wrote:
> 
>>However, I don't agree that individual checkins must not generate
>>regressions. Sometimes changes are quite complex, and imply more than
>>just an implementation fix.
> 
> 
> Rejecting regressions is a reliable way to ensure that the code doesn't
> stay broken. Half-finished changes have significantly delayed or killed
> projects in the past. It's OK if you are going to fix-and-simultaneously
> improve things with your next check-in in a few minutes. 

I fully agree. Chances that subsequent commits will fix the regression
are higher if the person who commits is a core member, i.e. it's somehow
a question of trust.

> But taking the current patch as an example, if we don't check that it
> works then we _might_ discover later that we've made a fundamental
> change which can _never_ support even the old functionality. And, after
> all, the other patches that you've suggested are additions to the API,
> so it won't be any waste of time to make sure that the existing API
> still works with the patch.

well, as I said, there are parts of the API that are fundamentally 
incompatible with the suggested change: It's more than a change in 
implementation if the new code is *strictly* a wrapper around libxml2,
i.e. doesn't implement itself a DOM tree, but *always* delegates down.

So strictly speaking, a change like that may be required to be justified
by a design document. Though that's getting quite a bit formal, and it
would be the first time in an open project that I see that degree of
formal development process. (well, actually, I'm trying to encourage
developers in the fresco project to do just that, as things tend to
get out of hands at times...:-) But compared to that project, libxml++
is really small...)

> However, it's not too bad to submit incomplete candidate patches and
> gradually revise those patches until one is fit for a commit.

agreed, especially if part of the exercise is to get familiar with
internal project policies, for example coding guides etc.

Stefan