I agree. If the contribution is substantial then we should aim for a sub-project. If not then we could consider hosting it in the bin.
Anyone from the current widget owners that want to move in a separate repo? On Fri, Apr 12, 2013 at 5:07 PM, Edwin Park <[email protected]> wrote: > 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 > >
_______________________________________________ nebula-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/nebula-dev
