Subversion layout

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Subversion layout

Kip Streithorst
Administrator
All,

I've been working on creating the 4.2.0rc1 release this week and it
dawned on me that our Subversion layout will need to be adjusted.  Since
we are now creating release candidates before we create a final
production worthy release, we now need adjust our Subversion layout to
add a new layer of parallelism.  Basically we need to support working a
release from release candidates to a final production release while
simultaneous to that allowing developers to work on the code that will
become the next production release.  So, in order to accomplish that I'm
recommended the following Subversion layout:

branches/
        4.2.0   <-- Production release we're working towards
        4.2.X   <-- Next binary compat release we're going towards
        future  <-- Next binary breaking release

trunk/
        4.2.0
        4.2.X
        future

In this scenario, the 4.2.0 under branches/ and trunk/ would only exist
until we had 4.2.0 out the door, i.e. it would only exist between
4.2.0rc1 and 4.2.0.  Any work we had to do after 4.2.0rc1 in order to
create 4.2.0 would live here.  The 4.2.X folder would contain any work
on the next binary compatible release and once that work was complete we
create a new rc1, i.e. 4.2.1rc1.  The future work would contain any work
on the next binary breaking release and once that work was complete we
would create a new area (i.e. 4.3.X) under branches/ and current/ and we
would proceed to create the first release candidate from there.  What
does everyone think?  I would like to move on this early Monday morning
so that I can open the branches/ and trunk/ for 4.2.1 development.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Subversion layout

Forehand, Richard
Kip,

I can see this layout working fine for new features, but what about bug
fixes? Won't most bugs found in the release candidates be present in the
next binary compatible and future code bases since they were derived
from the same base code at some point? Will the roll up for a new
release candidate involve merging it or just the bug fix changes into
the other code bases?

Dick

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, May 30, 2008 5:03 PM
To: [hidden email]
Subject: Subversion layout


All,

I've been working on creating the 4.2.0rc1 release this week and it
dawned on me that our Subversion layout will need to be adjusted.  Since
we are now creating release candidates before we create a final
production worthy release, we now need adjust our Subversion layout to
add a new layer of parallelism.  Basically we need to support working a
release from release candidates to a final production release while
simultaneous to that allowing developers to work on the code that will
become the next production release.  So, in order to accomplish that I'm
recommended the following Subversion layout:

branches/
        4.2.0   <-- Production release we're working towards
        4.2.X   <-- Next binary compat release we're going towards
        future  <-- Next binary breaking release

trunk/
        4.2.0
        4.2.X
        future

In this scenario, the 4.2.0 under branches/ and trunk/ would only exist
until we had 4.2.0 out the door, i.e. it would only exist between
4.2.0rc1 and 4.2.0.  Any work we had to do after 4.2.0rc1 in order to
create 4.2.0 would live here.  The 4.2.X folder would contain any work
on the next binary compatible release and once that work was complete we
create a new rc1, i.e. 4.2.1rc1.  The future work would contain any work
on the next binary breaking release and once that work was complete we
would create a new area (i.e. 4.3.X) under branches/ and current/ and we
would proceed to create the first release candidate from there.  What
does everyone think?  I would like to move on this early Monday morning
so that I can open the branches/ and trunk/ for 4.2.1 development.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Subversion layout

Kip Streithorst
Administrator
In reply to this post by Kip Streithorst
Dick,

You are correct, in this model if we find a problem after rc1 is created, we will need to merge that change down into the binary compat trunk and the future trunk.  Now, in the short term I wouldn't suggest anyone put changes into the future trunk because it is binary incompatible which requires a fairly large buy-in from the rest of the community.  I'm not saying don't put changes in the future trunk, I'm just saying one should get community buy-in for when the future trunk will become a full production release before putting changes in there.  This won't apply to the binary compat trunk because it's must easier for plug-in developers to use a binary compat trunk.  But, you are correct we will need to push changes over in this model and I figured as the Release Manager it would be my job to make sure this happens before we perform a release.

Thanks,
Kip

----- Original Message ----
From: "Forehand, Richard" <[hidden email]>
To: [hidden email]
Sent: Friday, May 30, 2008 9:41:59 PM
Subject: RE:  Subversion layout

Kip,

