You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2006/09/12 17:50:15 UTC
Qpid Release Process
Hi Folks,
I think, this is a good time for us to discuss and agree on a release
mechanism that's agreeable to the Apache way.
As per my observations from projects like Axis2, Synapse, Tuscany, Geronimo
...etc the release process is as follows.
We start with milestone releases (M1, M2 ...Mx) until we graduate from the
incubator.
Once graduated we can start doing a couple of 0.9x releases before we hit
the grand 1.0 release.
Here is the typical setup for any release.
Everything is decided based on a public voting on the list. (only binding
votes are counted)
Pre Release
-------------------
1. Create a wiki page and start capturing the feature/bug fix list for the
release
2. We can start a discussion thread and then come to a concensus on the
final list
3. These items should be tracked by jira or other means (jira is preffered)
4. We can start a parallel thread on the release dates.
Release Process,
-------------------------
1. We should do a code freeze and put out a release candidate (ex RC1)
2. We should allow a minimum of one week for people to test/check out the RC
3. If there are major issues maybe do a RC2 and follow the same process
4. If a majority is happy then we can do a code freeze and cut out a
release.
For incubator projects, I believe the incubator PMC has to vote on a
release.
Cliff, Paul can you please confirm??
For the first release I will volunteer to cordinate it.
Comments are appreciated.
Regards,
Rajith
Re: Qpid Release Process
Posted by ma...@jpmorgan.com.
I think Robert's point is that we should generate a summary page from the
details in JIRA which will avoid re-typing/aging of the information.
Regards,
Marnie
Alan Conway <ac...@redhat.com>
18/09/2006 16:29
Please respond to qpid-dev
To: qpid-dev@incubator.apache.org
cc:
Subject: Re: Qpid Release Process
I've seen similar approaches. Jira is the way to capture the individual
bite-sized pieces of the release, but it's not great for representing
the larger goals. The wiki is good for that, and you can have links
either way where that's helpful.
(Disclaimer - haven't used Jira yet am assuming it's similar to other
bug tracking systems. Maybe it can do more than I think.)
On Mon, 2006-09-18 at 10:57 -0400, Rajith Attapattu wrote:
> Robert,
>
> The preffered way of capturing features (and of course bug fixes) is to
open
> a JIRA.
> But it also helps if we can have a page that list down the high level
> features list/ wish list so that people know where to go to get an idea
> about the current release.
>
> All details should be in JIRA, the wiki page is just a summary and a
> convinience where you see everything in one page.
>
> Comments are most welcomed
>
> Regards,
>
> Rajith
>
> On 9/17/06, Robert Greig <ro...@gmail.com> wrote:
> >
> > > I have create a release page in wiki
> > > http://wiki.apache.org/qpid/QpidReleasePage
> > > I have captured the release process and created a sample page for M1
> > > release.
> > >
> > > Please feel free to add/edit details and lets start planning for the
M1
> > > release (or whatever name we want to give it)
> >
> > Hi,
> >
> > I have just one question, relating to this point:
> >
> > "Create a wiki page and start capturing the feature/bug fix list for
> > the release"
> >
> > Can we use Jira's release notes generation for this rather than
> > maintaining a separate page? We can just provide a link to the Jira
> > release notes.
> >
> > Actually, do we have a Jira project yet?
> >
> > RG
> >
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
Re: Qpid Release Process
Posted by Alan Conway <ac...@redhat.com>.
I've seen similar approaches. Jira is the way to capture the individual
bite-sized pieces of the release, but it's not great for representing
the larger goals. The wiki is good for that, and you can have links
either way where that's helpful.
(Disclaimer - haven't used Jira yet am assuming it's similar to other
bug tracking systems. Maybe it can do more than I think.)
On Mon, 2006-09-18 at 10:57 -0400, Rajith Attapattu wrote:
> Robert,
>
> The preffered way of capturing features (and of course bug fixes) is to open
> a JIRA.
> But it also helps if we can have a page that list down the high level
> features list/ wish list so that people know where to go to get an idea
> about the current release.
>
> All details should be in JIRA, the wiki page is just a summary and a
> convinience where you see everything in one page.
>
> Comments are most welcomed
>
> Regards,
>
> Rajith
>
> On 9/17/06, Robert Greig <ro...@gmail.com> wrote:
> >
> > > I have create a release page in wiki
> > > http://wiki.apache.org/qpid/QpidReleasePage
> > > I have captured the release process and created a sample page for M1
> > > release.
> > >
> > > Please feel free to add/edit details and lets start planning for the M1
> > > release (or whatever name we want to give it)
> >
> > Hi,
> >
> > I have just one question, relating to this point:
> >
> > "Create a wiki page and start capturing the feature/bug fix list for
> > the release"
> >
> > Can we use Jira's release notes generation for this rather than
> > maintaining a separate page? We can just provide a link to the Jira
> > release notes.
> >
> > Actually, do we have a Jira project yet?
> >
> > RG
> >
Re: Qpid Release Process
Posted by Rajith Attapattu <ra...@gmail.com>.
Robert,
The preffered way of capturing features (and of course bug fixes) is to open
a JIRA.
But it also helps if we can have a page that list down the high level
features list/ wish list so that people know where to go to get an idea
about the current release.
All details should be in JIRA, the wiki page is just a summary and a
convinience where you see everything in one page.
Comments are most welcomed
Regards,
Rajith
On 9/17/06, Robert Greig <ro...@gmail.com> wrote:
>
> > I have create a release page in wiki
> > http://wiki.apache.org/qpid/QpidReleasePage
> > I have captured the release process and created a sample page for M1
> > release.
> >
> > Please feel free to add/edit details and lets start planning for the M1
> > release (or whatever name we want to give it)
>
> Hi,
>
> I have just one question, relating to this point:
>
> "Create a wiki page and start capturing the feature/bug fix list for
> the release"
>
> Can we use Jira's release notes generation for this rather than
> maintaining a separate page? We can just provide a link to the Jira
> release notes.
>
> Actually, do we have a Jira project yet?
>
> RG
>
Re: Qpid Release Process
Posted by Rajith Attapattu <ra...@gmail.com>.
Cliff,
Thanks a lot. Looking forward to your comments
Rajith
On 9/17/06, Cliff Schmidt <cl...@gmail.com> wrote:
>
> First of all, I know I was asked to respond to this thread about
> releases...I will catch up on the whole thread and offer any advice I
> can in the next 24 hours or so. I'm a little backlogged right now,
> but I wanted to let you all know Jira is up and that committers need
> to create accounts.
>
> See below for Jira info...
>
> On 9/17/06, Carl Trieloff <cc...@redhat.com> wrote:
> >
> > I believe the JIRA should be up soon, as soon as I see it is working I
> will
> > mail out the details.
>
> I created a Qpid Jira project with the typical notification and
> permission schemes: https://issues.apache.org/jira/browse/QPID.
>
> This also involved creating a qpid-developers group, but I only added
> people I knew would already have an account -- qpid committers who
> were already committers on other Apache projects.
>
> So, each new committer should go to
> https://issues.apache.org/jira/secure/Signup!default.jspa and create a
> jira account and email me with your username. I'll then add you to
> the qpid-developers group. The typical convention is to use your
> Apache id for your Jira username (that's how I was able to guess the
> Jira ids of the committers who already had apache accounts).
>
> Also, I tentatively made myself the "project lead", but it should
> really be a committer who is going to be very active in the project.
> So, who would like to volunteer to be the Jira person for this
> project? All qpid-developers really have all the permission they'd
> need with the scheme I set up, but I think the project lead might be
> able to do some admin stuff others can't do -- really not sure exactly
> what. So, I'll reassign this to whomever you all come up with. I
> don't think it's much of a big deal though.
>
> Cliff
>
Re: Qpid Release Process
Posted by Cliff Schmidt <cl...@gmail.com>.
First of all, I know I was asked to respond to this thread about
releases...I will catch up on the whole thread and offer any advice I
can in the next 24 hours or so. I'm a little backlogged right now,
but I wanted to let you all know Jira is up and that committers need
to create accounts.
See below for Jira info...
On 9/17/06, Carl Trieloff <cc...@redhat.com> wrote:
>
> I believe the JIRA should be up soon, as soon as I see it is working I will
> mail out the details.
I created a Qpid Jira project with the typical notification and
permission schemes: https://issues.apache.org/jira/browse/QPID.
This also involved creating a qpid-developers group, but I only added
people I knew would already have an account -- qpid committers who
were already committers on other Apache projects.
So, each new committer should go to
https://issues.apache.org/jira/secure/Signup!default.jspa and create a
jira account and email me with your username. I'll then add you to
the qpid-developers group. The typical convention is to use your
Apache id for your Jira username (that's how I was able to guess the
Jira ids of the committers who already had apache accounts).
Also, I tentatively made myself the "project lead", but it should
really be a committer who is going to be very active in the project.
So, who would like to volunteer to be the Jira person for this
project? All qpid-developers really have all the permission they'd
need with the scheme I set up, but I think the project lead might be
able to do some admin stuff others can't do -- really not sure exactly
what. So, I'll reassign this to whomever you all come up with. I
don't think it's much of a big deal though.
Cliff
Re: Qpid Release Process
Posted by Carl Trieloff <cc...@redhat.com>.
I believe the JIRA should be up soon, as soon as I see it is working I will
mail out the details.
Robert Greig wrote:
>> I have create a release page in wiki
>> http://wiki.apache.org/qpid/QpidReleasePage
>> I have captured the release process and created a sample page for M1
>> release.
>>
>> Please feel free to add/edit details and lets start planning for the M1
>> release (or whatever name we want to give it)
>
> Hi,
>
> I have just one question, relating to this point:
>
> "Create a wiki page and start capturing the feature/bug fix list for
> the release"
>
> Can we use Jira's release notes generation for this rather than
> maintaining a separate page? We can just provide a link to the Jira
> release notes.
>
> Actually, do we have a Jira project yet?
>
> RG
Re: Qpid Release Process
Posted by Robert Greig <ro...@gmail.com>.
> I have create a release page in wiki
> http://wiki.apache.org/qpid/QpidReleasePage
> I have captured the release process and created a sample page for M1
> release.
>
> Please feel free to add/edit details and lets start planning for the M1
> release (or whatever name we want to give it)
Hi,
I have just one question, relating to this point:
"Create a wiki page and start capturing the feature/bug fix list for
the release"
Can we use Jira's release notes generation for this rather than
maintaining a separate page? We can just provide a link to the Jira
release notes.
Actually, do we have a Jira project yet?
RG
Re: Qpid Release Process
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi All,
Before do a release lets try to get ourselves with the guidelines provided
in the following urls.
[Borrowed from the tuscany mailing list]
http://incubator.apache.org/incubation/Incubation_Policy.html
http://incubator.apache.org/guides/releasemanagement.html
http://incubator.apache.org/guides/sites.html
Regards,
Rajith
On 9/17/06, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Hi All,
>
> I have create a release page in wiki
> http://wiki.apache.org/qpid/QpidReleasePage
> I have captured the release process and created a sample page for M1
> release.
>
> Please feel free to add/edit details and lets start planning for the M1
> release (or whatever name we want to give it)
>
> Regards,
>
> Rajith
>
Re: Qpid Release Process
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi All,
I have create a release page in wiki
http://wiki.apache.org/qpid/QpidReleasePage
I have captured the release process and created a sample page for M1
release.
Please feel free to add/edit details and lets start planning for the M1
release (or whatever name we want to give it)
Regards,
Rajith
Re: Qpid Release Process
Posted by Carl Trieloff <cc...@redhat.com>.
That would be great, as soon as rajith has the release page on the wiki
let's outline what we need to
do to create a release the. I am keen to get a baseline release out so
that we have all walked through the
process, and have an easy way for others to work with us. (will the good
to learn the incubator ropes also)
Carl.
Bozhong Lin wrote:
> Hi All,
>
> I am currently doing distribution/packaging setup work for CeltiXfire
> project, and make it to meeting Apache release requirement. If there
> is anything that I can help for Qpid in this area, I would be glad to
> do it. Where can I found this kind of task?
>
> Cheers,
> Bo
>
> Carl Trieloff wrote:
>>
>> Rajith,
>>
>> This looks like the place to start - are you going to put this up on
>> the wiki and create a page that
>> we can create the work into. I suggest that this be phase one, and
>> then sorting those into milestone
>> releases will be based on sign-up / discussion.
>>
>> Carl.
>>
>> Rajith Attapattu wrote:
>>> Hi Folks,
>>>
>>> I think, this is a good time for us to discuss and agree on a release
>>> mechanism that's agreeable to the Apache way.
>>> As per my observations from projects like Axis2, Synapse, Tuscany,
>>> Geronimo
>>> ...etc the release process is as follows.
>>>
>>> We start with milestone releases (M1, M2 ...Mx) until we graduate
>>> from the
>>> incubator.
>>> Once graduated we can start doing a couple of 0.9x releases before
>>> we hit
>>> the grand 1.0 release.
>>>
>>> Here is the typical setup for any release.
>>> Everything is decided based on a public voting on the list. (only
>>> binding
>>> votes are counted)
>>>
>>> Pre Release
>>> -------------------
>>> 1. Create a wiki page and start capturing the feature/bug fix list
>>> for the
>>> release
>>> 2. We can start a discussion thread and then come to a concensus on the
>>> final list
>>> 3. These items should be tracked by jira or other means (jira is
>>> preffered)
>>> 4. We can start a parallel thread on the release dates.
>>>
>>> Release Process,
>>> -------------------------
>>> 1. We should do a code freeze and put out a release candidate (ex RC1)
>>> 2. We should allow a minimum of one week for people to test/check
>>> out the RC
>>> 3. If there are major issues maybe do a RC2 and follow the same process
>>> 4. If a majority is happy then we can do a code freeze and cut out a
>>> release.
>>>
>>> For incubator projects, I believe the incubator PMC has to vote on a
>>> release.
>>> Cliff, Paul can you please confirm??
>>>
>>> For the first release I will volunteer to cordinate it.
>>> Comments are appreciated.
>>>
>>> Regards,
>>> Rajith
>>>
>>
Re: Qpid Release Process
Posted by Bozhong Lin <bl...@iona.com>.
Hi All,
I am currently doing distribution/packaging setup work for CeltiXfire
project, and make it to meeting Apache release requirement. If there is
anything that I can help for Qpid in this area, I would be glad to do
it. Where can I found this kind of task?
Cheers,
Bo
Carl Trieloff wrote:
>
> Rajith,
>
> This looks like the place to start - are you going to put this up on the
> wiki and create a page that
> we can create the work into. I suggest that this be phase one, and then
> sorting those into milestone
> releases will be based on sign-up / discussion.
>
> Carl.
>
> Rajith Attapattu wrote:
>> Hi Folks,
>>
>> I think, this is a good time for us to discuss and agree on a release
>> mechanism that's agreeable to the Apache way.
>> As per my observations from projects like Axis2, Synapse, Tuscany,
>> Geronimo
>> ...etc the release process is as follows.
>>
>> We start with milestone releases (M1, M2 ...Mx) until we graduate from
>> the
>> incubator.
>> Once graduated we can start doing a couple of 0.9x releases before we hit
>> the grand 1.0 release.
>>
>> Here is the typical setup for any release.
>> Everything is decided based on a public voting on the list. (only binding
>> votes are counted)
>>
>> Pre Release
>> -------------------
>> 1. Create a wiki page and start capturing the feature/bug fix list for
>> the
>> release
>> 2. We can start a discussion thread and then come to a concensus on the
>> final list
>> 3. These items should be tracked by jira or other means (jira is
>> preffered)
>> 4. We can start a parallel thread on the release dates.
>>
>> Release Process,
>> -------------------------
>> 1. We should do a code freeze and put out a release candidate (ex RC1)
>> 2. We should allow a minimum of one week for people to test/check out
>> the RC
>> 3. If there are major issues maybe do a RC2 and follow the same process
>> 4. If a majority is happy then we can do a code freeze and cut out a
>> release.
>>
>> For incubator projects, I believe the incubator PMC has to vote on a
>> release.
>> Cliff, Paul can you please confirm??
>>
>> For the first release I will volunteer to cordinate it.
>> Comments are appreciated.
>>
>> Regards,
>> Rajith
>>
>
Re: Qpid Release Process
Posted by Carl Trieloff <cc...@redhat.com>.
Rajith,
This looks like the place to start - are you going to put this up on the
wiki and create a page that
we can create the work into. I suggest that this be phase one, and then
sorting those into milestone
releases will be based on sign-up / discussion.
Carl.
Rajith Attapattu wrote:
> Hi Folks,
>
> I think, this is a good time for us to discuss and agree on a release
> mechanism that's agreeable to the Apache way.
> As per my observations from projects like Axis2, Synapse, Tuscany,
> Geronimo
> ...etc the release process is as follows.
>
> We start with milestone releases (M1, M2 ...Mx) until we graduate from
> the
> incubator.
> Once graduated we can start doing a couple of 0.9x releases before we hit
> the grand 1.0 release.
>
> Here is the typical setup for any release.
> Everything is decided based on a public voting on the list. (only binding
> votes are counted)
>
> Pre Release
> -------------------
> 1. Create a wiki page and start capturing the feature/bug fix list for
> the
> release
> 2. We can start a discussion thread and then come to a concensus on the
> final list
> 3. These items should be tracked by jira or other means (jira is
> preffered)
> 4. We can start a parallel thread on the release dates.
>
> Release Process,
> -------------------------
> 1. We should do a code freeze and put out a release candidate (ex RC1)
> 2. We should allow a minimum of one week for people to test/check out
> the RC
> 3. If there are major issues maybe do a RC2 and follow the same process
> 4. If a majority is happy then we can do a code freeze and cut out a
> release.
>
> For incubator projects, I believe the incubator PMC has to vote on a
> release.
> Cliff, Paul can you please confirm??
>
> For the first release I will volunteer to cordinate it.
> Comments are appreciated.
>
> Regards,
> Rajith
>
Re: Qpid Release Process
Posted by Rajith Attapattu <ra...@gmail.com>.
Thanks marnie,
I am going to create a wiki page to capture the release process and the
requirments.
Once I do it, can u create a wiki page with the below mentioned points and
link it to the main page.
I will ping as soon as I create the page.
Regards,
Rajith
On 9/15/06, marnie.mccormack@jpmorgan.com <ma...@jpmorgan.com>
wrote:
>
> Hi,
>
> It'd be good to agree how we go about testing RCs. I've seen quite a few
> cross-platform issues as I've used builds each week, mainly trivial but
> still embarassing, so I'd like to see clarity around quality gates on
> various envs.
>
> First, we need to agree the set of platforms/envs we're supporting - I'll
> start by offering the following for discussion:
>
> - Linux 2.6+
> - Windows XP 5+
> - Solaris 8 (SunOS 5.8)+
> - Cygwin ?
>
> This list needs to be expanded/debated :-)
>
> I guess we ought to plan an initial release early doors to encourage early
> adpoter feedback ?
>
> Regards,
> Marnie
>
>
>
>
>
>
> "Rajith Attapattu" <ra...@gmail.com>
> 12/09/2006 16:50
> Please respond to qpid-dev
>
> To: qpid-dev@incubator.apache.org
> cc:
> Subject: Qpid Release Process
>
>
> Hi Folks,
>
> I think, this is a good time for us to discuss and agree on a release
> mechanism that's agreeable to the Apache way.
> As per my observations from projects like Axis2, Synapse, Tuscany,
> Geronimo
> ...etc the release process is as follows.
>
> We start with milestone releases (M1, M2 ...Mx) until we graduate from the
> incubator.
> Once graduated we can start doing a couple of 0.9x releases before we hit
> the grand 1.0 release.
>
> Here is the typical setup for any release.
> Everything is decided based on a public voting on the list. (only binding
> votes are counted)
>
> Pre Release
> -------------------
> 1. Create a wiki page and start capturing the feature/bug fix list for the
> release
> 2. We can start a discussion thread and then come to a concensus on the
> final list
> 3. These items should be tracked by jira or other means (jira is
> preffered)
> 4. We can start a parallel thread on the release dates.
>
> Release Process,
> -------------------------
> 1. We should do a code freeze and put out a release candidate (ex RC1)
> 2. We should allow a minimum of one week for people to test/check out the
> RC
> 3. If there are major issues maybe do a RC2 and follow the same process
> 4. If a majority is happy then we can do a code freeze and cut out a
> release.
>
> For incubator projects, I believe the incubator PMC has to vote on a
> release.
> Cliff, Paul can you please confirm??
>
> For the first release I will volunteer to cordinate it.
> Comments are appreciated.
>
> Regards,
> Rajith
>
>
>
> This communication is for informational purposes only. It is not intended
> as an offer or solicitation for the purchase or sale of any financial
> instrument or as an official confirmation of any transaction. All market
> prices, data and other information are not warranted as to completeness or
> accuracy and are subject to change without notice. Any comments or
> statements made herein do not necessarily reflect those of JPMorgan Chase &
> Co., its subsidiaries and affiliates.
>
> This transmission may contain information that is privileged,
> confidential, legally privileged, and/or exempt from disclosure under
> applicable law. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution, or use of the
> information contained herein (including any reliance thereon) is STRICTLY
> PROHIBITED. Although this transmission and any attachments are believed to
> be free of any virus or other defect that might affect any computer system
> into which it is received and opened, it is the responsibility of the
> recipient to ensure that it is virus free and no responsibility is accepted
> by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for
> any loss or damage arising in any way from its use. If you received this
> transmission in error, please immediately contact the sender and destroy the
> material in its entirety, whether in electronic or hard copy format. Thank
> you.
>
>
Re: Qpid Release Process
Posted by ma...@jpmorgan.com.
Hi,
It'd be good to agree how we go about testing RCs. I've seen quite a few
cross-platform issues as I've used builds each week, mainly trivial but
still embarassing, so I'd like to see clarity around quality gates on
various envs.
First, we need to agree the set of platforms/envs we're supporting - I'll
start by offering the following for discussion:
- Linux 2.6+
- Windows XP 5+
- Solaris 8 (SunOS 5.8)+
- Cygwin ?
This list needs to be expanded/debated :-)
I guess we ought to plan an initial release early doors to encourage early
adpoter feedback ?
Regards,
Marnie
"Rajith Attapattu" <ra...@gmail.com>
12/09/2006 16:50
Please respond to qpid-dev
To: qpid-dev@incubator.apache.org
cc:
Subject: Qpid Release Process
Hi Folks,
I think, this is a good time for us to discuss and agree on a release
mechanism that's agreeable to the Apache way.
As per my observations from projects like Axis2, Synapse, Tuscany,
Geronimo
...etc the release process is as follows.
We start with milestone releases (M1, M2 ...Mx) until we graduate from the
incubator.
Once graduated we can start doing a couple of 0.9x releases before we hit
the grand 1.0 release.
Here is the typical setup for any release.
Everything is decided based on a public voting on the list. (only binding
votes are counted)
Pre Release
-------------------
1. Create a wiki page and start capturing the feature/bug fix list for the
release
2. We can start a discussion thread and then come to a concensus on the
final list
3. These items should be tracked by jira or other means (jira is
preffered)
4. We can start a parallel thread on the release dates.
Release Process,
-------------------------
1. We should do a code freeze and put out a release candidate (ex RC1)
2. We should allow a minimum of one week for people to test/check out the
RC
3. If there are major issues maybe do a RC2 and follow the same process
4. If a majority is happy then we can do a code freeze and cut out a
release.
For incubator projects, I believe the incubator PMC has to vote on a
release.
Cliff, Paul can you please confirm??
For the first release I will volunteer to cordinate it.
Comments are appreciated.
Regards,
Rajith
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.