db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: ALTER TABLE NULL-NOT NULL not merged WAS Re: 10.2 status
Date Fri, 01 Sep 2006 23:45:46 GMT
Bryan Pendleton wrote:

>>> r437215 | bpendleton | 2006-08-26 12:42:02 -0700 (Sat, 26 Aug 2006) |
>>> 18 lines
>>>  DERBY-119: Add ALTER TABLE option to change column from NULL to NOT
>>> NULL
>> Why was this omitted?
> Probably because I suggested it should not be merged. I think this
> reflects my
> inexperience with the open source process: the changes for DERBY-119
> came in
> after the announced "feature complete date" (I just made that term up)
> for 10.2,
> which was something like August 10th, I believe.
> So when I committed it to the trunk I noted that it was a new feature,
> not a bug
> fix for a 10.2 feature, and I think Rick was only looking for bug fixes
> for 10.2
> features when he did his merging.
> I'm probably stepping all over the actual intended process with my words
> here, but
> hopefully someone will step in and clarify how things should work.

Not sure there is real "how things must work".

If there had been a release from a branch or even a release candidate*
made then I agree, putting a new feature into the branch is not acceptable.

However we are in a phase where the branch is just a place where Rick
produces snapshots and does a lot of merging.

So for any change in the trunk I think we have to think about the upside
and downside of not merging it while the branch is open for features:

    Feature will get into the community early, more use, more bugs
found, better quality sooner.

    Risk of introducing new regressions into the branch (which most
likely would already exist in the trunk)
    Behaviour of new funcionality might be incorrect or require future
changes that would have compatibility implications.

Now the downsides often drive the decision (in closed source projects at
least) to be "don't merge", leave it in the trunk, it's better that way.
This is fine, *but only* if some more work is planned to address the
quality, though QA, additional reviews, additional functional testing
etc. If nothing is planned then once it comes to be released the quality
will be the same *modulo* any testing by chance that exposed bugs.

In the open source world however, by releasing the code and allowing
others to use it, the more eyes syndrome means that the "testing by
chance" becomes the significant factor, thus the quality increases by
releasing it.

The ASF also has a "... desire to create high quality software ..." so
we have to balance that with the benefit of getting features into user's

My question was really driven by ALTER TABLE DROP COLUMN which I thought
was ready, and I was going to follow up this question with that one. But
then I looked at the Jira issue and say that there's still some amount
of work to do on that so it doesn't seem ready for the branch, even
though there is strong community demand for it.

Rick has been taking new features, such as DERBY-883.


* Though if the release candidate had real problems and there had been
no official release from the branch I could see that maybe the branch
could be open for features again.

View raw message