10.2 status

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

Looks like we're in steady-state right now. New urgent bugs trickle in 
at about the same rate that we fix old ones. 12 outstanding urgent 
issues remain, of which half are unassigned. In addition, the licensing 
problem has not stopped churning several floors over my head. Again, I 
am grateful for the community's patience and I must ask for your 
continued good will.

The urgent bugs combined with the licensing problem mean that I cannot 
build a release candidate yet. However, I do plan to mega-merge and 
build another beta candidate tomorrow unless the community objects.

Regards,
-Rick

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

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: 10.2 status

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

Hi Dan,

Yes, I'll add this useful information to the wiki page after I've posted 
the new beta.

Regards,
-Rick

Daniel John Debrunner wrote:

>Rick Hillegas wrote:
>
>  
>
>>I tried the mega merge approach this time and ended up with a conflict
>>on one of the patches which had been ported previously. I don't know if
>>there was something special about the patch or if that's just to be
>>expected. So I broke the merge up into mini-merges whose endpoints were
>>the patches which had been ported already. That resulted in no
>>conflicts. Any regular policy would simplify the job of the release
>>manager. Unfortunately, regardless of the policy, people will make
>>mistakes and create outlying cases. It's those outliers which complicate
>>the process. All in all, I prefer the following policy--but I'm still
>>going to have to sanity check the submission comments on every patch:
>>
>>1) Don't bother merging from the trunk to the branch. I'll sweep up
>>these changes in a mega-merge.
>>
>>2) However, if you think a patch should not be ported to 10.2, then
>>please note that in the table at the end of this 10.2 wiki page:
>>http://wiki.apache.org/db-derby/TenTwoRelease.
>>    
>>
>
>Rick thanks for doing these merges, can you keep the wiki upto date with
>what *has* been merged? I think it's fine to say as I did after your
>last merge that everything has been merged up to a certain point
>excluding the list above, rather than list everything that has been merged.
>
>Eg.
>
>All changes on the trunk from the time the 10.2 branch was created and
>ending with subversion revision 432654 (excluding the above) were merged
>into the 10.2 branch on 2006/8/18.
>
>Thanks,
>Dan.
>
>
>
>  
>

Re: 10.2 status

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

Rick Hillegas wrote:

> I tried the mega merge approach this time and ended up with a conflict
> on one of the patches which had been ported previously. I don't know if
> there was something special about the patch or if that's just to be
> expected. So I broke the merge up into mini-merges whose endpoints were
> the patches which had been ported already. That resulted in no
> conflicts. Any regular policy would simplify the job of the release
> manager. Unfortunately, regardless of the policy, people will make
> mistakes and create outlying cases. It's those outliers which complicate
> the process. All in all, I prefer the following policy--but I'm still
> going to have to sanity check the submission comments on every patch:
> 
> 1) Don't bother merging from the trunk to the branch. I'll sweep up
> these changes in a mega-merge.
> 
> 2) However, if you think a patch should not be ported to 10.2, then
> please note that in the table at the end of this 10.2 wiki page:
> http://wiki.apache.org/db-derby/TenTwoRelease.

Rick thanks for doing these merges, can you keep the wiki upto date with
what *has* been merged? I think it's fine to say as I did after your
last merge that everything has been merged up to a certain point
excluding the list above, rather than list everything that has been merged.

Eg.

All changes on the trunk from the time the 10.2 branch was created and
ending with subversion revision 432654 (excluding the above) were merged
into the 10.2 branch on 2006/8/18.

Thanks,
Dan.

Re: 10.2 status

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

Thanks, Bryan!

Bryan Pendleton wrote:

> Rick Hillegas wrote:
>
>> This time around, the following patches were not merged.
>> 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
>>
>> r438942 | mikem | 2006-08-31 07:39:55 -0700 (Thu, 31 Aug 2006) | 11 
>> lines
>>  DERBY-1583 contributed by Bryan Pendleton
>
>
> Hi Rick,
>
> I've merged both these changes to the 10.2 branch, and updated the Wiki
> page accordingly.
>
> thanks,
>
> bryan
>

