RE: [cdt-dev] Thoughts on the CDT - CVS repository

[Sebastien Marineau <sebastien@xxxxxxx>]

> 
> Sounds like a good plan.  I'm really just looking for a place 
> to start up 
> new contributions which may or may not end up in the base 
> feature set of 
> the CDT (just like CPPUnit).  We still need to send all requests go 
> through you for approval.  But when that approval is 
> received, it should 
> be a simple matter to get things setup.

So now the next question is whether we can change our plugin/project
layout to have the additional directory structure. I will have to
discuss with JohnD (I believe he's on vacation this week), as this
may be counter to the Eclipse charter :-)

In any case, stay tuned -- I'd much prefer to have a hierarchical layout,
and any "upheaval" of our CVS directory structure would also be a good
opportunity
for the feature plugin cleanup Dave/Doug have suggested.

> 
> As for the JDT, it doesn't need to deal with host specific pieces, 
> different toolchains, different build systems, etc.  It has it's own 
> toolchain and build system and that makes life easy.  I'd 
> love to have a 
> core set of features that are complete and common to all CDT users 
> everywhere.  But I think we'll have some growing pains for a 
> while before 
> we get there.  As long as the community is putting the CDT 
> into products 
> they will have concerns about the maturity level of the 
> various parts and 
> will want to mitigate risk.

Yes, I agree. However, I think we also have to balance the "modularity" 
through multiple plugins (which may be omitted by various vendors), 
with a consistent set of unified core APIs; this is critical to
allowing integrations with CDT to work seamlessly with different vendors.

One example is the build -- if we move the managed build functionality out
of the core plugin, we should still have all of the build integration APIs
defined in cdt.core (with the managed build plugin being an implementor
of those interfaces), e.g. the interfaces are defined in cdt.core. 
This way, all tools still integrate with a unified set of APIs in cdt.core.

In any case, we'll figure out the right balance :-)

Thanks,

Sebastien
> 
> Thanks, Sebastien,
> Doug Schaefer, Senior Software Developer
> IBM Rational Software, Ottawa, Ontario, Canada
> 
> 
> 
> Sebastien Marineau <sebastien@xxxxxxx> 
> Sent by: cdt-dev-admin@xxxxxxxxxxx
> 06/26/2003 11:47 AM
> Please respond to
> cdt-dev@xxxxxxxxxxx
> 
> 
> To
> "'cdt-dev@xxxxxxxxxxx'" <cdt-dev@xxxxxxxxxxx>
> cc
> John Duimovich/Ottawa/IBM@IBMCA
> Subject
> RE: [cdt-dev] Thoughts on the CDT - CVS repository
> 
> 
> 
> 
> 
> 
> Comment below...
> 
> > Hey gang,
> > 
> > I thought I would throw this out there and see what people 
> > think.  We've 
> > had a request to move the managed build work into a separate 
> > plugin/feature so that people incorporating the CDT into 
> > their products 
> > can chose not to include it.  There has also been some 
> > discussion on a 
> > win32 debugger integration and then I have my automated 
> nightly build 
> > stuff that should probably go into source control as well. 
> > And then, I'm 
> > sure there are many other contributed projects that could get 
> > started. So, 
> > in the end, I don't see any way out of the scenario where 
> > we're just going 
> > to have a lot of projects in CVS to keep our momentum and 
> feature set 
> > growing.  And that's not even mentioning the change log 
> > scripts we'd like 
> > to get running on our projects.
> > 
> > My main concern is that it feels to me that the process to 
> get these 
> > projects set up and maintained is so cumbersome that I am 
> > weary to even 
> > start the process.  Maybe it's just my perception but, having 
> > maintained 
> > CVS servers locally, I know that requests that are taking 
> > days or weeks 
> > and several round trips to get the information right could 
> be done in 
> > minutes with the right permissions set on the server.  I 
> > realize that we 
> > need the right set of PMC approvals to put things up there, 
> > especially 
> > with newly emphasized requirements for due diligence, but I'm 
> > not sure 
> > that's really the bottleneck at this time, and Sebastien can 
> > confirm this.
> > 
> > So, I was thinking of possible alternatives, some of them 
> > crazy, but here 
> > they are:
> > - move the cdt project into it's own CVS repository on 
> > eclipse.org and 
> > allow a certain set of committers to add/change projects, 
> > upon approval of 
> > the PMC, of course.
> > - move the cdt project to an entirely different server (like 
> > sourceforge) 
> > - this is the wacky one BTW.
> > - allow a certain set of committers to fire in commands to 
> > the eclipse.org 
> > CVS maintainers to make sure things get set up timely and 
> > correctly, again 
> > with PMC approvals.
> > 
> > Any thoughts?  And I don't mind people calling me a whiner 
> about this.
> 
> Quick comments--
> 
> - I don't think the sourceforge proposal will fly :-)
> - Another alternative is to set up a slightly deeper hierarchy in CVS,
> which could also ease the navigation of the CVS repository (the large 
> number
> of plugins is somewhat scary for people when you first look 
> at it). We 
> could
> achieve this by creating some top-level directories, and putting the 
> plugins
> below, e.g.:
> 
> cdt-core
>  -> org.eclipse.cdt.core
>  -> org.eclipse.cdt.ui
>  -> org.eclipse.cdt.build
>  -> org.eclipse.cdt.core.tests
> ...
> cdt-debug
>  -> org.eclipse.cdt.debug.core
> ...
> cdt-contrib
>  -> org.eclipse.cdt.cppunit.core
>  -> org.eclipse.cdt.whizbang
> ...
> 
> This would make the CDT cvs repository easier to nagivate, 
> and would allow
> the commiters to create new plugins. However, for this work, 
> we would have
> to all commit
> to being very disciplined in creating new plugins.
> 
> - The last point I want to re-inforce is that we should try to be as 
> frugal
> when 
> creating new plugins. We really need good reasons to justify 
> a new plugin,
> as opposed
> to extending one of the current ones. It's interesting to 
> note that JDT,
> which has
> a lot more code than we do, only has a total of 10 plugins 
> (including the
> launching,
> source code and docs). 
> 
> For the build system, for example, we might consider having
> options or overrides that let an ISV or user disable it, but without 
> having
> to split
> it into a separate plugin. Since we're trying to create a common CDT
> foundation, we do
> not want to end up in a situation where different companies 
> are shipping
> compatible
> versions of the CDT, but with each removing different parts 
> (plugins) from
> the standard
> CDT -- that would be counter to the whole "plug and play" objective.
> 
> 
> Sebastien
> 
> > 
> > Cheers,
> > Doug Schaefer, Senior Software Developer
> > IBM Rational Software, Ottawa, Ontario, Canada
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>