I can see this layout working fine for new features, but what about bug
fixes? Won't most bugs found in the release candidates be present in the
next binary compatible and future code bases since they were derived
from the same base code at some point? Will the roll up for a new
release candidate involve merging it or just the bug fix changes into
the other code bases?

Dick

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, May 30, 2008 5:03 PM
To: [hidden email]
Subject: Subversion layout


All,

I've been working on creating the 4.2.0rc1 release this week and it
dawned on me that our Subversion layout will need to be adjusted.  Since
we are now creating release candidates before we create a final
production worthy release, we now need adjust our Subversion layout to
add a new layer of parallelism.  Basically we need to support working a
release from release candidates to a final production release while
simultaneous to that allowing developers to work on the code that will
become the next production release.  So, in order to accomplish that I'm
recommended the following Subversion layout:

branches/
    4.2.0   <-- Production release we're working towards
    4.2.X   <-- Next binary compat release we're going towards
    future  <-- Next binary breaking release

trunk/
    4.2.0
    4.2.X
    future

In this scenario, the 4.2.0 under branches/ and trunk/ would only exist
until we had 4.2.0 out the door, i.e. it would only exist between
4.2.0rc1 and 4.2.0.  Any work we had to do after 4.2.0rc1 in order to
create 4.2.0 would live here.  The 4.2.X folder would contain any work
on the next binary compatible release and once that work was complete we
create a new rc1, i.e. 4.2.1rc1.  The future work would contain any work
on the next binary breaking release and once that work was complete we
would create a new area (i.e. 4.3.X) under branches/ and current/ and we
would proceed to create the first release candidate from there.  What
does everyone think?  I would like to move on this early Monday morning
so that I can open the branches/ and trunk/ for 4.2.1 development.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


     

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Re: Subversion layout

Sulgrove, David
I like this approach in that I think it will be easier for all
developers to get a better picture of which changes are going into which
version.

Would merging changes from the release candidate into the binary
compatible and binary incompatible changes happen automatically at
release time, or will it be the responsibility of one or more developers
to perform the merge?

Will the addition of the 'future' folder replace the existing 'current'
folder?

David


-----Original Message-----
From: Kip Streithorst [mailto:[hidden email]]
Sent: Saturday, May 31, 2008 10:44 AM
To: [hidden email]
Subject: Re: Subversion layout

Dick,

You are correct, in this model if we find a problem after rc1 is
created, we will need to merge that change down into the binary compat
trunk and the future trunk.  Now, in the short term I wouldn't suggest
anyone put changes into the future trunk because it is binary
incompatible which requires a fairly large buy-in from the rest of the
community.  I'm not saying don't put changes in the future trunk, I'm
just saying one should get community buy-in for when the future trunk
will become a full production release before putting changes in there.
This won't apply to the binary compat trunk because it's must easier for
plug-in developers to use a binary compat trunk.  But, you are correct
we will need to push changes over in this model and I figured as the
Release Manager it would be my job to make sure this happens before we
perform a release.

Thanks,
Kip

----- Original Message ----
From: "Forehand, Richard" <[hidden email]>
To: [hidden email]
Sent: Friday, May 30, 2008 9:41:59 PM
Subject: RE:  Subversion layout

Kip,

I can see this layout working fine for new features, but what about bug
fixes? Won't most bugs found in the release candidates be present in the
next binary compatible and future code bases since they were derived
from the same base code at some point? Will the roll up for a new
release candidate involve merging it or just the bug fix changes into
the other code bases?

Dick

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, May 30, 2008 5:03 PM
To: [hidden email]
Subject: Subversion layout


All,

I've been working on creating the 4.2.0rc1 release this week and it
dawned on me that our Subversion layout will need to be adjusted.  Since
we are now creating release candidates before we create a final
production worthy release, we now need adjust our Subversion layout to
add a new layer of parallelism.  Basically we need to support working a
release from release candidates to a final production release while
simultaneous to that allowing developers to work on the code that will
become the next production release.  So, in order to accomplish that I'm
recommended the following Subversion layout:

branches/
    4.2.0   <-- Production release we're working towards
    4.2.X   <-- Next binary compat release we're going towards
    future  <-- Next binary breaking release

trunk/
    4.2.0
    4.2.X
    future

