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

[Sebastien Marineau <sebastien@xxxxxxx>]

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
>