So, I agree let's focus on revamping the widget catalog as a first step. Let me know if you need any help with this.
As for the project organization, I'm not going to push hard to change this if you're happy with it, I just wanted to point out the tradeoff that is being made there. Basically we are opting for ease of ingesting a widget into Nebula at the expense of effectively maintaining it. This is not so much of an issue if there is no real activity for the widget, but if you do, then your build status, issues, feedback, etc is all muddled together with everything and it is a problem to constantly disentangle what is relevant for your widget from everything else. This organization (or lack of) makes Nebula a pretty effective dumping ground for widgets, but I think gets in the way of managing active development. It's true that we do have different models now tho (NatTable as a subproject, everything else in Nebula itself), so I guess I'd just encourage other widgets to split into subprojects if they are encountering any of the pain I just mentioned. Cheers, Edwin On Tue, Apr 9, 2013 at 4:36 PM, Wim Jongman <[email protected]> wrote: > Hi Hallvard, > > Thanks for joining the discussion. > > > On Tue, Apr 9, 2013 at 8:42 PM, Hallvard Trætteberg <[email protected]>wrote: > >> Hi, >> >> Sorry my comments are a bit late (Easter holiday/Spring break). >> >> From the consumer perspective, I agree that a table summarizing the >> purpose, features and state of widgets is important. I think a table with >> the following contents would be a good start: >> >> - widget name >> - one-liner describing purpose >> - SWT support (yes/no) >> - RWT/RAP support (yes/no) >> - JFace requirement (yes/optional/no) >> - CSS support, i.e. can be styled with CSS >> - lead maintainer >> - (separate) indication of maturity (e.g. alpha, beta, released, mature) >> and activity (e.g. inactive (dead?), stable (mainly bug-fixing), active >> (new features in development)) >> - links to example page, bugzilla, source repo, ... >> > > Yes, there seems to be consensus about this. I will start this effort. > > >> >> From the maintainer perspective I think it is important to allow for >> several models, from simple widget in common repo and little or no >> overhead, to separate project with own repo, releases and site. This >> ensures a low threshold for contributing, while allowing more complex >> projects to manage on their own without burdening the Nebula lead. >> > > I agree. This is more or less like we do it now. Edwin? > > > _______________________________________________ > 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