In this scenario, the 4.2.0 under branches/ and trunk/ would only exist
until we had 4.2.0 out the door, i.e. it would only exist between
4.2.0rc1 and 4.2.0.  Any work we had to do after 4.2.0rc1 in order to
create 4.2.0 would live here.  The 4.2.X folder would contain any work
on the next binary compatible release and once that work was complete we
create a new rc1, i.e. 4.2.1rc1.  The future work would contain any work
on the next binary breaking release and once that work was complete we
would create a new area (i.e. 4.3.X) under branches/ and current/ and we
would proceed to create the first release candidate from there.  What
does everyone think?  I would like to move on this early Monday morning
so that I can open the branches/ and trunk/ for 4.2.1 development.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


     

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: RE: Re: Subversion layout

Kip Streithorst
Administrator
Yes, the 'future' folder would replace the existing 'current' folder.

As Release Manager, I would make sure changes had been merged over
before a release was made.  In general, I would prefer if each committer
handled putting their changes into each applicable trunk.

Thanks,
Kip

-----Original Message-----
From: Sulgrove, David [mailto:[hidden email]]
Sent: Monday, June 02, 2008 9:52 AM
To: [hidden email]
Subject: RE: Re: Subversion layout

I like this approach in that I think it will be easier for all
developers to get a better picture of which changes are going into which
version.

Would merging changes from the release candidate into the binary
compatible and binary incompatible changes happen automatically at
release time, or will it be the responsibility of one or more developers
to perform the merge?

Will the addition of the 'future' folder replace the existing 'current'
folder?

David


-----Original Message-----
From: Kip Streithorst [mailto:[hidden email]]
Sent: Saturday, May 31, 2008 10:44 AM
To: [hidden email]
Subject: Re: Subversion layout

Dick,

You are correct, in this model if we find a problem after rc1 is
created, we will need to merge that change down into the binary compat
trunk and the future trunk.  Now, in the short term I wouldn't suggest
anyone put changes into the future trunk because it is binary
incompatible which requires a fairly large buy-in from the rest of the
community.  I'm not saying don't put changes in the future trunk, I'm
just saying one should get community buy-in for when the future trunk
will become a full production release before putting changes in there.
This won't apply to the binary compat trunk because it's must easier for
plug-in developers to use a binary compat trunk.  But, you are correct
we will need to push changes over in this model and I figured as the
Release Manager it would be my job to make sure this happens before we
perform a release.

Thanks,
Kip

----- Original Message ----
From: "Forehand, Richard" <[hidden email]>
To: [hidden email]
Sent: Friday, May 30, 2008 9:41:59 PM
Subject: RE:  Subversion layout

Kip,

I can see this layout working fine for new features, but what about bug
fixes? Won't most bugs found in the release candidates be present in the
next binary compatible and future code bases since they were derived
from the same base code at some point? Will the roll up for a new
release candidate involve merging it or just the bug fix changes into
the other code bases?

Dick

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, May 30, 2008 5:03 PM
To: [hidden email]
Subject: Subversion layout


All,

I've been working on creating the 4.2.0rc1 release this week and it
dawned on me that our Subversion layout will need to be adjusted.  Since
we are now creating release candidates before we create a final
production worthy release, we now need adjust our Subversion layout to
add a new layer of parallelism.  Basically we need to support working a
release from release candidates to a final production release while
simultaneous to that allowing developers to work on the code that will
become the next production release.  So, in order to accomplish that I'm
recommended the following Subversion layout:

branches/
    4.2.0   <-- Production release we're working towards
    4.2.X   <-- Next binary compat release we're going towards
    future  <-- Next binary breaking release

trunk/
    4.2.0
    4.2.X
    future

In this scenario, the 4.2.0 under branches/ and trunk/ would only exist
until we had 4.2.0 out the door, i.e. it would only exist between
4.2.0rc1 and 4.2.0.  Any work we had to do after 4.2.0rc1 in order to
create 4.2.0 would live here.  The 4.2.X folder would contain any work
on the next binary compatible release and once that work was complete we
create a new rc1, i.e. 4.2.1rc1.  The future work would contain any work
on the next binary breaking release and once that work was complete we
would create a new area (i.e. 4.3.X) under branches/ and current/ and we
would proceed to create the first release candidate from there.  What
does everyone think?  I would like to move on this early Monday morning
so that I can open the branches/ and trunk/ for 4.2.1 development.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


     

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: RE: RE: Re: Subversion layout

