[equinox-dev] Vote for Committer status for Oleg Besedin has started
eclipse.incubator.equinox Committers, This automatically generated message signals that Jeff McAffer has nominated Oleg Besedin as a Committer on the equinox component of the eclipse.incubator project. The reason given is as follows: It seems that when we set up the Equinox incubator somehow we missed Oleg in the list of initial committers. All committers in the regular Equinox components should be a committer in the incubator The vote is being held via the MyFoundation portal: voters *must* use the portal for the votes to be properly recorded. The voting will continue until either all 21 existing Committers have voted or until they have been given enough time to vote, even if they do not do so (defined as at least one week). Oleg Besedin must receive at least three +1s and no -1s for a successful election. Eligible Committers must cast their votes through their My Foundation portal page (do NOT just reply to this email; your vote will not be correctly recorded unless you use the portal): http://portal.eclipse.org/ If you have any questions, please do not hesitate to contact your project lead, PMC member, or the EMO [EMAIL PROTECTED] The project Committers eligible to vote are: John Arthorne Robert Connell Sonia Dimitrov Jennifer Fogell Olivier Gruber Ted Habeck BJ Hargrave Kim Horne DJ Houghton Simon Kaegi Peter Kriens Martin Lippert Jeff McAffer Susan McCourt Kim Moir Andrew Niefer Pascal Rapicault Jay Rosenthal Thomas Watson Matthew Webster Ikuo Yamasaki ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[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
[equinox-dev] +1 for Oleg Besedin
+1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[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
[equinox-dev] +1 for Oleg Besedin
+1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Oleg Besedin
+1 Voting summary: http://portal.eclipse.org/ ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
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 equinox-dev@eclipse.org To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ 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
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 [EMAIL PROTECTED] .ibm.com To Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 09/12/2007 11:21 Re: [equinox-dev] Equinox-Bundles AMcomponent is getting crowded Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org 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: To [EMAIL PROTECTED] equinox-dev@eclipse.org cc 09/12/2007 11:42 AM Subject [equinox-dev] Equinox-Bundles component is getting crowded Please respond to Equinox development mailing list equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gifinline: pic01850.gifinline: ecblank.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] +1 for Oleg Besedin
+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
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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To equinox-dev@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev attachment: pic01850.gif___ 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
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/Austin/I [EMAIL PROTECTED] To Sent by: Equinox development mailing list equinox-dev-bounc equinox-dev@eclipse.org [EMAIL PROTECTED] cc Subject 09/12/2007 12:30 Re: [equinox-dev] Equinox-Bundles PMcomponent is getting crowded Please respond to Equinox development mailing list [EMAIL PROTECTED] pse.org 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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To equinox-dev@eclipse.org 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
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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To equinox-dev@eclipse.org 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
Re: [equinox-dev] Equinox-Bundles component is getting crowded
For now I would stick with prefix in the summary (e.g. [prov]). This is what I have been using in p2 and worked great so far, as I never see any other bugs from the incubator. This is pretty clear and does not bring forces us into to strict of a categorization. Also this way bugs can be multiply categorized ([sec][prov], a security issue on provisioning). As some work area because vast, we can try to create categories but for now I don't see the need. PaScaL From: Thomas Watson [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 09/12/2007 02:50 PM 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 (Embedded image moved to file: pic04828.gif)Inactive hide details for BJ Hargrave---09/12/2007 12:31:35 PM---It would probably be best if each separately downloadable itemBJ Hargrave---09/12/2007 12:31:35 PM---It would probably be best if each separately downloadable item had its own BJ Hargrave/Aus tin/[EMAIL PROTECTED] S(Embedded image moved to file: Sent by: pic12496.gif) equinox-dev- To [EMAIL PROTECTED] (Embedded image moved to pse.org file: pic19700.gif) Equinox development mailing list 09/12/2007 equinox-dev@eclipse.org 12:30 PM (Embedded image moved to file: pic10719.gif) cc Please respond to (Embedded image moved to Equinox development mailing list file: pic25593.gif) equinox-dev@eclipse.org (Embedded image moved to file: pic26588.gif) Subject (Embedded image moved to file: pic23207.gif) Re: [equinox-dev] Equinox-Bundles component is getting crowded (Embedded image moved to file: pic26607.gif) (Embedded image moved to
Re: [equinox-dev] Equinox-Bundles component is getting crowded
[EMAIL PROTECTED] wrote on 2007-09-12 14:47:42: 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. What overhead? The provisioning of a set of components for the Equinox product in bugzilla? It is my understanding that in Eclipse typically every bugzilla component has its own set of commit rights in CVS. I am not sure this is true. According to portal.eclipse.org, I am a committer on eclipse, eclipse.equinox and eclipse.incubator. Thus it would seem to me we only need to elect one to eclipse.equinox to have commit rights to all the framework and the various potential bundle components. 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. I think the think you want to minimize is the number of committer groups. Assuming that bugzilla components are not tied to committer groups, then there is no reason not to have a 1-1 mapping of downloadable items to bugzilla components. Tom -- 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 ___ 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
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] 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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
Re: [equinox-dev] Equinox-Bundles component is getting crowded
BJ Hargrave wrote on 09/12/2007 03:33:59 PM: I am not sure this is true. According to portal.eclipse.org, I am a committer on eclipse, eclipse.equinox and eclipse.incubator. Thus it would seem to me we only need to elect one to eclipse.equinox to have commit rights to all the framework and the various potential bundle components. Actually the UI is misleading. Components are treated as second-class by the web ui. Actually they are hidden for scaleability reasons. If you drill into the members link in any given project you will see that you are a committer on the framework and bundles components of equinox (for example). Note that there is currently some bogus data driving these pages to don't believe all you see. Jeff ___ 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
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] 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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
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] 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 equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org 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
