Hi, Yes I agree with Nicolas. If the only way of getting you guys here is through a subproject then I will vote +1 but I think that we are stronger if we join forces. We will still be responsible for our own widgets but we can work together on the commons (build, website, wiki, blogs, etc..)
Shall I continue to file the CQ while we discuss this? Regards, Wim On 22 nov. 2011, at 12:36, Nicolas Richeton <[email protected]> wrote: > Hi all, > > I'm not sure that creating subprojects for a single widget would be a good > thing. I understand the reasons why NatTable needs to be a subproject, but I > think these are issues we have to solve for every widget : > > * Being able to install independently : > Each widget has his own plugins : widget, tests, feature, ... This won't > change. > Version numbers do not necessary have to be in sync for all Nebula widgets. > > * Having its own build > XViewer already have his own build because eclipse projects depends on it. > This is something that can be done without being a subproject, but I still > think this should be avoided. (If we look at an another projet : I believe > SWT build fails if tests for one component fail). The key thing is : projects > which depends on Nebula should not build against the trunk. They should build > against an integration or a release branch/site which always builds. We have > setup things in a way that make this work. > > * Being able to release with its own schedule. > We are looking for a 1.0 nebula release with several widgets, but we will > always have to fix major/critial issues on a widget without waiting for the > next major Nebula release. I believe we have to see a nebula release as a > snapshot of the current stable widgets (for the annual eclipse release train) > and keep an update site with intermediate/frequent releases. > > It NatTable committers are ready to go fast and get out of incubation right > away, I rather remove all widgets from the release project, keeping only > NatTable and then add every stable widget one after one, than going thru the > eclipse process for only one subproject. > > That said, everything is possible :-) > -- > Nicolas > > > > > > Le 21 nov. 2011 à 23:26, Tom Schindl a écrit : > >> Hi, >> >> +1 for me on moving forward as a subproject to Nebula but Wim I'd like >> to hear Wims and Nicolas' input. >> >> Tom >> >> Am 21.11.11 23:05, schrieb Edwin Park: >>> Hi all, >>> >>> Once upon a time, there was a proposal to bring NatTable to Eclipse... :-) >>> >>> It has taken some time, but we've gotten through all the IP >>> attribution issues finally and I have the go ahead from Eclipse legal >>> to push this forward again. In the meantime I know Nebula has been >>> going through changes as well. Importantly, in order to move forward >>> this needs to be pushed by the Nebula folks. Tom, would you still be >>> the one to do this or does that fall to Wim now? >>> >>> Also, I wanted to update everyone on the current status and sync up on >>> the plan for moving forward to make sure we're all on the same page: >>> >>> The original New Widget request for NatTable is here: >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=328836 >>> The latest version of the code attached to this is NatTable 2.2.0. The >>> current production version is 2.3.0. No additional dependencies have >>> been added in the interim, but there is new post-2.3.0 code in trunk >>> that introduces a new dependency on Apache Poi for table export. This >>> is packaged as a separate extension bundle however, so if there are >>> issues with this we can always omit it from moving over to Eclipse. >>> >>> The NatTable Eclipse Project Proposal is here: >>> https://docs.google.com/document/d/1Krpj0ceaWqP-WndbR1Ba79gwhGCbUHNspw-j9naYPQc/edit?hl=en_US >>> The only update that may need to be made for this is the tentative >>> project schedule, which currently indicates code contribution and >>> migration to Eclipse is Q4 2011.. >>> >>> The plan for moving NatTable to Nebula was to make it a Nebula >>> subproject rather than incorporating it into the conglomerate Nebula >>> project and build. Tom and I favored this approach because we wanted >>> to preserve the ability for NatTable to maintain its own independent >>> release schedule. NatTable has 7 active committers and a history of >>> putting out regular releases over the past four years. I'm happy to >>> take on the additional maintenance overhead of treating NatTable as a >>> separate project since that's what it is now anyway. >>> >>> Wayne needs confirmation from the Nebula project that we want to move >>> forward with NatTable as a Nebula subproject, and then my >>> understanding from legal is that we'd need someone from Nebula to kick >>> off the CQ. >>> >>> It's been over a year since we started this journey and I'm eager to >>> see this through. :-) >>> >>> Thanks, >>> Edwin >>> _______________________________________________ >>> nebula-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/nebula-dev >> >> >> -- >> B e s t S o l u t i o n . a t EDV Systemhaus GmbH >> ------------------------------------------------------------------------ >> tom schindl geschäftsführer/CEO >> ------------------------------------------------------------------------ >> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512 935833 >> http://www.BestSolution.at phone ++43 512 935834 >> _______________________________________________ >> 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
