+1 also. I think thats the best possible solution given the constraints. regards, -Chris
From: Matthew Hall <[email protected]> To: Nebula Dev <[email protected]> Date: 04/29/2009 11:42 AM Subject: Re: [nebula-dev] On the state and future of Nebula - Part 2 +1 to the hybrid approach (L1 for stable projects and L2 for incubation projects). Matthew Tom Schindl wrote: > Hi Nebula-Community, > > This is the next part in my series on "The state and future for Nebula". > The last mail was "It's all about the mission" and we came up with a new > mission statement but only changing our mission is not enough because > the changing the mission implies the project structure also changes. > > So this mail can be summerized with "It's all about project structure > and release". > > There are 3 different possibilities to address the problem that we can't > release stuff to the public make our mission statement reality: > > * Every widget has is its own eclipse project (L1) > > Nebula-Project > + PShelf-Project (Stable - release 1.0) > + Gallery-Project (Stable - release 1.1) > + ... > + MyComponent-Project (stable release 2.0) > + MyComponent2-Project (Incubation - no release) > > * We split nebula in 2 Projects (L2) > > Nebula-Project (Stable - release 1.0) > + PShelf > + Gallery > + MyComponent > + ... > + Nebula-Incubator-Project > + MyComponent2 > > > Both layouts have features and draw backs and we need to take a look at > them in more detail: > > L1: > - Administrative-Overhead for Widget-Creator is high > - Administrative-Overhead for Eclipse-Foundation and Webmasters > - High burden to bring in new widgets > + Release flexibility for the widget owner > > L2: > + No Administrative-Overhead for Widget-Creator > + No Administrative-Overhead for Eclipse-Foundation and Webmasters > - No individual releases by the widget owner > > Both layouts don't play well with our mission because if we want Eclipse > Projects move their reuseable code to Nebula (like e.g. XViewer) they > might have the need of individual releases and might decide to keep the > code private to their project (On EclipseCon I talked with people from > NatTable and this was something they would have a problem with). > > So in the last days I thought about those things and came up with the > following project structure: > > Nebula-Project > + PShelf-Project (Stable - release 1.0) > + Gallery-Project (Stable - release 1.1) > + ... > + MyComponent-Project (Stable release 2.0) > + Nebula-Incubator-Project > + MyComponent2 > > Additionally I'd like to define a Nebula-Release-Train just like we have > an Eclipse Release Train on the top-level project structure where we > provide a concerted release of all Nebula-Widgets, an Update-Site, ... . > > We need to ask our PMC of course whether the above layout is supported > by the Eclipse-Project rules or not but to me looks like it is. > > Looking at the +/- for this layout we have: > / Medium Administrative-Overhead for Widget-Creator > / Medium Administrative-Overhead for Eclipse-Foundation > + Low burden to bring in new widget ideas and follow parallel ip > + Release flexibility for the widget owner > + Concerted release of widgets through the Nebula-Release-Train > involving adversiment, ... . > > And there's one more nice side-effect. Up-grading from Incubator gives > the community a chance to review the project, source code, ... and give > feedback through the default channels because up-grading involves a > project proposal (To make this as painless as possible we should provide > a template proposal widget-owners can use and simply drop in their > widget-description, ...). > > So now it's once more your turn Nebula-Developers and widget owners > (soon you can add the title project lead to your mail signature :-). > > What do you think? I leave this topic once more open for the next weeks > and hope that we come to a decision until then. > > Thanks for reading through this once more long mail and your feedback. > > Tom > _______________________________________________ > nebula-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/nebula-dev > > _______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
