[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Indexer conf call?
|
I'm not totally sure what you guys are talking about. If you are talking
about the DAO thing, I don't consider that an API of the CDT. In fact I'd
rather people not know about it. It is a hack to allow the IBM to tear apart
the CDT at their whim while adding complexity to an already too complex
architecture. No one else will benefit from it. Did I mention I really don't
like this thing? ;) Until someone shows me the real costs, I will continue
to believe that indexing locally and accessing the files over the wire is
the correct architecture, especially now that the CDT never parses an
unchanged file more than once.
So as such, the DAO interface can be changed whenever.
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Chris Recoskie
> Sent: Thursday, March 15, 2007 4:08 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Indexer conf call?
>
> Hi Andrew,
>
> I'm not sure if you mean whether we (IBM) have slack in terms of our
> schedule for getting the items in before the freeze, or if you mean
> whether
> we have slack as to what release of CDT they would go in.
>
> I'll try to answer both questions.
>
> If (big if...) we were going to move all the clients to the DAO model
> (call
> hierarchy, type hierarchy, search, etc.), our internal schedule says we
> would be done this in early to mid April (I can break this down in detail
> if anyone is interested). If the work only has to make the feature freeze
> then there is a couple of weeks of slack. We didn't get consensus yet
> that
> everyone has a warm fuzzy feeling about migrating all the clients though.
> For those clients that have already a good separation of UI and back end
> such as the call hierarchy and type hierarchy this would be a relatively
> simple process, but for other clients it might or might not take more work
> to factor out the back end. For our part we are very concerned with
> making
> sure that quality is maintained and we've been rigorously running the UI
> tests to make sure we haven't been breaking anything.
>
> In terms of CDT releases, that probably bears some discussion and
> clarification...
>
> Markus was concerned about making it for API freeze... I guess the
> questions we need to answer are what are our (as in CDT's) APIs going to
> be
> and are we actually prepared to freeze them in two weeks given that
> feature
> work is ongoing up until April 30th. Some things are obviously going to
> be
> API (IIndex and the like, new project model stuff, etc.) but in terms of
> the back end to the views and other index based services it's not very
> clear to me what is going to be API and what isn't.
>
> What is API and what is not has a lot of ramifications...
>
> - What are we freezing for API freeze? Are we in fact freezing at M6?
> Personally I'm not sure it's practical to freeze API prior to feature work
> being done unless the system is very mature (i.e., if you are the Eclipse
> Platform and are not implementing a huge amount of features in this
> release you have a much easier time of freezing API ahead of your feature
> delivery than we do). That's just my $0.02 CDN though...
>
> - What can and cannot be put in between M6 and the feature freeze?
>
> - What can and cannot be done in CDT 4.1 that doesn't make it into CDT
> 4.0?
> In a 4.1 we can add new API but can't break existing API. To break
> existing API we'd need a CDT 5.0, which would be a year from now.
>
> In terms of our own desires at IBM, a year is a long time to wait because
> it doesn't line up well with our product release cycle (it already takes
> almost a year for us to deploy products based on CDT, so it would be
> basically two years before anything consuming our proposed functionality
> would see the light of day if we had to wait until CDT 5.0 to get the
> changes in). It likely suits our purposes well enough if we can get
> something done this year, and we are not entirely picky about which
> release
> that would be so long as the changes happen and we are not restricted by
> the versioning rules.
>
> What are people's thoughts on the API issues?
>
> ===========================
>
> Chris Recoskie
> Team Lead, IBM CDT Team
> IBM Toronto
> http://www.eclipse.org/cdt
>
>
>
>
> From: Andrew.Ferguson@xxxxxxxxxxx
>
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>
> Date: 15/03/2007 03:06 PM
>
> Subject Re: [cdt-dev] Indexer conf call?
> :
>
>
>
>
>
>
> hi,
>
> I've posted minutes for the meeting here:
> http://wiki.eclipse.org/index.php/CDT/calls/IndexingMar2007_1
> if I've missed anything then please add it in.
>
> We ran out of time at the end, just as we were discussing the scale of
> changes proposed. My next
> question was going to be if you have any slack in terms of whether these
> changes make CDT 4.0?
>
> thanks,
> Andrew
>
>
>
>
>
> **********************************************************************
> Symbian Software Ltd is a company registered in England and Wales with
> registered number 4190020 and registered office at 2-6 Boundary Row,
> Southwark, London, SE1 8HP, UK. This message is intended only for use by
> the named addressee and may contain privileged and/or confidential
> information. If you are not the named addressee you should not
> disseminate,
> copy or take any action in reliance on it. If you have received this
> message in error please notify postmaster@xxxxxxxxxxx and delete the
> message and any attachments accompanying it immediately. Neither Symbian
> nor any of its Affiliates accepts liability for any corruption,
> interception, amendment, tampering or viruses occurring to this message in
> transit or for any message sent by its employees which is not in
> compliance
> with Symbian corporate policy.
> **********************************************************************
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
