Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [nebula-dev] On the state and future of Nebula - Part 2

+1 also.  I think thats the best possible solution given the constraints.

regards,
-Chris


From: Matthew Hall <matthall@xxxxxxxxxxxxxxxxx>
To: Nebula Dev <nebula-dev@xxxxxxxxxxx>
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
> nebula-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/nebula-dev
>
>  

_______________________________________________
nebula-dev mailing list
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev



Back to the top