[equinox-dev] +1 for Oleg Besedin
+1 This is where you enter your comments about the candidate and you explain why you are voting +1, 0, or -1. Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re:
[equinox-dev] Ability to update from one version of the SDK version to another one
Hello, Earlier this week I had released an implementation of the IDirector.replace() API on the director. Some simple tests were working fine, however the replacement of a version of the SDK by another one turned out to be more challenging that we'd hope because of the silly implementation we have our dependency analysis mechanism (for the curious it does not backtrack). Today I'm happy to say that it is possible to install one version of the SDK and then replace it by another one! Of course this is just a first cut and there are some caveats that I will fill in the next few days. To be able to test this, you have to regenerate metadata. Note that now the metadata generator application has a parameter -rootVersion which allows you the specification of the version of the top level IU being generated. Enjoy! PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox-Bundles component is getting crowded
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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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
Re: [equinox-dev] Equinox-Bundles component is getting crowded
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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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 -
AW: [equinox-dev] Equinox-Bundles component is getting crowded
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? As an outsider I'd say use tags. HttpService would be tagged standard as well as server side. That would naturally involve some work on both front and back end and not in itself guarantee that people would easily find what they are looking for. Arthur Jeff McAffer wrote: 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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
Re: [equinox-dev] Equinox-Bundles component is getting crowded
BJ Hargrave wrote on 09/13/2007 03:13:56 PM: 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. I agree that there is likely no common view currently. That does not mean there cannot be a (reasonably) common view. That is the point of this discussion. My sense is that with the eventual addition of p2 (an obvious component) and further bundles into Bundles, the current one size fits all view will come into question in two ways. From the outside - why is p2 a component and xxx not and the inside - Bundles becomes a big soup. 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. Completely agree and I much prefer thinking without boxes. Especially arbitrary ones. Please do not confuse my comments with actually pushing this particular solution. I am exploring the space and reacting to reports from new folks to the community and people looking to get involved. They are confused by the current (lack of) structure. They want to know about/get involved in area X but cannot tell what bundles relate to area X. As I mentioned before, making a formal component may not be the best answer. Then again, at a certain point there is enough activity/interest/content/infrastruture to tip the balance and make the weight of a component worthwhile. Perhaps this whole topic deserves a small slot on the Equinox Summit agenda? Sure. The agenda is a wiki so it can be added by anyone. Speaking of which, people should be adding their agenda items... Jeff___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: AW: [equinox-dev] Equinox-Bundles component is getting crowded
can you say more about the mechanism for tagging? The sorts of media/item in question are downloads, bundles in the repo, wiki/web information, posts on the mail list or newsgroup, bugs, ... Not all need the same level of rigor perhaps. Jeff Arthur van Dorp [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 09/14/2007 01:20 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject AW: [equinox-dev] Equinox-Bundles component is getting crowded 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? As an outsider I'd say use tags. HttpService would be tagged standard as well as server side. That would naturally involve some work on both front and back end and not in itself guarantee that people would easily find what they are looking for. Arthur Jeff McAffer wrote: 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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
AW: [equinox-dev] Equinox-Bundles component is getting crowded
I was primarily thinking about web pages for downloading and searching bundles. A download page which would show all server side bundles would have some items that are also on the standard bundles page. It doesn't solve the problem of what each downloadable item should comprise and it doesn't help with tools like bugzilla or how to address things on the mailing lists. Personally I would tend to make the items small when tagging is available, e.g. a download per bundle. I'd do the same on the bugzilla side with rather fine grained partitioning. The download pages could even offer you to choose several tags/categories to include in your download and then pack you an individual downloadable bundles archive without duplicates and all the items you wanted. (Ah, the lovely smell of over-engineering in the early morning :) ). Arthur Jeff McAffer wrote: can you say more about the mechanism for tagging? The sorts of media/item in question are downloads, bundles in the repo, wiki/web information, posts on the mail list or newsgroup, bugs, ... Not all need the same level of rigor perhaps. Jeff *Arthur van Dorp [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 09/14/2007 01:20 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject AW: [equinox-dev] Equinox-Bundles component is getting crowded 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? As an outsider I'd say use tags. HttpService would be tagged standard as well as server side. That would naturally involve some work on both front and back end and not in itself guarantee that people would easily find what they are looking for. Arthur Jeff McAffer wrote: 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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
