Re: [nebula-dev] Restructuring Nebula Project

["Emil Crumhorn" <emil.crumhorn@xxxxxxxxx>]

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 <listom@xxxxxxxxxxxxxxx> 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
nebula-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/nebula-dev