Re: 10.2 status

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

Rick Hillegas wrote:
> This time around, the following patches were not merged. 
> 
> 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
> 
> r438942 | mikem | 2006-08-31 07:39:55 -0700 (Thu, 31 Aug 2006) | 11 lines
>  DERBY-1583 contributed by Bryan Pendleton

Hi Rick,

I've merged both these changes to the 10.2 branch, and updated the Wiki
page accordingly.

thanks,

bryan

Re: 10.2 status

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

I tried the mega merge approach this time and ended up with a conflict 
on one of the patches which had been ported previously. I don't know if 
there was something special about the patch or if that's just to be 
expected. So I broke the merge up into mini-merges whose endpoints were 
the patches which had been ported already. That resulted in no 
conflicts. Any regular policy would simplify the job of the release 
manager. Unfortunately, regardless of the policy, people will make 
mistakes and create outlying cases. It's those outliers which complicate 
the process. All in all, I prefer the following policy--but I'm still 
going to have to sanity check the submission comments on every patch:

1) Don't bother merging from the trunk to the branch. I'll sweep up 
these changes in a mega-merge.

2) However, if you think a patch should not be ported to 10.2, then 
please note that in the table at the end of this 10.2 wiki page: 
http://wiki.apache.org/db-derby/TenTwoRelease.

This time around, the following patches were not merged. All of the 
others were merged either by me or by the original committers:

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

r438942 | mikem | 2006-08-31 07:39:55 -0700 (Thu, 31 Aug 2006) | 11 lines
  DERBY-1583 contributed by Bryan Pendleton

Thanks,
-Rick


Mike Matrigali wrote:

>
>
> Rick Hillegas wrote:
>
>> Thanks for the warning, Mike. I'm cautiously hopeful that this won't 
>> be a problem. I'll find out!
>>
>> Regards,
>> -Rick
>>
> Definitely let us know which makes the work easier.  For most changes I
> would be happy to commit to trunk and wait for the mega merge to move
> them to the branch.
>

Re: 10.2 status

[Mike Matrigali <mi...@sbcglobal.net>]

Rick Hillegas wrote:
> Thanks for the warning, Mike. I'm cautiously hopeful that this won't be 
> a problem. I'll find out!
> 
> Regards,
> -Rick
> 
Definitely let us know which makes the work easier.  For most changes I
would be happy to commit to trunk and wait for the mega merge to move
them to the branch.

Re: 10.2 status

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

Thanks for the warning, Mike. I'm cautiously hopeful that this won't be 
a problem. I'll find out!

Regards,
-Rick

Mike Matrigali wrote:

> I have been doing merges to 10.2 branch, does this cause your
> "mega merges" problems?
>
> Rick Hillegas wrote:
>
>> Looks like we're in steady-state right now. New urgent bugs trickle 
>> in at about the same rate that we fix old ones. 12 outstanding urgent 
>> issues remain, of which half are unassigned. In addition, the 
>> licensing problem has not stopped churning several floors over my 
>> head. Again, I am grateful for the community's patience and I must 
>> ask for your continued good will.
>>
>> The urgent bugs combined with the licensing problem mean that I 
>> cannot build a release candidate yet. However, I do plan to 
>> mega-merge and build another beta candidate tomorrow unless the 
>> community objects.
>>
>> Regards,
>> -Rick
>>
>>
>

Re: 10.2 status

[Mike Matrigali <mi...@sbcglobal.net>]

I have been doing merges to 10.2 branch, does this cause your
"mega merges" problems?

Rick Hillegas wrote:
> Looks like we're in steady-state right now. New urgent bugs trickle in 
> at about the same rate that we fix old ones. 12 outstanding urgent 
> issues remain, of which half are unassigned. In addition, the licensing 
> problem has not stopped churning several floors over my head. Again, I 
> am grateful for the community's patience and I must ask for your 
> continued good will.
> 
> The urgent bugs combined with the licensing problem mean that I cannot 
> build a release candidate yet. However, I do plan to mega-merge and 
> build another beta candidate tomorrow unless the community objects.
> 
> Regards,
> -Rick
> 
>