ALTER TABLE NULL-NOT NULL not merged WAS Re: 10.2 status

[Daniel John Debrunner <dj...@apache.org>]

Rick Hillegas 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?

Dan.

Re: ALTER TABLE NULL-NOT NULL not merged WAS Re: 10.2 status

[Rick Hillegas <Ri...@Sun.COM>]

Hi Bryan,

Thanks for porting this valuable feature to the 10.2 branch. I have 
raised the urgency of DERBY-1765 so that the feature will go out the 
door with documentation. I also added this feature to the Buddy-testing 
page.

I too am muddling my way forward. I see great value in getting real 
users to commodity-test new features as soon as possible, particularly 
since the beta effort isn't attracting a lot of attention from our user 
community.

Regards,
-Rick

Bryan Pendleton wrote:

>> 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.
>
>
> I completely agree. Release early, release often, get real feedback 
> from real users.
>
> Regarding your point about whether there is any additional work planned:
> I don't know of any additional such work on the *code*; however, there is
> documentation work needed, recorded in JIRA as DERBY-1765. I would like
> to contribute to the documentation work but am not going to get to 
> that soon.
>
> So if we merge DERBY-119 back to 10.2, it would get released in an
> undocumented fashion, at least until we found the time to address 
> DERBY-1765.
>
> Release Manager Rick, do you care to express an opinion here? Anybody 
> else?
>
> I am partial to Dan's observations, and my inclination is to go ahead and
> merge DERBY-119 to the 10.2 branch, unless I hear otherwise. So I'll 
> put it
> like this: if nobody expresses a contrary opinion in the next 60 hours 
> or so,
> I'll merge DERBY-119 back to the 10.2 branch.
>
> Thanks for the good discussion, Dan.
>
> bryan
>

Re: ALTER TABLE NULL-NOT NULL not merged WAS Re: 10.2 status

[Bryan Pendleton <bp...@amberpoint.com>]

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

I completely agree. Release early, release often, get real feedback from real users.

Regarding your point about whether there is any additional work planned:
I don't know of any additional such work on the *code*; however, there is
documentation work needed, recorded in JIRA as DERBY-1765. I would like
to contribute to the documentation work but am not going to get to that soon.

So if we merge DERBY-119 back to 10.2, it would get released in an
undocumented fashion, at least until we found the time to address DERBY-1765.

Release Manager Rick, do you care to express an opinion here? Anybody else?

I am partial to Dan's observations, and my inclination is to go ahead and
merge DERBY-119 to the 10.2 branch, unless I hear otherwise. So I'll put it
like this: if nobody expresses a contrary opinion in the next 60 hours or so,
I'll merge DERBY-119 back to the 10.2 branch.

Thanks for the good discussion, Dan.

bryan

Re: ALTER TABLE NULL-NOT NULL not merged WAS Re: 10.2 status

[Daniel John Debrunner <dj...@apache.org>]

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:

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

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

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.

Dan.

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

Re: ALTER TABLE NULL-NOT NULL not merged WAS Re: 10.2 status

[Bryan Pendleton <bp...@amberpoint.com>]

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

thanks,

bryan