RE: [cdt-dev] logistices for the EFS work

[Doug Schaefer <DSchaefer@xxxxxxx>]

BTW, I got great feedback from people at ESE on the Add File/Exclude File
feature I've proposed. EFS support will be critical for that (although Dave
Inglis has found a way we can cheat :).

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 Doug Schaefer
> Sent: Monday, October 15, 2007 11:05 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] logistices for the EFS work
> 
> I'd vote for (a). I fear dropping all the changes in at once since there
> will be a period where things won't work at all (remember the new project
> model :). At least this way, we can put a priority on fixing the bugs
> before
> continuing incremental work.
> 
> 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: Monday, October 15, 2007 10:57 AM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: [cdt-dev] logistices for the EFS work
> >
> >
> > Hello everyone,
> >
> > Greg and I are at the point where we want to start making changes to the
> > code as we implement EFS support in CDT.  This is a large task which
> will
> > take a while to complete, and will have direct implications on APIs
> people
> > are using.
> >
> > As such, we want to get feedback from everyone as to how to handle
> putting
> > the changes in.  We can:
> >
> > a)  Make incremental checkins as we go on HEAD.  Pros:  everyone can
> adapt
> > to API changes incrementally.  People can collaborate more easily on the
> > new changes.  Cons:  EFS support will trickle in, and will not
> necessarily
> > provide a complete or functional solution until we are done.  Things are
> > apt to be broken frequently.
> >
> > b) Work for months until we think we're done, then do one gigantic
> checkin
> > once things are "working."  Pros:  nothing changes until stuff works.
> > Cons:  It's very hard for everyone to react to the new APIs and
> > functionality.  People may modify the same code we're trying to modify,
> > which will making staying in sync difficult.
> >
> > c)  Work on a branch in the CDT, then merge it back to HEAD when we're
> > done.  Pros:  Nothing changes until stuff works.  Cons:  CVS merge tools
> > suck.  Also, no one is forced to look at the changes because most people
> > will work on HEAD and not our branch.  Staying in sync is still a
> problem.
> >
> > We are leaning towards doing a).  Does anyone have any concerns with
> this
> > before we start doing anything?
> >
> > ===========================
> >
> > Chris Recoskie
> > Team Lead, IBM CDT Team
> > IBM Toronto
> > http://www.eclipse.org/cdt
> >
> > _______________________________________________
> > 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