Re: [equinox-dev] Equinox->Bundles component is getting crowded

["Alex Blewitt" <alex.blewitt@xxxxxxxxx>]

Frankly, the organisation of Eclipse projects in general falls into
the same problem (i.e. is it in tools/, eclipse/, technology/ ...

On 13/09/2007, BJ Hargrave <hargrave@xxxxxxxxxx> wrote:
> > It is about community and clarity for our consumers.
>
> I don't see how arbitrary groupings help here. The whole point of the
> component model is people pick the components they need which is why it is
> good that people can download bundles individually. Arbitrary groupings
> would be more interesting perhaps if you actually delivered against the
> groupings.
>
> > Why not reify the structure we think we have?
>
> I think part of the issue is that there is no common view of the structure
> "we think we have" to reify it.
>
> >  would the http service be part of "standard services" or "server side"?
>
> You totally avoid this question by avoiding arbitrary groupings like
> standard services and server side.
>
> Perhaps this whole topic deserves a small slot on the Equinox Summit
> agenda?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@xxxxxxxxxx
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> From:
> Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
> To:
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> Date:
> 2007-09-13 09:04
> Subject:
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
> to me it is neither of these options.  It is about community and clarity
> for our consumers.  Walking up to Equinox you just have a sea of bundles.
> Add in the p2 and security stuff and the sea turns into an ocean.  Say you
> hear that Equinox has implementations of some OSGi service specs.  If you
> go to the download page today you have to grovel through spec impls,
> launchers, random other stuff and cannot tell one from the other.  Since
> there is no particular web/wiki page for people interested in spec
> implementations, it is hard to build a community around that topic. People
> interested in contributing to standard spec impls cannot easily find
> related bugs etc.  There is also no clear lead of that community who is
> plotting the course/planning, coordinating execution, building the
> community, ...  You can replace OSGi service spec with p2, security, ...
>
>
> A number of these issues can be addressed simply by structuring the
> download site or wiki or...  If you address most of them then in effect
> you have just created a component without actually creating a component.
> So what are we afraid of?  Why not reify the structure we think we have?
>
> That begs the question, what is the structure? The challenge is that all
> partitionings will have problems as different people have different views
> on the world.  would the http service be part of "standard services" or
> "server side"?  However the existance of issues need not stop progress or
> movement.  So this discussion is really about defining that structure.  At
> least thats my view...
>
> Jeff
>
>
>
> BJ Hargrave <hargrave@xxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 05:13 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
> What is the point of the proposed change?  Tom's mail suggests we
> subdivide bundles. But in what way? To organize commit rights or bugs in
> bugzilla? Or both? I guess that is what is not clear. Clarity here will
> help us evaluate choices. It seems we can easily have M bugzilla
> components and N commit right sets with M >=N. Right now (for bundles) M
> and N both equal 1. Are we looking to increase M or N or both?
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@xxxxxxxxxx
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> From:
> Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
> To:
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> Date:
> 2007-09-12 16:03
> Subject:
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
> yes but under the new plan you pointed out, the commit rights will be
> managed by groups and groups will have a 1:1 relationship to components
> and components will have associated leads, bugzilla entries, websites, ...
>
> This is alot of infrastructure to put in place for each bundle.
>
> We did "bundles" originally because we could not come up with any
> reasonable partitioning of the space.  To date we have gotten away with it
>
> because a) the number of bundles in there was relatively low and b) many
> have very little activity.  As Tom points out, this is changing.  Our
> solution space seem to be N bundles => 1 group, N groups or M groups where
>
> 1 < M < N.  Unfortunately, it is still not clear that there is a
> reasonable grouping so while (at least to me) M groups feels like a good
> spot, it will be challenging.  Here are some thoughts
> - "framework" = the framework.  This stays unchanged
> - "standard" = bundles that implement OSGi standard services
> - "p2"
> - "security" = if needed
> - "bundles" = catch all for things that don't fit
>
> This is just a stake in the ground.
>
> Jeff
>
>
>
> John Arthorne/Ottawa/IBM@IBMCA
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 03:42 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
>
> Since "component" is a confusing term, I should clarify my comments on
> this.  I like the idea of being more fine-grained with Unix groups (CVS
> commit rights), because I think it encourages new committers. If someone
> joins the community with a strong interest in a narrow area (such as
> security or provisioning), but isn't interested in the rest of the
> framework, they could quickly earn commit rights in that area, without
> having to give them write access to other code they aren't qualified to
> maintain (or aren't interested in maintaining).  On the question of
> bugzilla components, I don't particularly care whether we have one or ten
> - these are fairly easy to change over time as the need arises.
>
> John
>
>
> John Arthorne/Ottawa/IBM@IBMCA
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 03:24 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
>
>
>
> I agree one component per bundle is probably overkill.  However, it's not
> necessarily true that the CVS commit groups match 1-1 with Bugzilla
> groups. While it's often convenient to do it this way, it's not a
> constraint that we need to conform to.  I should also add that the EMO has
>
> a plan under consideration for standardizing the group structure for Unix
> groups, and part of this work is to facilitate election across multiple
> groups (see item 6 in
> https://bugs.eclipse.org/bugs/attachment.cgi?id=77092).  Essentially,
> simultaneously nominating an individual for N groups would only require a
> single election, and a single vote per committer. Just some things to
> consider...
>
>
> Thomas Watson <tjwatson@xxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 02:47 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
>
>
>
>
> There are two extreme positions to take. Lump a large number of loosely
> related deliverables under one component or create a separate component
> for each and every deliverable. I'm not sure I favor the latter extreme.
> Currently the Equinox download page allows you to download each bundle
> individually so each bundle is a separate downloadable item. Creating a
> separate component for each and every bundle in Equinox may prove to be
> too much overhead. It is my understanding that in Eclipse typically every
> bugzilla component has its own set of commit rights in CVS. If we have a
> very high number of components then we will be holding a very large number
>
> of committer elections to get all the committers the access they need :-)
>
> I think we a balance and create components as we see fit to split up the
> different work areas in Equinox instead of creating a component for every
> bundle.
>
> Tom
>
>
>
> BJ Hargrave---09/12/2007 12:31:35 PM---It would probably be best if each
> separately downloadable item had its own
> BJ Hargrave/Austin/IBM@IBMUS
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 12:30 PM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
>
>
>
>
> To
>
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
>
> cc
>
>
>
>
>
> Subject
>
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
>
>
>
> It would probably be best if each separately downloadable item had its own
>
>
> component against which people could file bugs.
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance
> hargrave@xxxxxxxxxx
>
> office: +1 386 848 1781
> mobile: +1 386 848 3788
>
>
>
>
> From:
> Thomas Watson/Austin/IBM@IBMUS
> To:
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> Date:
> 2007-09-12 12:34
> Subject:
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
> For the security stuff I was referring to the security-specific bundles
> like login (JAAS integration etc.)
>
> You are right there is a lot of cross-cutting concerns with the other
> security related work that will not really fit into any one component.
>
> Tom
>
>
>
> John Arthorne ---09/12/2007 11:25:42 AM---Creating a new component for p2
> definitely makes sense to me. I don't know much about the security work,
> but that may be diffi
>
> John Arthorne <John_Arthorne@xxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 11:21 AM
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
>
> To
>
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> cc
>
>
> Subject
>
> Re: [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
> Creating a new component for p2 definitely makes sense to me. I don't know
>
>
> much about the security work, but that may be difficult to partition into
> its own component because it's an inherently cross-cutting concern. If
> there end up being a number of security-specific bundles, it may make
> sense.
>
> Generally speaking, I think more components is a good thing. It's a great
> way to bring in new committers who may not be able to make the large
> commitment needed to contribute across a large part of Equinox.
>
> John
>
>
> Thomas Watson <tjwatson@xxxxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 09/12/2007 11:42 AM
>
>
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
>
> To
> equinox-dev@xxxxxxxxxxx
> cc
>
> Subject
> [equinox-dev] Equinox->Bundles component is getting crowded
>
>
>
>
>
>
>
>
> The Equinox project continues to grow with new components and new
> contributes being added. Thanks everyone!!
>
> As new contributions are graduated into Equinox proper we need to place
> them under one of the existing components. Currently we have the
> "Framework" and "Bundles" components for Equinox proper in bugzilla/cvs. A
>
>
> large majority of the new contributions will fall into the "Bundles"
> component. For example, we have a few work areas in the equinox incubator
> which are very active (e.g. p2, security etc). Once this work graduates it
>
>
> will likely to be placed into the generic "Bundles" component. This will
> make an already crowded component even more crowded.
>
> Should we consider creating a more diverse set of components for the work
> which is graduated into Equinox? I think the p2 and security work will
> deserve their own component when they graduate. Thoughts?
>
> Tom
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> (See attached file: pic01850.gif)
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
>