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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > From: > Jeff McAffer <[EMAIL PROTECTED]> > To: > Equinox development mailing list <[email protected]> > 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 09/12/2007 05:13 PM > > Please respond to > Equinox development mailing list <[email protected]> > > > To > Equinox development mailing list <[email protected]> > 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 > [EMAIL PROTECTED] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > From: > Jeff McAffer <[EMAIL PROTECTED]> > To: > Equinox development mailing list <[email protected]> > 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/[EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > 09/12/2007 03:42 PM > > Please respond to > Equinox development mailing list <[email protected]> > > > To > Equinox development mailing list <[email protected]> > 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/[EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > 09/12/2007 03:24 PM > > Please respond to > Equinox development mailing list <[email protected]> > > > > To > Equinox development mailing list <[email protected]> > 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 09/12/2007 02:47 PM > > Please respond to > Equinox development mailing list <[email protected]> > > > > To > Equinox development mailing list <[email protected]> > 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/[EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > 09/12/2007 12:30 PM > > Please respond to > Equinox development mailing list <[email protected]> > > > > > > > > To > > Equinox development mailing list <[email protected]> > > > > > 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 > [EMAIL PROTECTED] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > > > From: > Thomas Watson/Austin/[EMAIL PROTECTED] > To: > Equinox development mailing list <[email protected]> > 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 09/12/2007 11:21 AM > > Please respond to > Equinox development mailing list <[email protected]> > > > > > To > > Equinox development mailing list <[email protected]> > > 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 <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 09/12/2007 11:42 AM > > > Please respond to > Equinox development mailing list <[email protected]> > > > > To > [email protected] > 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > (See attached file: pic01850.gif) > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
