You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2005/10/20 01:04:32 UTC
VOTE: Shared Components Guidelines
Hi, all. I'd like to have a formal vote on the shared components
guidelines as published at
http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
Thanks,
David
Re: VOTE: Shared Components Guidelines
Posted by David Van Couvering <Da...@Sun.COM>.
Ok, I agree. I will call for a new vote.
David
Daniel John Debrunner wrote On 10/21/05 06:11,:
> David W. Van Couvering wrote:
>
>
>>>Hi, all. I'd like to have a formal vote on the shared components
>>>guidelines as published at
>>>
>>>http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>
>
> -1
>
> The wiki page has changed about six times (or more) during the vote,
> thus what exactly are people voting on? The wiki is a great place to
> build a proposal and to keep a single view of it following e-mail
> discussion, but the proposal needs to be directly in the vote e-mail
> (and hence the archives). Discussion happens on the e-mail lists in
> Apache projects.
>
> Minor changes & clarifications can be made in the vote e-mail thread
> during a vote, but any significant change should cause a new vote. I
> would expect voters to continue to keep track of the discussion after
> they have voted.
>
> Dan.
>
Re: VOTE: Shared Components Guidelines
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David W. Van Couvering wrote:
>> Hi, all. I'd like to have a formal vote on the shared components
>> guidelines as published at
>>
>> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
-1
The wiki page has changed about six times (or more) during the vote,
thus what exactly are people voting on? The wiki is a great place to
build a proposal and to keep a single view of it following e-mail
discussion, but the proposal needs to be directly in the vote e-mail
(and hence the archives). Discussion happens on the e-mail lists in
Apache projects.
Minor changes & clarifications can be made in the vote e-mail thread
during a vote, but any significant change should cause a new vote. I
would expect voters to continue to keep track of the discussion after
they have voted.
Dan.
Re: VOTE: Shared Components Guidelines
Posted by Kathey Marsden <km...@sbcglobal.net>.
Andrew McIntyre wrote:
>
> On Oct 20, 2005, at 4:13 PM, Daniel John Debrunner wrote:
>
>> Is this ok? A vote that refers to a page that is by definition
>> updateable? This means there will be no records in the archives on what
>> exactly was voted on. Maybe the wiki page could be extracted into the
>> call to vote e-mail.
>
>
> This is why wikis are nice, but STATUS is really the place to keep a
> record of important votes and proposal type information for
> posterity. I think it's OK to have the vote on the proposal, but then
> the vote and proposal should then be recorded in STATUS, and the web
> page for the proposal should move from the wiki to a permanent place
> in the website.
>
Perhaps for the voting part it would be good to have a short ballot
measure summarizing what we are doing, the externalized product impact
and the general strategy. This would be something that would not
monopolize the STATUS file and could be understood by those who are
really only interested in the product impact. Those with a keen
interest in implementation details can continue to review and change the
Wiki page. Perhaps something like...
Implement a framework to allow code sharing across the product jars that
will allow derbyclient.jar, derby.jar and derbytools.jar of the same
major version to be loaded in a Java VM without having to use
specialized classloaders. If the major version of the jars loaded in a
JVM differ, the user will need to separate the two versions by using
separate classloaders. Code sharing will be implemented by versioning
and deprecating internal API's. The implementation will not have any
significant impact on jar file size or otherwise affect product
distribution or usage.
That's just a stab at it, but I think it has most of the parts that are
really controversial, covers the significant risk areas, and makes it
clear that users can no longer mix jars across major versions. I think
it is good to be clear about that since as I see it, that is currently
the only proposed change to external behaviour. The Wiki page says that
developers should try to avoid breaking compatiblity across major
versions and that's fine, but makes no committment, so it is best if
we just document that it won't work.
Kathey
Re: VOTE: Shared Components Guidelines
Posted by Francois Orsini <fr...@gmail.com>.
On 10/21/05, David W. Van Couvering <Da...@sun.com> wrote:
>
>
>
> Francois Orsini wrote:
> > David, it looks good. Just a few comments.
> >
> > * Regarding "Mixed Version Support", it might be good at some point to
> > elaborate on "As much as possible, two applications should be able to
> > use different versions of Derby within the same Java VM without having
> > to resort to creating specialized classloaders." - Were you referring to
> > 2 different Derby engines or/and Clients or/and mix of the 2 running in
> > the same JVM? If an application is expected to run at a certain level of
> > Derby and it is not because of class order loading issues which could
> > cause the application not to use the appropriate level of Derby classes.
> > Depending what the statement meant I don't think we can completely rule
> > out specialized class loaders to isolate loading of a specific and
> > expected level of classes for certain configuration. More clarifications
> > on what the statement meant to say would be nice...
>
> Hi, Francois. I'm not sure I fully understand your question, but let me
> try to answer. The intent was that this was to cover the case where you
> specifically want to run the network client at one version and the
> embedded client at another. In this case you either have one
> application with mixed version requirements or two applications running
> in the same container with differing version requirements, in which case
> you will need separate classloaders with separate classpaths. But
> generally this is handled by the container provider environment and tools.
>
> I would like to specifically talk about the first case -- a single VM
> wanting to use a different version for the network client and the
> embedded client. I can adjust the proposal (before I submit for another
> vote) to try and be more explicit about this.
Yes please - I was just trying to say that the current proposal is not going
to be the panacea where specialized class loaders would be required for
_certain_ (mixed) configuration of network client drivers (various ones with
different versions in the same JVM) and derby engine version would happen to
run in an app server which would not necessary install separate class
loaders for the 2 applications (i.e. HomeGrown ones)...
>
> > * As a guideline, we should try to have the <ComponentName>Info class at
> > the top level of the package for that component (in the case of Common
> > component, one would expect to have the class be defined under the
> > org.apache.derby.common package. I may have missed this being mentioned
> > in the proposal.
>
> OK, seems reasonable.
>
> >
> > * Would be nice to run JVM / Derby incompatibility test harness suite
> > when a new 'common' class is introduced (not just a new package).
>
> I'm not sure why you'd want to run compatibility tests when adding new
> classes and packages. The compatibility issue really comes up when you
> modify an existing class, right?
Yes, you're right - Even if a newly added class to the common package area
gets referenced by other classes already in the same package, them the
modification rule will apply since they would have had to be modified in
order to reference the new class ;)
Anyway, I don't know if it's essential to outline when compatibility
> tests should be run as part of these guidelines...
>
> >
> > +1
> >
>
> Thanks, but we'll need your vote again on the next go-round.
Will do - thanks.
David
> > --francois
> >
> >
>
>
>
Re: VOTE: Shared Components Guidelines
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Francois Orsini wrote:
> David, it looks good. Just a few comments.
>
> * Regarding "Mixed Version Support", it might be good at some point to
> elaborate on "As much as possible, two applications should be able to
> use different versions of Derby within the same Java VM without having
> to resort to creating specialized classloaders." - Were you referring to
> 2 different Derby engines or/and Clients or/and mix of the 2 running in
> the same JVM? If an application is expected to run at a certain level of
> Derby and it is not because of class order loading issues which could
> cause the application not to use the appropriate level of Derby classes.
> Depending what the statement meant I don't think we can completely rule
> out specialized class loaders to isolate loading of a specific and
> expected level of classes for certain configuration. More clarifications
> on what the statement meant to say would be nice...
Hi, Francois. I'm not sure I fully understand your question, but let me
try to answer. The intent was that this was to cover the case where you
specifically want to run the network client at one version and the
embedded client at another. In this case you either have one
application with mixed version requirements or two applications running
in the same container with differing version requirements, in which case
you will need separate classloaders with separate classpaths. But
generally this is handled by the container provider environment and tools.
I would like to specifically talk about the first case -- a single VM
wanting to use a different version for the network client and the
embedded client. I can adjust the proposal (before I submit for another
vote) to try and be more explicit about this.
>
> * As a guideline, we should try to have the <ComponentName>Info class at
> the top level of the package for that component (in the case of Common
> component, one would expect to have the class be defined under the
> org.apache.derby.common package. I may have missed this being mentioned
> in the proposal.
OK, seems reasonable.
>
> * Would be nice to run JVM / Derby incompatibility test harness suite
> when a new 'common' class is introduced (not just a new package).
I'm not sure why you'd want to run compatibility tests when adding new
classes and packages. The compatibility issue really comes up when you
modify an existing class, right?
Anyway, I don't know if it's essential to outline when compatibility
tests should be run as part of these guidelines...
>
> +1
>
Thanks, but we'll need your vote again on the next go-round.
David
> --francois
>
>
Re: VOTE: Shared Components Guidelines
Posted by Francois Orsini <fr...@gmail.com>.
David, it looks good. Just a few comments.
* Regarding "Mixed Version Support", it might be good at some point to
elaborate on "As much as possible, two applications should be able to use
different versions of Derby within the same Java VM without having to resort
to creating specialized classloaders." - Were you referring to 2 different
Derby engines or/and Clients or/and mix of the 2 running in the same JVM? If
an application is expected to run at a certain level of Derby and it is not
because of class order loading issues which could cause the application not
to use the appropriate level of Derby classes. Depending what the statement
meant I don't think we can completely rule out specialized class loaders to
isolate loading of a specific and expected level of classes for certain
configuration. More clarifications on what the statement meant to say would
be nice...
* As a guideline, we should try to have the <ComponentName>Info class at the
top level of the package for that component (in the case of Common
component, one would expect to have the class be defined under the
org.apache.derby.common package. I may have missed this being mentioned in
the proposal.
* Would be nice to run JVM / Derby incompatibility test harness suite when a
new 'common' class is introduced (not just a new package).
+1
--francois
Re: VOTE: Shared Components Guidelines
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Rick Hillegas wrote:
> Sigh. I also created a wiki page for recording votes
> (http://wiki.apache.org/db-derby/VoteResults). This page hangs off the
> top Derby wiki page. I can see that it's an unclean innovation because
> it lets non-committers fake vote results. However, the wiki page has two
> advantages over the STATUS page:
>
> 1) It makes votes visible on the web site.
>
> 2) It empowers non-commiters like me to record results for votes which
> we call.
>
I think the wiki is a great place for recording these votes. The link
into the e-mail archives provides the validation of the vote.
The wiki is a great place to consolidate any information, it's just not
the definitive decision archive.
Dan.
Re: VOTE: Shared Components Guidelines
Posted by Rick Hillegas <Ri...@Sun.COM>.
Sigh. I also created a wiki page for recording votes
(http://wiki.apache.org/db-derby/VoteResults). This page hangs off the
top Derby wiki page. I can see that it's an unclean innovation because
it lets non-committers fake vote results. However, the wiki page has two
advantages over the STATUS page:
1) It makes votes visible on the web site.
2) It empowers non-commiters like me to record results for votes which
we call.
Could we at least promote vote results to somewhere on the website? If
that's controversial, could the web site at least tell people where to
find vote results?
Thanks,
-Rick
Andrew McIntyre wrote:
>On 10/21/05, David W. Van Couvering <Da...@sun.com> wrote:
>
>
>>Can you explain how the STATUS gets modified?
>>
>>
>
>It's a text file. You'll find it in the root of the code tree.
>Committers can just edit it and check it in. :-)
>
>Anyone can update STATUS, though, by posting a patch to derby-dev. The
>latest STATUS is viewable on the web for all to see via svn's web
>interface:
>
>http://svn.apache.org/repos/asf/db/derby/code/trunk/STATUS
>
>andrew
>
>
Re: VOTE: Shared Components Guidelines
Posted by Andrew McIntyre <mc...@gmail.com>.
On 10/21/05, David W. Van Couvering <Da...@sun.com> wrote:
> Can you explain how the STATUS gets modified?
It's a text file. You'll find it in the root of the code tree.
Committers can just edit it and check it in. :-)
Anyone can update STATUS, though, by posting a patch to derby-dev. The
latest STATUS is viewable on the web for all to see via svn's web
interface:
http://svn.apache.org/repos/asf/db/derby/code/trunk/STATUS
andrew
Re: VOTE: Shared Components Guidelines
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Can you explain how the STATUS gets modified?
Thanks,
David
Andrew McIntyre wrote:
>
> On Oct 20, 2005, at 4:13 PM, Daniel John Debrunner wrote:
>
>> Is this ok? A vote that refers to a page that is by definition
>> updateable? This means there will be no records in the archives on what
>> exactly was voted on. Maybe the wiki page could be extracted into the
>> call to vote e-mail.
>
>
> This is why wikis are nice, but STATUS is really the place to keep a
> record of important votes and proposal type information for posterity.
> I think it's OK to have the vote on the proposal, but then the vote and
> proposal should then be recorded in STATUS, and the web page for the
> proposal should move from the wiki to a permanent place in the website.
>
> my $.02,
> andrew
Re: VOTE: Shared Components Guidelines
Posted by Andrew McIntyre <mc...@gmail.com>.
On Oct 20, 2005, at 4:13 PM, Daniel John Debrunner wrote:
> Is this ok? A vote that refers to a page that is by definition
> updateable? This means there will be no records in the archives on
> what
> exactly was voted on. Maybe the wiki page could be extracted into the
> call to vote e-mail.
This is why wikis are nice, but STATUS is really the place to keep a
record of important votes and proposal type information for
posterity. I think it's OK to have the vote on the proposal, but then
the vote and proposal should then be recorded in STATUS, and the web
page for the proposal should move from the wiki to a permanent place
in the website.
my $.02,
andrew
Re: VOTE: Shared Components Guidelines
Posted by David Van Couvering <Da...@Sun.COM>.
Hi, that's a good point, Dan.
I have a better solution, though. Each Wiki page is revisioned, and if
you click on "info" you can look at any old revision of the page. So I
will modify the vote to be a vote on *revision 27* of the page, with the
following link.
http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines?action=recall&rev=27
Those of you who have already recorded your vote (I think Rick is the
only one), should look at this revision and make sure your vote still
stands.
If after further feedback I want to submit a new version, I'll call for
a revote with a new revision number of the page.
Once the vote is approved, I'll make a snapshot of the page marked as
the *approved* version, e.g. SharedComponentVersioningGuidelinesApproved
with a link to the recorded vote.
Does this sound good?
David
Daniel John Debrunner wrote On 10/20/05 16:13,:
> David W. Van Couvering wrote:
>
>>Hi, all. I'd like to have a formal vote on the shared components
>>guidelines as published at
>>
>>http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>
>
> Is this ok? A vote that refers to a page that is by definition
> updateable? This means there will be no records in the archives on what
> exactly was voted on. Maybe the wiki page could be extracted into the
> call to vote e-mail.
>
> Dan.
>
Re: VOTE: Shared Components Guidelines
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David W. Van Couvering wrote:
> Hi, all. I'd like to have a formal vote on the shared components
> guidelines as published at
>
> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
Is this ok? A vote that refers to a page that is by definition
updateable? This means there will be no records in the archives on what
exactly was voted on. Maybe the wiki page could be extracted into the
call to vote e-mail.
Dan.
Re: VOTE: Shared Components Guidelines
Posted by David Van Couvering <Da...@Sun.COM>.
Kathey Marsden wrote On 10/20/05 14:26,:
> David Van Couvering wrote:
>
>
>>This sounds appealing, but I was told that in an Apache open source
>>proejct like this we can't really have checkin policies, only guidelines?
>>
>>
>>
>
> Well we can reject any submission if it causes a regression and what I
> am suggesting is that any incompatiblity of jars within the same major
> version or unreasonable jar file growth be considered a regression.
> Can we make that part of the vote?
>
Yes, I would agree to that. Note that compatibility tests are not
expected to be run as part of a gate to checkin, but would be run at a
minimum as a release test, and perhaps as part of a nightly or weekly
test run.
I will add something to this effect to the guidelines page and make it
part of the vote.
>
>>I do think having compatibility tests will help ensure that these
>>guidelines are met, however. I didn't think about a regression test to
>>catch massive jar file growth, that seems easy enough to add...
>>
>>
>>
>
> Tests are always good. I have to confess my first month with
> Cloudscape, I made the mistake of pulling a server class into the tools
> jar because it looked like something I could use. It came in later
> as a high priority customer bug labeled "ij needs a DIET!". Your test
> would have sure helped me out.
>
OK. I can add a JIRA item to test for a regression test that can be
used to monitor JAR file growth.
David
> Kathey
>
>
Re: VOTE: Shared Components Guidelines
Posted by Kathey Marsden <km...@sbcglobal.net>.
David Van Couvering wrote:
>This sounds appealing, but I was told that in an Apache open source
>proejct like this we can't really have checkin policies, only guidelines?
>
>
>
Well we can reject any submission if it causes a regression and what I
am suggesting is that any incompatiblity of jars within the same major
version or unreasonable jar file growth be considered a regression.
Can we make that part of the vote?
>I do think having compatibility tests will help ensure that these
>guidelines are met, however. I didn't think about a regression test to
>catch massive jar file growth, that seems easy enough to add...
>
>
>
Tests are always good. I have to confess my first month with
Cloudscape, I made the mistake of pulling a server class into the tools
jar because it looked like something I could use. It came in later
as a high priority customer bug labeled "ij needs a DIET!". Your test
would have sure helped me out.
Kathey
Re: VOTE: Shared Components Guidelines
Posted by David Van Couvering <Da...@Sun.COM>.
This sounds appealing, but I was told that in an Apache open source
proejct like this we can't really have checkin policies, only guidelines?
I do think having compatibility tests will help ensure that these
guidelines are met, however. I didn't think about a regression test to
catch massive jar file growth, that seems easy enough to add...
David
Kathey Marsden wrote On 10/20/05 09:46,:
> John Embretsen wrote:
>
>
>>David W. Van Couvering wrote:
>>
>>
>>>I can add this, but to answer real quickly, at this point there are
>>>no restrictions and no visible user impact.
>>
>>ly add a "no" between the words "be" and "visible" in the following
>>sentence in the "User Visible Impact and Restrictions" sectio
>>Then you should probabn:
>>
>>"With these guidelines in place, there should in general be visible
>>impact or restrictions for Derby users."
>
>
>
> I think I would prefer to see a clear commitment (without words like
> "should" and "in general" ) that:
>
> There *will* be no visible impact or restrictions for Derby users who
> have different versions of derbyclient.jar, derbytools.jar and
> derby.jar in the same JVM, unless the jars are different major
> versions. If the major versions differ, classloaders need to be used
> to separate the versions.
>
> No visible impact implies the following checkin requirements for any
> common code.
>
> - derbyclient.jar, derby.jar, and derbytools.jar of the same major
> version can continue to be mixed within the same JVM classpath without
> any difference in behavior from loading these jars in separate
> classloaders.
> - Jar file growth is commensurate with functionality improvement.
> - Replacing any jar with a jar of the same major version will not
> require any user classpath changes.
>
> Is that what we are committing to?
>
> Kathey
>
>
>
Re: VOTE: Shared Components Guidelines
Posted by Kathey Marsden <km...@sbcglobal.net>.
John Embretsen wrote:
> David W. Van Couvering wrote:
>
>> I can add this, but to answer real quickly, at this point there are
>> no restrictions and no visible user impact.
>
> ly add a "no" between the words "be" and "visible" in the following
> sentence in the "User Visible Impact and Restrictions" sectio
> Then you should probabn:
>
> "With these guidelines in place, there should in general be visible
> impact or restrictions for Derby users."
I think I would prefer to see a clear commitment (without words like
"should" and "in general" ) that:
There *will* be no visible impact or restrictions for Derby users who
have different versions of derbyclient.jar, derbytools.jar and
derby.jar in the same JVM, unless the jars are different major
versions. If the major versions differ, classloaders need to be used
to separate the versions.
No visible impact implies the following checkin requirements for any
common code.
- derbyclient.jar, derby.jar, and derbytools.jar of the same major
version can continue to be mixed within the same JVM classpath without
any difference in behavior from loading these jars in separate
classloaders.
- Jar file growth is commensurate with functionality improvement.
- Replacing any jar with a jar of the same major version will not
require any user classpath changes.
Is that what we are committing to?
Kathey
Re: VOTE: Shared Components Guidelines
Posted by John Embretsen <Jo...@Sun.COM>.
David W. Van Couvering wrote:
> I can add this, but to answer real quickly, at this point there are no
> restrictions and no visible user impact.
Then you should probably add a "no" between the words "be" and "visible"
in the following sentence in the "User Visible Impact and Restrictions"
section:
"With these guidelines in place, there should in general be visible
impact or restrictions for Derby users."
;)
> If at some point we make a
> change that is not forward-compatible (which by the proposed guidelines
> would only be allowed across major versions like from 10 to 11), then
> the user should place the jar files from the latest revisions first in
> the classpath.
>
> Your question has also reminded me to put in a note about testing
> impact: we will want to add compatibility tests to ensure that
> incompatible changes have not been added between releases. Note that
> these tests do not need to exist until the first release *after* 10.2
> (assuming the first release with common code is in 10.2).
>
> I'll add both of these items to the policy.
>
> David
>
> Kathey Marsden wrote:
>
>> David W. Van Couvering wrote:
>>
>>
>>> Hi, all. I'd like to have a formal vote on the shared components
>>> guidelines as published at
>>>
>>> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>>>
>>
>> A while back we talked about adding a section that would describe the
>> user impact and any restrictions on mixing derbyclient.jar, derby.jar
>> and derbytools.jar from the perspective of the user. But I don't see
>> that yet. What restrictions on jar mixing will exist and need to be
>> documented in the user documentation with this proprosal?
>> Kathey
>>
>>
--
John
Re: VOTE: Shared Components Guidelines
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I can add this, but to answer real quickly, at this point there are no
restrictions and no visible user impact. If at some point we make a
change that is not forward-compatible (which by the proposed guidelines
would only be allowed across major versions like from 10 to 11), then
the user should place the jar files from the latest revisions first in
the classpath.
Your question has also reminded me to put in a note about testing
impact: we will want to add compatibility tests to ensure that
incompatible changes have not been added between releases. Note that
these tests do not need to exist until the first release *after* 10.2
(assuming the first release with common code is in 10.2).
I'll add both of these items to the policy.
David
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>Hi, all. I'd like to have a formal vote on the shared components
>>guidelines as published at
>>
>>http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>>
>
> A while back we talked about adding a section that would describe the
> user impact and any restrictions on mixing derbyclient.jar, derby.jar
> and derbytools.jar from the perspective of the user. But I don't see
> that yet. What restrictions on jar mixing will exist and need to be
> documented in the user documentation with this proprosal?
>
> Kathey
>
>
Re: VOTE: Shared Components Guidelines
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> Hi, all. I'd like to have a formal vote on the shared components
> guidelines as published at
>
> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>
A while back we talked about adding a section that would describe the
user impact and any restrictions on mixing derbyclient.jar, derby.jar
and derbytools.jar from the perspective of the user. But I don't see
that yet. What restrictions on jar mixing will exist and need to be
documented in the user documentation with this proprosal?
Kathey
Re: VOTE: Shared Components Guidelines
Posted by Rick Hillegas <Ri...@Sun.COM>.
+1
David W. Van Couvering wrote:
> Hi, all. I'd like to have a formal vote on the shared components
> guidelines as published at
>
> http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
>
> Thanks,
>
> David