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 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 (See attached file: pic01850.gif) _______________________________________________ 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
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<attachment: pic01850.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