Sulgrove, David
OK, that sounds like a reasonable approach.

David


-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Monday, June 02, 2008 9:57 AM
To: [hidden email]
Subject: RE: RE: Re: Subversion layout

Yes, the 'future' folder would replace the existing 'current' folder.

As Release Manager, I would make sure changes had been merged over
before a release was made.  In general, I would prefer if each committer
handled putting their changes into each applicable trunk.

Thanks,
Kip

-----Original Message-----
From: Sulgrove, David [mailto:[hidden email]]
Sent: Monday, June 02, 2008 9:52 AM
To: [hidden email]
Subject: RE: Re: Subversion layout

I like this approach in that I think it will be easier for all
developers to get a better picture of which changes are going into which
version.

Would merging changes from the release candidate into the binary
compatible and binary incompatible changes happen automatically at
release time, or will it be the responsibility of one or more developers
to perform the merge?

Will the addition of the 'future' folder replace the existing 'current'
folder?

David


-----Original Message-----
From: Kip Streithorst [mailto:[hidden email]]
Sent: Saturday, May 31, 2008 10:44 AM
To: [hidden email]
Subject: Re: Subversion layout

Dick,

You are correct, in this model if we find a problem after rc1 is
created, we will need to merge that change down into the binary compat
trunk and the future trunk.  Now, in the short term I wouldn't suggest
anyone put changes into the future trunk because it is binary
incompatible which requires a fairly large buy-in from the rest of the
community.  I'm not saying don't put changes in the future trunk, I'm
just saying one should get community buy-in for when the future trunk
will become a full production release before putting changes in there.
This won't apply to the binary compat trunk because it's must easier for
plug-in developers to use a binary compat trunk.  But, you are correct
we will need to push changes over in this model and I figured as the
Release Manager it would be my job to make sure this happens before we
perform a release.

Thanks,
Kip

----- Original Message ----
From: "Forehand, Richard" <[hidden email]>
To: [hidden email]
Sent: Friday, May 30, 2008 9:41:59 PM
Subject: RE:  Subversion layout

Kip,

I can see this layout working fine for new features, but what about bug
fixes? Won't most bugs found in the release candidates be present in the
next binary compatible and future code bases since they were derived
from the same base code at some point? Will the roll up for a new
release candidate involve merging it or just the bug fix changes into
the other code bases?

Dick

-----Original Message-----
From: Streithorst, Kip [mailto:[hidden email]]
Sent: Friday, May 30, 2008 5:03 PM
To: [hidden email]
Subject: Subversion layout


All,

I've been working on creating the 4.2.0rc1 release this week and it
dawned on me that our Subversion layout will need to be adjusted.  Since
we are now creating release candidates before we create a final
production worthy release, we now need adjust our Subversion layout to
add a new layer of parallelism.  Basically we need to support working a
release from release candidates to a final production release while
simultaneous to that allowing developers to work on the code that will
become the next production release.  So, in order to accomplish that I'm
recommended the following Subversion layout:

branches/
    4.2.0   <-- Production release we're working towards
    4.2.X   <-- Next binary compat release we're going towards
    future  <-- Next binary breaking release

trunk/
    4.2.0
    4.2.X
    future

In this scenario, the 4.2.0 under branches/ and trunk/ would only exist
until we had 4.2.0 out the door, i.e. it would only exist between
4.2.0rc1 and 4.2.0.  Any work we had to do after 4.2.0rc1 in order to
create 4.2.0 would live here.  The 4.2.X folder would contain any work
on the next binary compatible release and once that work was complete we
create a new rc1, i.e. 4.2.1rc1.  The future work would contain any work
on the next binary breaking release and once that work was complete we
would create a new area (i.e. 4.3.X) under branches/ and current/ and we
would proceed to create the first release candidate from there.  What
does everyone think?  I would like to move on this early Monday morning
so that I can open the branches/ and trunk/ for 4.2.1 development.

Thanks,
Kip



This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


     

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.
Please  
notify the sender by email if you are not the intended recipient.  If
you are  
not the intended recipient, you may not use, copy, disclose, or
distribute this  
message or its contents or enclosures to any other person and any such
actions  
may be unlawful.  Ball reserves the right to monitor and review all
messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]