I'll do a point-by-point reply. a). Do we really have an option even if it's a lot of work unless we convert to sub-project? Combining everyone's widgets and coordinating would never work I think, and as more projects join nebula it would be even harder. If we don't convert, we'll stay where we are now and go nowhere, or we do a lot of work and go somewhere. I vote for the latter.
b). I guess this depends on a) c). I don't see why not. I don't like that it's potentially "a pain in the butt" to join Nebula though. I can see why some people go the sourceforge route because there it's easy to control your project and you can manage it quite easily as well. Setting it up is also mostly a no brainer. I don't think people are against a bit of work, but if it becomes too much, they're going to wonder (like I did), if it's really worth the effort. Also, sourceforge has more of a "these people are working on the project", but I never see that in Nebula in the same way, and people can't easily join to contribute. I know there's a reason there are barriers, but sometimes they're too hight.... But I'll still say "yes". d). Agreed on the API. But I think some widgets wouldn't mind a 1.0 stamp as their api hasn't changed in a while and they're quite stable. I don't know if there should be a review process first though to ensure they conform to API and Widget "standards", probably would be good, even if it's just a "hey guys, could you take a look at ......". Emil On Fri, Nov 21, 2008 at 11:41 AM, Tom Schindl <[EMAIL PROTECTED]>wrote: > Hi, > > After having had discussions on ESE about how the nebula project can > align itself to the release and incubation rules of the Eclipse Foundation. > > Let me summarize the current situation: > a) Only a (sub-)project can do a release! If we keep the current > structure this means that we can only do a release if all > Widget-Owners agree that their code is stable enough for a release! > > b) Only a (sub-)project can be in incubation! If we keep the current > structure this means that all widgets are in incubation or none is > which is not true when we look at widgets like Gallery, Grid who are > quite stable > > c) Dormant. Only a (sub-)project can get into a dormant state! If we > keep the current structure this means that we would all together get > into dormant if we only want to have one widget (CTreeTable comes to > my mind sorry Jeremy) to become dormant to indicate the user that > there's currently no active development going on. > > d) We are afraid of doing 1.0 releases of stable widgets like PGroup, > PShelf, Grid, ... because it stops us from doing breaking API > changes. We don't need to be afraid about this. I think if we > really need to break the API contract (we should do so though with a > good reason) we need to switch to version 2.0 and continue there only > doing bugfixes in 1.x. > > So Nebula-Widget(Subproject)-Leads and Technology-PMC now its your turn > to comment on: > > a) Every *single* widget is transformed into a subproject. So it can > follow its own release cycle, incubation state, committer election, > ... . > > b) How can we the Nebula-Project-Leads and the Technology PMC ensure > that the overhead for the current widgets is as easy as possible. For > widgets like our nebula ones the subproject process is too heavy > weight IMHO (at least for the existing ones). > > c) Should we start with widgets currently proposed at nebula with this > process? > > Rich Text Control: > ------------------ > https://bugs.eclipse.org/bugs/show_bug.cgi?id=255340 > > RadioGroup/RadioItem: > --------------------- > https://bugs.eclipse.org/bugs/show_bug.cgi?id=249060 > > And then step by step move the existing ones to this new structure. > > d) Open up our own IRC as a fast communication channel between > committers, project leads, ... ? I would have been in need of this > last week where the E4 asked me to get a tagged version of the > Gallery to setup a build (well Nicolas infact there now exist a build > for your [1] :-) > > Thanks for your attention and your feedback and the time you all invest > into the cool nebula controls! > > Tom > > [1] > http://download.eclipse.org/e4/downloads/drops/I20081120-1930/index.html > _______________________________________________ > 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
