Ewan,

First, thanks for stepping up to help organize everyone around the
release process.  We have all agreed that getting to a "legal" release
is the priority, and we also agreed to target a time-bound release
model.  It's a thank-less job sometimes to be the one to "crack the
wip".  It was needed.  Perhaps we need to look at how to rotate that
around the community for future releases, so that everybody gets a
chance to take some of that heat... ;-)

On the tactical topic of the AWS API's for our first release, I think
we need to compromise a bit here.  If Prachi can get everything
working without the WSDL files being in the source tree, then that
would be sufficient to achieve our primary objective for the release.
Due to the noted concerns about the current quality of the query API,
my personal opinion would be to release with the SOAP API intact.  If
we run into issues making it work without the WSDL's, we'll need an
alternative strategy to deal with the licensing / copyright issue for
those files.

Strategically, I would like to second Chiradeep's proposal that we aim
to convert from SOAP to Query.  That will require testing effort, but
I believe it's the right move long term.  Assuming the WSDL's can be
removed cleanly, this deprecation step would be in a future release.
However, I would strongly suggest that we include a notice in the 4.0
release notes that expresses our aim to convert from SOAP to Query.
This, of course, assumes that nobody strongly disagrees with that
strategy.

To summarize, can we agree on the following?

1 - Prachi will update the list with his findings (attempting to
remove the WSDL files).
2 - If Prachi is able to get it working, we release WITH the SOAP API
intact, but with a notice of planned deprecation.
3 - If Prachi is not able to get it working, then we remove the SOAP
API for this release, and do some of the basic testing required to
assess quality for the Query API.  This would allow us to make an
informed decision about how to handle the situation.

-chip

On Thu, Aug 2, 2012 at 12:41 PM, Ewan Mellor <ewan.mel...@eu.citrix.com> wrote:
> No, it's not my decision to make alone.  This group has asked for time-based 
> releases, so that's what I'm doing.  If people decide that they don't want 
> time-based releases after all, then we can start again with a new release 
> plan.
>
> That's not what people have asked for though.  We've asked the question 
> multiple times, and every time the answer comes back -- ship as soon as you 
> can.  We haven't shipped an Apache release for four months (it will be five 
> months on the current release plan) and we're already seeing articles saying 
> that you shouldn't use Apache releases because they are crippled compared 
> with Citrix's.
>
> Like I say, this isn't my decision.  I'm just cracking the whip to make sure 
> people actually get what they're asking for.  If the group decides that it 
> wants to slip to October or beyond, then that's a decision that's open to 
> them.
>
> Ewan.
>
>
>
>> -----Original Message-----
>> From: fernc...@gmail.com [mailto:fernc...@gmail.com] On Behalf Of
>> Adrian Cole
>> Sent: 02 August 2012 09:14
>> To: cloudstack-dev@incubator.apache.org
>> Cc: Prachi Damle
>> Subject: Re: ec2 API compatibility (WSDL vs Query)
>>
>> Well, if this is your decision to make alone, then I guess we'll have to 
>> either
>> convince you or deal with your decision.
>>
>> -A
>>
>> On Thu, Aug 2, 2012 at 9:06 AM, Ewan Mellor
>> <ewan.mel...@eu.citrix.com>wrote:
>>
>> > The problem is that "not well tested" is likely to be code for
>> > "doesn't work and has never worked".  If someone can convince me that
>> > it will be working in the next 2 weeks (1 week of open development, 1
>> > week stability and bugfixing) then I'm happy to take that step and
>> > remove the SOAP API and declare 4.0 to be Query API only.  If it can't
>> > be done in the next two weeks then we're talking about slipping the
>> release, and no-one wants that.
>> >
>> > Ewan.
>> >
>> > > -----Original Message-----
>> > > From: Chip Childers [mailto:chip.child...@sungard.com]
>> > > Sent: 02 August 2012 08:37
>> > > To: cloudstack-dev@incubator.apache.org
>> > > Cc: Prachi Damle
>> > > Subject: Re: ec2 API compatibility (WSDL vs Query)
>> > >
>> > > From Chiradeep's note:
>> > >
>> > > > Currently the EC2 API layer implements both the WSDL interface as
>> > > > well as the Query API.
>> > > > However the Query API is not well tested.
>> > >
>> > > So removing the SOAP interface would leave us with the query API...
>> > > which would then need testing.
>> > >
>> > > Am I misunderstanding?
>> > >
>> > > -chip
>> > >
>> > > On Thu, Aug 2, 2012 at 11:33 AM, Ewan Mellor
>> > > <ewan.mel...@eu.citrix.com>
>> > > wrote:
>> > > >> -----Original Message-----
>> > > >> From: Chip Childers [mailto:chip.child...@sungard.com]
>> > > >> Sent: 02 August 2012 07:58
>> > > >> To: cloudstack-dev@incubator.apache.org
>> > > >> Subject: Re: ec2 API compatibility (WSDL vs Query)
>> > > >>
>> > > >> On Thu, Aug 2, 2012 at 10:56 AM, Adrian Cole
>> > > >> <adrian.f.c...@gmail.com>
>> > > >> wrote:
>> > > >> > Just curious.
>> > > >> >
>> > > >> > If this is the first apache release, and cloudbridge was
>> > > >> > formerly in a different repo, why don't we just rip out the SOAP
>> interface?
>> > > >> > That's a heck of a lot simpler than deprecating the first
>> > > >> > version of
>> > > something.
>> > > >> >
>> > > >> > -A
>> > > >>
>> > > >> I think we are saying the same thing.  In this case, deprecate =
>> > > >> rip
>> > it out.
>> > > >
>> > > > Are we saying that?  We've got 6 working days of general
>> > > > development
>> > > time before we start locking down for a release.  Can we get the
>> > > query
>> > API
>> > > implemented in that time?
>> > > >
>> > > > Regarding the specific licensing issue, Prachi is looking at what
>> > happens
>> > > when we remove the WSDLs.  The server stubs are already in the code
>> > > base, so in theory we shouldn't need the WSDLs to be present anyway.
>> > > Prachi is looking at whether that's true.
>> > >
>> > > >
>> > > > Ewan.
>> > > >
>> > > >
>> >
>

Reply via email to