Bugzilla – Full Text Bug Listing
| Summary: | Eclipse top-level project group cleanup | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | John Arthorne <john.arthorne> | ||||||||||||||
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> | ||||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | P3 | CC: | daniel_megert, janet.campbell, jeffmcaffer, Mike_Wilson, mober.at+eclipse, pwebster, sharon.corbett, wayne.beaton | ||||||||||||||
| Version: | unspecified | ||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||
| Hardware: | PC | ||||||||||||||||
| OS: | Windows XP | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
John Arthorne
Our proposed structure reflects to the traditional 3-level project structure found at Eclipse. We have 5 principle projects (platform, jdt, pde, incubator, and e4). The first three of those projects have a number of sub-projects, while the incubator and e4 are organizationally flat. One open question for us, is how to handle "common" artifacts shared by multiple sub-projects. For example we have documentation, web content, release engineering artifacts, etc, that all committers should have access to. There are a few ways to support this: 1) Have an "eclipse.common" group for the common stuff, and we have separate committer elections to be added to that group. 2) Have an "eclipse.common" group for the common stuff, and we automatically add committers to that group if they become committers on any sub-project 3) There is no "eclipse.common" group, but the ACL's are configured so that those common directories are jointly owned by all ACL's used by the project. We would like to avoid the extra overhead of 1). Number 2) is easy enough, but doesn't have the attribute of "one vote == one ACL". This makes things more complex and potentially harder to completely automate the election process. 3) would be fine with us but we don't know what kind of work that involves for the webmasters to implement. If you (webmasters) could provide feedback on which of those you prefer, that would be helpful. I like #3. Question: Do we have a similar topic for the platform, pde and jdt groups. As it is all the pde.* committers need also to have access to pde-doc and pde-home etc. Suggestion: why not put ALL of the doc and web sites etc under one banner (e.g., eclipse.common) and then ALL committers anywhere on the Eclipse projects get access by virtue of approach #3. Looking at it another way, why put up barriers to committers writing doc and updating web pages? Topic: org.eclipse.platform is a grab bag of old stuff and a couple things that don't really fit anywhere else. in particular there is a) really old stuff that never really made it (scripting, webdav, ...), b) deprecated things like Update and c) Ant that does not obviously fit somewhere else. Similarly, org.eclipse.jdt and org.eclipse.pde control the jdt and pde features and home pages (respectively). Suggestion: Eliminate org.eclipse.platform, org.eclipse.pde and org.eclipse.jdt. For Platform make a org.eclipse.platform.<oldstuff> (Or some such) for the old stuff. Move Ant to debug (or some suitable home) and the doc/webpages etc to eclipse.common. for pde and jdt, put their features in either releng or eclipse.common and their websites in eclipse.common. Without doing this we will have, for example, org.eclipse.jdt.ui committers also needing to be org.eclipse.jdt committers or we'll have to do the #3 thing again at each level. This approach flattens the structure completely. Regardless of the flattening, I would have expected to see eclipse.common appear more in the mapping from folder to ACL. As it is there are only org.eclipse.releng in eclipse.common. doesn't seem to match approach what we are shooting for. btw, I'm not sure that "Bugzilla" is the right component for this discussion. (In reply to comment #1) > 3) There is no "eclipse.common" group, but the ACL's are configured so that > those common directories are jointly owned by all ACL's used by the project. This is our preferred option as well, provided all the common files/directories are under a single directory/container at the top-level. As you may know, *nix filesystems function on the basis that each file and object is owned by exactly one user and one group. Webmasters use extended ACLs to achieve #3, but ACLs are clunky to work with. Here is a snapshot of the Webtools CVS structure: Group Directory ================================ cvs CVSROOT webtools.common common webtools.datatools datatools webtools.ejbtools ejbtools webtools.incubator incubator webtools.jeetools jeetools webtools.dali org.eclipse.jpa webtools.jsdt org.eclipse.jsdt webtools.jsf org.eclipse.jsf webtools.pave org.eclipse.pave webtools.servertools servertools webtools.sourceediting sourceediting webtools.webservices webservices webtools.releng webtools.maps webtools.releng webtools.releng It's nice and clean, and only the webtools.maps directory contains extended ACLs to achieve your #3 solution above. The rest of the directories are owned by the group, and no further ACLs are specified. The ACL list for the webtools.maps directory looks like this: dev1:/cvsroot/webtools # getfacl webtools.maps # file: webtools.maps # owner: david_williams # group: webtools.releng # flags: -s- user::rwx group::rwx group:webtools.incubator:rwx group:webtools.common:rwx group:webtools.dali:rwx group:webtools.datatools:rwx group:webtools.ejbtools:rwx group:webtools.jeetools:rwx group:webtools.jsf:rwx group:webtools.releng:rwx group:webtools.servertools:rwx group:webtools.sourceediting:rwx group:webtools.webservices:rwx group:webtools.pave:rwx group:webtools.jsdt:rwx mask::rwx other::r-x default:user::rwx default:group::rwx default:group:webtools.incubator:rwx default:group:webtools.common:rwx default:group:webtools.dali:rwx default:group:webtools.datatools:rwx default:group:webtools.ejbtools:rwx default:group:webtools.jeetools:rwx default:group:webtools.jsf:rwx default:group:webtools.releng:rwx default:group:webtools.servertools:rwx default:group:webtools.sourceediting:rwx default:group:webtools.webservices:rwx default:group:webtools.pave:rwx default:group:webtools.jsdt:rwx default:mask::rwx default:other::r-x Extended ACLs are not impossible to work with, but if we can set them once for a single container directory at the 'top' level that is the most efficient setup. What we want to avoid is 'oh, can you also make this sub/sub/sub/sub/sub-directory writable by all?'. (In reply to comment #3) > btw, I'm not sure that "Bugzilla" is the right component for this discussion. Right, I'll try "Servers" but webmasters feel free to move it. (In reply to comment #2) > Suggestion: why not put ALL of the doc and web sites etc under one banner > (e.g., eclipse.common) and then ALL committers anywhere on the Eclipse projects > get access by virtue of approach #3. Looking at it another way, why put up > barriers to committers writing doc and updating web pages? +1, That's fine with me. > Suggestion: Eliminate org.eclipse.platform, org.eclipse.pde and > org.eclipse.jdt. For Platform make a org.eclipse.platform.<oldstuff> (Or some > such) for the old stuff. Move Ant to debug (or some suitable home) and the > doc/webpages etc to eclipse.common. for pde and jdt, put their features in > either releng or eclipse.common and their websites in eclipse.common. I agree with putting all features under releng. Typically the releng team needs to be involved whenever bundles are added to a feature anyway. I also agree with moving the doc/webpages to eclipse.common. For that matter, we could even move all the oldstuff to eclipse.common as well - it's not like there is a big risk of committers messing with the webdav or scripting components and causing any problems. Darin disagreed with the suggestion of moving Ant to Debug, so maybe we just keep an Ant component (which includes [core|ui].externaltools as well). (In reply to comment #4) > (In reply to comment #1) > > 3) There is no "eclipse.common" group, but the ACL's are configured so that > > those common directories are jointly owned by all ACL's used by the project. > > This is our preferred option as well, provided all the common files/directories > are under a single directory/container at the top-level. The currently proposal only contains our "maps" in eclipse.common, much like webtools. However we are separately discussing including doc and web pages, which is about 20 top-level directories in /cvsroot/eclipse, and another handful in /cvsroot/org.eclipse. Given that, perhaps it is easier to keep the "eclipse.common" group if there are a large number of directories in that boat. seems unlikely that there will be one dir to hold all the "common" stuff. those are all over the map. So is it conventient to have a eclipse.common group that owns the various dirs all over the place and then all committers would get rights to whatever eclipse.common owned and (of course) whatever they are committers on? We want to avoid having to have two elections, one for the real component and one for eclipse.common as we just want ALL eclipse project committers to have access to the common bits. (In reply to comment #6) > I agree with putting all features under releng. Typically the releng team needs > to be involved whenever bundles are added to a feature anyway. I also agree > with moving the doc/webpages to eclipse.common. For that matter, we could even > move all the oldstuff to eclipse.common as well - it's not like there is a big > risk of committers messing with the webdav or scripting components and causing > any problems. More power to them if they do! > Darin disagreed with the suggestion of moving Ant to Debug, so > maybe we just keep an Ant component (which includes [core|ui].externaltools as > well). We should try to get away from these fine-grained things. 1/2 a person on Ant does not a subproject make. The same is true of Text (not sure how many people are on that). Debug does seem the closest to Ant. UI could work with Text perhaps? It just feels broken to restructure and make projects that start off sparsely populated with no real plan for growth. We would not accept that for a new project. >one vote == one ACL" This should be the goal. +1 for opening the doc access to all (actually I already suggested that once to John) but I don't like to open up e.g. JDT web pages and plans to everyone. >We want to avoid having to have two elections, one for the >real component and one for eclipse.common as we just want ALL eclipse project >committers to have access to the common bits. Definitely. That's why I also prefer approach 3 from comment 1. >Suggestion: Eliminate org.eclipse.platform, org.eclipse.pde and >org.eclipse.jdt. ... for pde and jdt, put their features in >either releng or eclipse.common and their websites in eclipse.common. I could live with that as long as the access to the features and web pages is still restricted and not open for all committers: - xyz features: eclipse.releng and eclipse.xyz.* groups - web: eclipse.xyz.* groups +1 for having releng access all features BUT: the sub-projects (e.g. JDT or PDE) must have access to their features and not all committers must be part of eclipse.releng (only releng people plus those who gained commit rights on e.g. the Releng tools project). So, e.g. if we decide to get rid of eclipse.jdt, .pde, etc, org.eclipse.jdt-feature would be opened for 'eclipse.jdt.core', 'eclipse.jdt.debug', 'eclipse.jdt.ui' and 'eclipse.releng' > UI could work with Text perhaps? Sorry, -1 from here. I do want to have an 'eclipse.platform.text' group. UI is not text and vice versa. (In reply to comment #10) > +1 for having releng access all features BUT: the sub-projects (e.g. JDT or > PDE) must have access to their features and not all committers must be part of > eclipse.releng (only releng people plus those who gained commit rights on e.g. > the Releng tools project). So, e.g. if we decide to get rid of eclipse.jdt, > .pde, etc, > org.eclipse.jdt-feature would be opened for > 'eclipse.jdt.core', 'eclipse.jdt.debug', 'eclipse.jdt.ui' and 'eclipse.releng' This is starting to sound really complicated to manage (directory 'x" is owned by these four groups, directory 'y' is owned by another four groups, etc). If you want to keep write access to JDT features within JDT, then we'll just leave it there. The build engineer ends up needing to have commit rights on every group anyway (mainly to do tagging). I think for the sake of simplicity we should keep the common groups for JDT, PDE, and Platform. The project web pages, features, examples, and other common directories would live there. In fact I suggest renaming these (eclipse.jdt becomes eclipse.jdt.common, eclipse.platform becomes eclipse.platform.common, etc). Several people have expressed confusion because the group names appeared hierarchical when in practice they don't function that way (belonging to x.y.z does not imply belonging to x.y). >If >you want to keep write access to JDT features within JDT, then we'll just leave >it there. The build engineer ends up needing to have commit rights on every >group anyway (mainly to do tagging). Agreed. That way, the eclipse.platform.releng group would only hold the specific releng projects (e.g. Releng Tools) and some top-level features like SDK. >I think for the sake of simplicity we should keep the common groups for JDT, >PDE, and Platform. The project web pages, features, examples, and other common >directories would live there. I can live with that but it will violate "one vote == one ACL". (In reply to comment #12) > >I think for the sake of simplicity we should keep the common groups for JDT, > >PDE, and Platform. The project web pages, features, examples, and other common > >directories would live there. > I can live with that but it will violate "one vote == one ACL". Even if we end up with two votes it seems easier to manage to me. It might vary by project but maybe not all committers will need commit rights on the common stuff. Now that I think about it more, if the common stuff has a different pool of committers, it should probably have a different vote anyway. Technically all existing committers on a given directory should be able to participate in a vote to add a new committer in that area. If a new commiter gains access to platform doc stuff automatically via a vote on a JDT project, then the non-JDT platform doc committers would not get a vote. >If a new commiter gains access to
>platform doc stuff automatically via a vote on a JDT project, then the non-JDT
>platform doc committers would not get a vote.
If we really agree that all committers get access to all the doc, then I see no point in holding two elections. If the new process puts more administrative load on me, e.g. by being forced to hold two or even three votes for one new committer then that's a -1 for me. I think if we really need to violate the "one vote == one ACL" then the additional groups should be implicit.
Webmasters, we have reached agreement in the PMC and would like to move forward with this cleanup. Our story is: - One election == One Unix group/ACL - Reducing from 71 ACL's to 20 for entire Eclipse TLP - There is no "common" group that all committers must have access to - Some directories that are shared across sub-projects have multiple ACL's assign to them (mainly documentation, release engineering artifacts) The following wiki page has a complete breakdown of which group(s) owns each directory in our current CVS tree: http://wiki.eclipse.org/Eclipse/PMC/Unix_Groups/New_ACLS_By_Project We would like to get agreement from your side before we move to the next step. If the multiple ACL's per directory story is too complex, our fallback would be to have a separate "common" unix group for the common bits, and a single election would result in access to two groups. Having a separate election for common bits was considered unacceptable. Assuming this proposal is good on your end, our next steps are: 1) Create the new Unix groups 2) Nominate/elect committers in these new Unix groups (probably via single mass election) 3) chown the directories to the new groups 4) Remove the old Unix groups 5) Deactivate committers who no longer belong to any groups 6) Live happily ever after >2) Nominate/elect committers in these new Unix groups (probably via single mass
>election)
In my opinion an election is not necessary but we have to post the intended group assignments to eclipse-dev, platform-dev, jdt-dev and pde-dev to give our committers the opportunity to speak up in case we missed something. This post should also include those individuals that didn't contribute for e.g. 5 years, giving them the opportunity to announce that they still want to be part of the committer community - otherwise they won't be assigned to any of the new groups.
>6) Live happily ever after
I like that part! ;-)
For completeness, an election is not required. I agree with Dani that giving everybody an opportunity to weigh in is the right thing to do. webmaster/EMO: ping. We would like to move forward with this proposal. See comment #15 for a summary. Can you give us an estimate on when you might be able to look at this? If it helps, we can provide the mapping of projects to new ACLs in a script-friendly form to help automate the switch. An exercise of this nature will require legal paperwork verification. This will work best if a spreadsheet is provided to identify the changes that are required. If a committer's paperwork does not provide for the required change, we will work with the committer to obtain required paperwork before any change can be made to their Unix ID. Thanks, Sharon IP Team (In reply to comment #20) > An exercise of this nature will require legal paperwork verification. > > This will work best if a spreadsheet is provided to identify the changes that > are required. If a committer's paperwork does not provide for the required > change, we will work with the committer to obtain required paperwork before any > change can be made to their Unix ID. Ok, I want to be sure exactly what data you need before I collect it. I suppose you are interested in the committer mappings to the new groups, something like this? user1 eclipse.platform.runtime user2 eclipse.platform.ui,eclipse.jdt.ui etc Do you also need the data on what groups are being *removed* for each user? I was hoping we would never need to compile that, and the net effect is that some very inactive users would not belong to any groups after the transition is complete (by virtue of all groups they belong to going away). To clarify, this process will not add any new committers to any project. We are just cleaning up our byzantine Unix permission groups to better match the actual project structure. It surprises me that this change impacts legal paperwork but I take your word for it! I spoke with Sharon and she offered to start a spreadsheet that we can then fill in. The Foundation has a database of committers and the projects they can commit to, and there may well be discrepancies between that database and the Unix groups. For example we often have committer elections where the person being nominated is eligible to vote for him/herself, and these represent cases where the Foundation database believes they are already a committer but the Unix permissions say otherwise (bug 249648, bug 231933, and probably others). It will be a fantastic side-effect of this cleanup if these discrepancies can all be cleaned up. Having a single spreadsheet/whatever to gather the information will help make sure we end up in a consistent state. Sharon, I double-checked and we did not go with the "eclipse.common" idea. So, there will be no committers added to any of the principle sub-projects with this change (Platform, Incubator, JDT, PDE, e4). Within each of those sub-projects, some committers will get wider access and be allowed to modify more code than previously, but only within a sub-project they are already a committer on. However I still thing a spreadsheet would help to ensure that the foundation database is consistent with the unix users/groups when we are done. Created attachment 182043 [details]
Spreadsheet of Eclipse Project Committers as of Oct 29, 2010
Please find attached a listing of committers based on projects. For obvious reasons, the committers are identified by ID only.
Regards,
Sharon
I find this hard to work with, because there are many rows for each committer and they aren't grouped together. Also there seems to be poor correlation between this list and the actual set of accounts with commit access. For example this spreadsheet lists 14 committers on eclipse.platform.core, but there are actually 22 committers on the plat-core Unix group. There are many people with commit rights whose names don't appear in your database at all. Also there is no obvious correlation to your current notion of "project" access and the Unix groups we have today. In our end state there will be a 1-1 correspondence between these two. In the end, we want to end up in a state where the foundation database matches reality, so I suggest we create a spreadsheet of this form: ID Relationship Date Active Project Access johna Committer 1/19/2007 eclipse.e4,eclipse.platform, ...etc I can ensure that every committer ID in your spreadsheet and every ID that actually has commit access is included, so that committers to be removed look like this: ID Relationship Date Active Project Access vlad Committer 1/19/2007 <none> I think the webmasters should be able to create a script against such as listing to perform the actual Unix group membership modifications. Well, we had to have a starting point:-) I'll get together with Webmaster in the next day or so and see what we can come up. At this point we have clearly demonstrated even more reason to ensure this cleanup is achieved. We will be in touch. Regards, Sharon (In reply to comment #26) > Well, we had to have a starting point:-) > > I'll get together with Webmaster in the next day or so and see what we can come > up. > > At this point we have clearly demonstrated even more reason to ensure this > cleanup is achieved. > > We will be in touch. > Regards, > Sharon Ok, sounds good. I have no problem collecting the data on what the final end state should look like - what committers belong to what groups (sub-projects), etc. I do need an idea of what form that info should take, so that it will allow you to update both the foundation database and for the webmasters to perform the actual changes. Created attachment 182170 [details]
All Committers
Here is a list of all committers I can find. I started with your database list, and then added every member of all our Unix groups that wasn't already in your list. There are 202 ids here, vs the 169 ids in your attached spreadsheet. The 33 extra people are committers that should be deactivated because they are no longer active (I suspect the activity of these people predates the existence of the Eclipse Foundation).
> Here is a list of all committers I can find. I started with your database list,
> and then added every member of all our Unix groups that wasn't already in your
> list. There are 202 ids here, vs the 169 ids in your attached spreadsheet. The
> 33 extra people are committers that should be deactivated because they are no
> longer active (I suspect the activity of these people predates the existence of
> the Eclipse Foundation).
Can you attach that list as well?
While working with those lists is fine, we should do the following in parallel:
1. define an owner for each new ACL
2. let that owner name the active committers for that ACL
3. match it with the foundation list
Here are the ids that have commit rights but aren't in the foundation list. Note that perhaps these accounts are actually not active but they probably still need cleaning up: acovas airvine azerr btripkovic celek cknaus cmckillop cmclaren cwong davids dbirsan dkehn dkelley dpollock droberts dwilson eduardo eidsness ghoren gmendel greg ikhelifi jdeupree jgarms kcornell kdkelley khorne kkolosow kradloff mfaraj mvanmeek ptobias randyg sarsenau ssarkar tellison tmaeder twagner twidmer vlad winchest (In reply to comment #30) > Here are the ids that have commit rights but aren't in the foundation list. > Note that perhaps these accounts are actually not active but they probably > still need cleaning up: Some of them look like people that now work for a different company and they probably did not sign the Eclipse Committer Employer Consent Form. Hi Guys: One thing that I didn't mention when I provided the original spreadsheet was that if a committer had been decommitterized, I ommitted their id from the listing. I have performed a quick check on a couple of id's John provided in the 2nd attachment and this appears to explain the difference. I'll do another check to ensure the spreadsheet contains no omissions and respond accordingly. First and foremost we need a master listing. Then we should remove any committers that are no longer active if there are any. Matt and I had a brief discussion this morning. Once we have the master list, another approach may be to receive the requirements from the project side which we can then determine how best to implement. Thanks, Sharon Created attachment 182327 [details]
Eclipse Project Comitters
I've verified the list of 'diffs' provided.
With the exception of two committers, the rest do not hold valid unix accounts.
I've now included a new sheet in the workbook to identify those that do not hold unix accounts - "Deactivated Committers"!
I've added the two committers who do hold access but were not identified as such via the DB to the 'Committers' sheet. Please identify their correct project association as we will need to update our systems with that correct data. As they are both employees of an Eclipse Member with an MCA on file, there are no legal issues. My assumption is their access is historical.
Also, my understanding is that the current setup of the eclipse unix groups do not map automatically to the DB project associations. Therefore, I am not able to provide a different listing at this time.
I hope this helps.
Thanks,
Sharon
(In reply to comment #33) > I've added the two committers who do hold access but were not identified as > such via the DB to the 'Committers' sheet. Please identify their correct > project association as we will need to update our systems with that correct > data. As they are both employees of an Eclipse Member with an MCA on file, > there are no legal issues. My assumption is their access is historical. Yes their access is historical, and will likely be removed during this restructuring exercise. However for the time being, the closest mapping to your groups would be: gmendel Committer eclipse.platform.ui winchest Committer eclipse.platform.ui > Also, my understanding is that the current setup of the eclipse unix groups do > not map automatically to the DB project associations. Therefore, I am not able > to provide a different listing at this time. Yep, that lack of obvious mapping is the big reason for this exercise. We will provide a spreadsheet in the same format as yours, with our proposed associations for each committer to our new normalized group structure. We are gathering that data now. For reference, here is a link to a note that went out advising all committers about the change: http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg09035.html I also scraped the email addresses of all eclipse project committers and sent the same message to them directly. FYI, the following committer ids had invalid email addresses in the foundation database (email failed to deliver). akronenberg thallgren rherrmann tyeung kmaetzel jfogell bbiggs I had some replies directly to me. For transparency, here is what was sent to me and the changes I made: Steve Northover and Eike Stepper requested to be added back to eclipse.e4. They believe they may become active in the future. I added them back. Karice McIntyre stated that she was still active, but at the level of assisting in handling CQ's for the platform. I checked and she is indeed active in ipzilla so I added back her commit rights (because I don't want to start doing that for her! ;) kmaetzel -> kai-uwe_maetzel@us.ibm.com (In reply to comment #36) > kmaetzel -> kai-uwe_maetzel@us.ibm.com I've forwarded the note to him. (In reply to comment #35) I contacted > akronenberg artur dot kronenberg at web dot de > bbiggs billy dot biggs at eclipse dot org > thallgren thomas at tada dot se based on recent comments on the cross-project mailing list and bugzilla, without getting E-Mail failure messages. This leaves the following ID's with unknown E-Mail address: > rherrmann -- rherrmann at eclipsesource dot com -- delivery failure --> I contacted the RAP team based on this Aug 10 mailing list contribution: http://dev.eclipse.org/mhonarc/lists/rap-dev/msg00646.html > tyeung > jfogell -- jfogell at us dot ibm dot com -- delivery failure > FYI, the following committer ids had invalid
> email addresses in the foundation database (email failed to deliver).
I'm not sure how you got invalid email addresses from our Foundation database since you do not have access to it. If you examined the GECOS field from a shell on dev.eclipse.org, we've stopped using that long ago. We'll look into removing the email addresses from that field since it is maintained correctly in the LDAP mail attribute.
From the dev/build.eclipse.org shell, the proper way of getting someone's email address is:
ldapsearch -x -LLL 'uid=rherrmann' mail
As a side note, when webmaster sees a committer email bouncing (as a result of a mailing list bounce, or a password reset notice, or anything else), we forward the bounce to Sharon Corbett, who follows up with the committer to ensure our committer records are still correct.
(In reply to comment #39) > I'm not sure how you got invalid email addresses from our Foundation database > since you do not have access to it. cat committers.txt | xargs getent passwd | awk '{print $3}' | awk -F: '{printf $1; print ",";}' > committer-emails.txt Where committers.txt was pulled from the attached spreadsheet. Most of these emails seemed to work with a small set of exceptions. If those email addresses are bogus I guess removing the records entirely would make sense. Another update to the list: Nick Edgar emailed and said he is interested in remaining involved on platform.ui, so I added him back. Also Simon Chemouil is a very new committer on e4 but has not committed anything yet. He pinged on eclipse-dev and I added him back to the eclipse.e4 list. (In reply to comment #39) > > ldapsearch -x -LLL 'uid=rherrmann' mail > Cool. I quickly tried some of the problematic ID's, and the ldap query returned different (ie: seemingly more correct) E-Mail addresses than bugzilla has. John, are you going to try another mailing based on the updated E-Mail addresses? (In reply to comment #42) > Cool. I quickly tried some of the problematic ID's, and the ldap query returned > different (ie: seemingly more correct) E-Mail addresses than bugzilla has. > John, are you going to try another mailing based on the updated E-Mail > addresses? I have resent the message to a different set of email addresses for those people. I used the one in the ldap query, or addresses sent to me privately in cases where the ldap address was also incorrect. The only person missing is tyeung, who has the same invalid email address both in passwd and ldap. In the end I don't think it is imperative that every last person be reached. Personally I view this as a courtesy: if they have been inactive for two years, don't have valid emails on file with the foundation, and don't follow any mailing list, then removing them is probably the best course of action. webmasters, now that we have gathered and verified this data, it is important to proceed with the next steps as soon as possible. We have already had several elections this week, and manually maintaining this new data is going to be error prone. As mentioned in comment #15, the next steps are: 1) Create the new Unix groups 2) Add committers in these new Unix groups I will attach a file containing the new user->group data. It is in a format that should be easy to pipe through awk to automate the transition. Created attachment 183042 [details]
Commiter Ids to groups
Absolutely. As soon as you provide us with all the info, Sharon will do her paperwork checks and we'll get right on it. Sharon, the data is in a format that I thought would be useful for the webmasters. If you want the information in a different shape just let me know. Webmaster: I've verified the legal paperwork for those committers identified in attachment 183042 [details]. There are no barriers.
John: If I am understanding correctly, those that fall into the "diff" between the list we provided and attatchment 183042 will no longer continue to have access to a sub project under the Eclipse top level project. If that is true, may we proceed to remove their access ASAP?
Thanks,
Sharon
(In reply to comment #48) > John: If I am understanding correctly, those that fall into the "diff" between > the list we provided and attatchment 183042 will no longer continue to have > access to a sub project under the Eclipse top level project. If that is true, > may we proceed to remove their access ASAP? > > Thanks, > Sharon That is true. Can you please wait one more day though - I want to double check the data and make sure nothing is missing. Created attachment 183326 [details]
Committer Ids to groups v2
There is one update in this revision - after confirming directly with him, "darins" has also bee removed entirely.
You can proceed with enacting this now.
Thanks John. I have included the change regarding 'darins'. Also, please note the following folks will not be moving to the new ACLS as they are not Eclipse committers (haven't been for a while): kevinm khorne kent Regards, Sharon (In reply to comment #51) > Also, please note the following folks will not be moving to the new ACLS as > they are not Eclipse committers (haven't been for a while): > > kevinm > khorne > kent Ok. We left them in because there were involved until recently. But I suspect they don't have committer paperwork in place so they can't be committers. If they ever want to come back we can always hold a new election. Ok I've created and populated the new groups, and I just want to make sure everyone is ready before I script the ownership changes to cvs. Is there any reason to delay this? -M. (In reply to comment #53) > Ok I've created and populated the new groups, and I just want to make sure > everyone is ready before I script the ownership changes to cvs. Is there any > reason to delay this? I can't think of any. To be clear, I assume there will be two distinct steps: 1) chown the directories to the new groups 2) Remove the old Unix groups If so I suggest a little bit of breathing room between performing those two steps. I fully expect after 1) that there will be a small number of committers who discover they lost access to something by accident. Those could then be fixed up individually, but having the old group membership info for that committer would be handy to make sure we aren't granting commit rights they didn't already have access to. Ok I've changed the ownerships to match: http://wiki.eclipse.org/Eclipse/PMC/Unix_Groups/New_ACLS_By_Project , but there are a few straglers The following directories need new groups: jdt-doc-home/ org.eclipse.core.runtime.feature/ org.eclipse.swt.gtk.aix.ppc/ org.eclipse.swt.gtk.aix.ppc64/ org.eclipse.swt.gtk.hpux.ia64_32/ -M. (In reply to comment #55) > jdt-doc-home/ jdt-doc-home seems useless to me. It was created in 2001 but it has no content. I think this can just be deleted. Dani please confirm. The remaining directories have all been created since the mapping was first done. Please assign to groups as follows: org.eclipse.core.runtime.feature -> eclipse.platform.runtime org.eclipse.swt.gtk.aix.ppc -> eclipse.platform.swt org.eclipse.swt.gtk.aix.ppc64 -> eclipse.platform.swt org.eclipse.swt.gtk.hpux.ia64_32 -> eclipse.platform.swt Thanks Matt!! >jdt-doc-home seems useless to me. It was created in 2001 but it has no content.
>I think this can just be deleted. Dani please confirm.
There is and never was content in it. This can be deleted.
Since all the PMC and relevant foundation people are on the CC list, how should we handle the stragglers that only replied to my announcement *after* they realized they had lost their commit rights? Should we hold new elections, or just directly add them in here? I'm ok with just adding them back, but if there are committer paperwork changes involved maybe going through the normal election process is best. (In reply to comment #58) > Since all the PMC and relevant foundation people are on the CC list, how should > we handle the stragglers that only replied to my announcement *after* they > realized they had lost their commit rights? Should we hold new elections, or > just directly add them in here? I'm ok with just adding them back, but if there > are committer paperwork changes involved maybe going through the normal > election process is best. I think that going through the normal election process would be best. Point any complainers to me. (In reply to comment #59) > I think that going through the normal election process would be best. Point any > complainers to me. Ok, will do. I think the only remaining work here is the data that drives the portal (foundation committer database?). When I log into the portal, I still see some of the old groups such as plat-rel-core. The groups (sub-projects) in the portal should now match 1-1 with the list of unix groups listed here: http://wiki.eclipse.org/Eclipse/PMC/Unix_Groups#Proposed_new_ACLs That will allow us to conduct elections and manage the committers in each of these groups. (In reply to comment #60) > I think the only remaining work here is the data that drives the portal > (foundation committer database?). When I log into the portal, I still see some > of the old groups such as plat-rel-core. This should all be cleaned up now. -M. (In reply to comment #61) > This should all be cleaned up now. Does that change take awhile to propagate? Logging into the portal right now, I see the following projects in my "Committer On" list: eclipse -> Should not exist eclipse.e4 -> Good eclipse.incubator -> Should not exist eclipse.incubator.platform -> Should not exist eclipse.platform -> Good eclipse.platform.core -> Should not exist eclipse.platform.doc -> Should not exist eclipse.platform.plat-rel-core -> Should not exist eclipse.platform.team -> Group name is fine, but should not be a committer eclipse.platform.ui -> Good eclipse.platform.update -> Should not exist (In reply to comment #62) > > Does that change take awhile to propagate? The changes should be flushed out by now. > Logging into the portal right now, I > see the following projects in my "Committer On" list: > > eclipse -> Should not exist > eclipse.e4 -> Good > eclipse.incubator -> Should not exist > eclipse.incubator.platform -> Should not exist > eclipse.platform -> Good > eclipse.platform.core -> Should not exist > eclipse.platform.doc -> Should not exist > eclipse.platform.plat-rel-core -> Should not exist > eclipse.platform.team -> Group name is fine, but should not be a committer > eclipse.platform.ui -> Good > eclipse.platform.update -> Should not exist I'm not sure what you mean when you say 'Should not exist'. According to our internal project table those projects do exist and are active and you are listed as a committer on them, which is why they appear in that pane. If I understand you correctly you're saying the only 'Eclipse' project with an incubator is PDE? Wayne would you need to hold termination/archive reviews for these 'extra' projects? -M. (In reply to comment #63) > > eclipse.platform.plat-rel-core -> Should not exist > I'm not sure what you mean when you say 'Should not exist'. According to our > internal project table those projects do exist and are active and you are > listed as a committer on them, which is why they appear in that pane. What I'm saying is that your internal project table no longer corresponds with reality ;) (or has even less correspondence with reality than it did before). Take for example "eclipse.platform.plat-rel-core". There was never any "platform core release engineering" project. There was once a Unix group plat-rel-core, and I guess when the foundation was creating their internal database it was decided to call this a sub-project. There is no longer any such Unix group and therefore there is no code and no committers. Conversely, there is now an eclipse.platform.runtime Unix group and a set of projects in CVS owned by it. If I wanted to nominate a new committer on this sub-project, I wouldn't be able to because it doesn't appear in the portal. I thought the purpose of the spreadsheet setup by Sharon was so that the foundation database would be updated to match our actual project structure. I.e., when we are done, there would be exactly one "sub-project" appearing in the portal for each Unix group in our new list. See my comment #22. (In reply to comment #64) > What I'm saying is that your internal project table no longer corresponds with > reality ;) (or has even less correspondence with reality than it did before). Sharon, Matt, now that the Eclipse project has a specific (and manageable) set of unix groups, how can we make our Foundation projects list match reality? (In reply to comment #63) > > Wayne would you need to hold termination/archive reviews for these 'extra' > projects? No reviews are necessary. We are updating the database to match reality per Board resolution. Let me know what I need to do. The following projects/components exist in our database but were not mentioned in the remapping (thanks for assembling this list, Matt). I assume that some of these (eclipse.incubator.ufacekit comes immediately to mind) should stick around. Which, if any of these projects should go away as we wrap up this effort? eclipse.incubator eclipse.incubator.e4 eclipse.incubator.pde eclipse.incubator.platform eclipse.incubator.ufacekit eclipse.jdt.apt eclipse.jdt.doc eclipse.pde.api tools eclipse.pde.doc eclipse.pde.ds eclipse.platform.ant eclipse.platform.compare eclipse.platform.core eclipse.platform.doc eclipse.platform.plat-rel-core eclipse.platform.search eclipse.platform.update eclipse.platform.webdav Did we miss anything? Which project's committers have write access to the top-level project's website? Which project's committers have write access to the downloads area? As a result of this effort, we also need to add some new projects to align with the created groups (so that we can easily run elections and other project management stuff). eclipse.platform.resources eclipse.platform.runtime eclipse.platform.text eclipse.pde.incubator Is eclipse.pde.incubator really just eclipse.incubator.pde? (In reply to comment #67) > Which, if any of these projects should go away as we wrap up this effort? > > eclipse.incubator > eclipse.incubator.platform We realized that there was no active development in the generic Eclipse project incubator. All new incubation work is now done in e4. As such the generic "Eclipse Incubator" can go away. We should probably hold a move/termination/whatever review for this since it was formally created as a project. Wayne let me know what you think. > eclipse.incubator.e4 eclipse.incubator.e4 only existed as a temporary holding place while e4 was in its early proposal phase. There is no active code in that area and it is effectively merged with e4 at this time. So this sub-project can be removed now. > eclipse.incubator.pde This is now eclipse.pde.incubator. I vaguely remember when incubators were first introduced, there was some restriction that incubators couldn't be sub-projects. This required us to create the artificial shape of a single incubator that contained sub-projects for each of PDE/Platform/Equinox (at the time). This restriction no longer exists, so I think eclipse.pde.incubator is the more natural shape. This aligns with how that project has been operating since it was created - i.e., the PDE project lead oversaw efforts in the PDE incubator. > eclipse.incubator.ufacekit I'm embarrassed to say we completely missed UFaceKit in all of this work. I gathered the original list by looking at CVS, and I didn't even realize the Eclipse project had an SVN repository (which contains only UFaceKit). I have opened bug 330938 to discuss with Tom Schindl what to do with it. The most likely answer is that it moves under e4. > eclipse.jdt.apt > eclipse.jdt.doc > eclipse.pde.api tools > eclipse.pde.doc > eclipse.pde.ds > eclipse.platform.ant > eclipse.platform.compare > eclipse.platform.core > eclipse.platform.doc > eclipse.platform.plat-rel-core > eclipse.platform.search > eclipse.platform.update > eclipse.platform.webdav All of these can be removed. For the most part these groups didn't have enough committers to live on as independent sub-projects, so their code was folded into another sub-project. The exception is platform.core, which was split into platform.runtime and platform.resources to reflect the reality that these are really independent projects, with separate code, separate bugzilla components, and for the most part separate committer lists. The doc components now exists as directories with shared access among all relevant groups, as they are not really independent projects. > Did we miss anything? Probably ;) I can't think of anything else though. If we discover something that was missed we can always follow up separately. Other PMC members, please chime in if you see other projects in the portal that don't look right. > Which project's committers have write access to the top-level project's > website? eclipse.platform > Which project's committers have write access to the downloads area? eclipse.platform.releng > As a result of this effort, we also need to add some new projects to align with > the created groups (so that we can easily run elections and other project > management stuff). > > eclipse.platform.resources > eclipse.platform.runtime > eclipse.platform.text > eclipse.pde.incubator That looks right. Hi John: With some of the projects/components being terminated/archived, we have to consider that some CQs may need to be moved or marked obsolete depending on the project's requirements. I've taken a quick look and eclipse.incubator has CQs aligned with it. When you have a moment can you advise how you like to handle these. When I hear back from you I should be able to adjust accordingly in IPzilla. Regards, Sharon (In reply to comment #69) > I've taken a quick look and eclipse.incubator has CQs aligned with it. When > you have a moment can you advise how you like to handle these. When I hear back > from you I should be able to adjust accordingly in IPzilla. I have glanced through these, and I will comment on each one to indicate where it should be moved to. I have a question first though. Some of these entries are related to a very early prototype of e4 ideas that were put into CVS for the purpose of EclipseCon demos and as part of gathering community for the initial e4 work. If these dependencies or contributions never appeared in any release, and never will be, is it correct to mark these CQ's as withdrawn at this point? We probably still have some stale code in CVS that refer to them, but by leaving the CQ active it means it will appear in the IP log for future releases, which seems incorrect. Hi John: I'm happy to work from a list if that is easier for you. You can attach it to this bug. But either way will work. If content represented by a CQ had been checked into the repo, we would not mark that CQ as 'withdrawn' at a later date. Instead if the content is no longer in use, we would add one of two keywords to the relevant CQ(s): Obsolete: Obsolete and no longer in use Unused: Not currently used, but potentially may be in the future Adding either of these keywords effectively moves the CQ to a different place in the log. Regards, Sharon Created attachment 184179 [details] Mapping of CQ's from incubator I have attached a description of what should be done with all the incubator CQ's. Mostly this was UFaceKit and its dependencies, which we decided to move into eclipse.e4 (see bug 330938). There were a few stale entries related to early prototypes of e4 that should be moved to the eclipse.e4 bucket and marked obsolete. Thanks John! I've moved all CQs and made necessary changes as indicated. Sharon, as a next step in cleaning up our database, I'd like to remove the following projects.
> eclipse.jdt.apt
> eclipse.jdt.doc
> eclipse.pde.api tools
> eclipse.pde.doc
> eclipse.pde.ds
> eclipse.platform.ant
> eclipse.platform.compare
> eclipse.platform.core
> eclipse.platform.doc
> eclipse.platform.plat-rel-core
> eclipse.platform.search
> eclipse.platform.update
> eclipse.platform.webdav
Since these are all "components" in the EDP pre-2008 sense, a review is not required. AFAIK, the Eclipse PMC is fully aware of this.
None of these projects appear on the "Committer Ids to groups v2" attachment. What needs to be done on your end before we can shut these down?
Do you need additional information for those components that now become third level projects? Most of them don't appear yet on under 'Eclipse Project' on http://www.eclipse.org/projects/listofprojects.php. Also, most of them are missing the project lead info, e.g. http://www.eclipse.org/projects/project_summary.php?projectid=eclipse.jdt.ui. Do you have that information? (In reply to comment #75) > Do you need additional information for those components that now become third > level projects? Most of them don't appear yet on under 'Eclipse Project' on > http://www.eclipse.org/projects/listofprojects.php. > > Also, most of them are missing the project lead info, e.g. > http://www.eclipse.org/projects/project_summary.php?projectid=eclipse.jdt.ui. > Do you have that information? Traditional "components" didn't have project leads. As we turn these former components into proper projects, we'll need to nominate some people into those roles. Based on the groups provided by John, we need to turn the following from components into projects. To do this, we need to nominate/elect a PL. eclipse.platform.releng eclipse.platform.team eclipse.platform.ui eclipse.jdt.core eclipse.jdt.ui eclipse.pde.build eclipse.pde.ui From that same list, we now need the following new projects. Each of these will need a PL nominated/elected. eclipse.platform.resources eclipse.platform.runtime eclipse.platform.text The following projects already had a PL, so I've changed them into a projects. eclipse.platform.swt eclipse.platform.ua eclipse.incubator.pde Note that the Foundation database hasn't been correctly aligned with the committer lists yet. We're working on that. Note also that the following components are no longer required based on the new structure. These will all be retired. eclipse.jdt.apt eclipse.jdt.doc eclipse.pde.api tools eclipse.pde.doc eclipse.pde.ds eclipse.platform.ant eclipse.platform.compare eclipse.platform.core eclipse.platform.doc eclipse.platform.plat-rel-core eclipse.platform.search eclipse.platform.update eclipse.platform.webdav Speak now (or soon) if there's been an error. All these "new projects" are on the 3rd level. What if, for simplicity, they just inherit the PL from their respective 2nd level projects (eclipse.platform, eclipse.jdt, eclipse.pde respectively)? In most cases I think this reflects reality. I have entered bug 332159 about nominating project leads for third level projects. The group listing provided by John includes eclipse.pde.incubator. This is associated with the eclipse.incubator.pde project. For consistency sake, I think we should make these the same name. I'm inclined toward changing the project name to match the group name (i.e. eclipse.pde.incubator). Does that make sense? A +1 (or alternate suggestion) from the PMC and we'll make it so. (In reply to comment #79) > The group listing provided by John includes eclipse.pde.incubator. This is > associated with the eclipse.incubator.pde project. For consistency sake, I > think we should make these the same name. I'm inclined toward changing the > project name to match the group name (i.e. eclipse.pde.incubator). +1 This was intentional to make our names consistent. (In reply to comment #80) > (In reply to comment #79) > > The group listing provided by John includes eclipse.pde.incubator. This is > > associated with the eclipse.incubator.pde project. For consistency sake, I > > think we should make these the same name. I'm inclined toward changing the > > project name to match the group name (i.e. eclipse.pde.incubator). > > +1 > > This was intentional to make our names consistent. Webmaster, can you make this change in the database? Specifically, for eclipse.incubator.pde, change the name to "incubator" and the parent project to "eclipse.pde". There are six entries in the portal data as well that need to have their project id changed from eclipse.incubator.pde to eclipse.pde.incubator. Thanks in advance. Done. -M. Wayne, any update on the changes you describe in comment #76? All the changes you describe look correct to me. See bug 332159 for a list of component leads. It is important to wrap this up because we cannot hold elections against the new component structure until the foundation database and portal are updated with the new shape. (In reply to comment #83) > Wayne, any update on the changes you describe in comment #76? All the changes > you describe look correct to me. See bug 332159 for a list of component leads. > It is important to wrap this up because we cannot hold elections against the > new component structure until the foundation database and portal are updated > with the new shape. Matt already applied the committer changes. The committer lists look basically right to me. Is there something in particular that appears amiss? I don't currently have a PL for: eclipse.platform.releng eclipse.platform.resources eclipse.platform.runtime eclipse.platform.team eclipse.platform.text eclipse.jdt.core eclipse.jdt.ui eclipse.pde.build Sharon, I'd like to mark the following components as inactive. eclipse.jdt.apt eclipse.jdt.doc eclipse.pde.api tools eclipse.pde.doc eclipse.pde.ds eclipse.platform.ant eclipse.platform.compare eclipse.platform.core eclipse.platform.doc eclipse.platform.plat-rel-core eclipse.platform.search eclipse.platform.update eclipse.platform.webdav Some of these still have active committers. Is there anything that you need to do for those active committers before we shut down the project? I feel that the end of this is near :-) > I don't currently have a PL for: > > eclipse.platform.releng > eclipse.platform.resources > eclipse.platform.runtime > eclipse.platform.team > eclipse.platform.text > eclipse.jdt.core > eclipse.jdt.ui > eclipse.pde.build See bug 332159 comment 4. (In reply to comment #86) > > I don't currently have a PL for: > > > > eclipse.platform.releng > > eclipse.platform.resources > > eclipse.platform.runtime > > eclipse.platform.team > > eclipse.platform.text > > eclipse.jdt.core > > eclipse.jdt.ui > > eclipse.pde.build > > See bug 332159 comment 4. Ah, ok. The bug was marked FIXED, but the PLs wheren't in place. I've updated the database. (In reply to comment #85) > Some of these still have active committers. Is there anything that you need to > do for those active committers before we shut down the project? Nothing to do. There are active committers, but there should be no files left on eclipse.org belonging to those groups. I.e., they have a commit rights to a group that has no code or other content associated with it. It is possible you will discover there are some Unix accounts at that end that don't belong to any groups, but I believe Sharon already identified and deactivated the committer accounts in those cases. > I feel that the end of this is near :-) Yes! Thanks for all your help on finishing this up. (In reply to comment #88) > (In reply to comment #85) > > Some of these still have active committers. Is there anything that you need to > > do for those active committers before we shut down the project? > > Nothing to do. There are active committers, but there should be no files left > on eclipse.org belonging to those groups. I.e., they have a commit rights to a > group that has no code or other content associated with it. It is possible you > will discover there are some Unix accounts at that end that don't belong to any > groups, but I believe Sharon already identified and deactivated the committer > accounts in those cases. > > > I feel that the end of this is near :-) > > Yes! Thanks for all your help on finishing this up. Each of the listed projects has at least one committer who is still marked as active in our database. Sharon, if it's just a matter of fixing the database to reflect the reality that we've established, I can take care of that. i.e. I can deactivate each of these committers and mark the project as inactive if there are no other considerations. > Each of the listed projects has at least one committer who is still marked as
> active in our database.
>
> Sharon, if it's just a matter of fixing the database to reflect the reality
> that we've established, I can take care of that. i.e. I can deactivate each of
> these committers and mark the project as inactive if there are no other
> considerations.
Just to be clear, the only committer accounts that would need deactivating is anyone who no longer belongs to any projects once the deprecated projects are removed. The current state is that committers are listed as members of both the old and new projects. For example the portal shows that I belong to eclipse.platform.core, which no longer exists in our new organization. So, in your records I should be removed as a committer from eclipse.platform.core, but I will remain a committer on the new project names (eclipse.platform.runtime, etc).
Hi Wayne: Yes, the committers will need to be marked as inactive in the DB for the components being archived. As John indicates we should have determined all the stragglers previously. However, if anyone was missed, please let me know so that I can arrange removal of their unix account completely. Regards, Sharon (In reply to comment #91) > Yes, the committers will need to be marked as inactive in the DB for the > components being archived. > > As John indicates we should have determined all the stragglers previously. > However, if anyone was missed, please let me know so that I can arrange removal > of their unix account completely. AFAIK, the UNIX accounts have been taken care of. All that remains are some committers marked as active in these still-active components. Can I assume, then, that I can go ahead and mark these committers as inactive and then shut down the components? Yes (In reply to comment #85) > Sharon, I'd like to mark the following components as inactive. > > eclipse.jdt.apt > eclipse.jdt.doc > eclipse.pde.api tools > eclipse.pde.doc > eclipse.pde.ds > eclipse.platform.ant > eclipse.platform.compare > eclipse.platform.core > eclipse.platform.doc > eclipse.platform.plat-rel-core > eclipse.platform.search > eclipse.platform.update > eclipse.platform.webdav > > Some of these still have active committers. Is there anything that you need to > do for those active committers before we shut down the project? > > I feel that the end of this is near :-) All of these projects/components have now been marked inactive. Are we done yet? :-) >Are we done yet? :-)
Almost ;-)
The portal says that 'Text' has no active committers. This is wrong. It should at least show:
Markus Keller
Dani Megert
(In reply to comment #95) > >Are we done yet? :-) > Almost ;-) > > The portal says that 'Text' has no active committers. This is wrong. It should > at least show: > Markus Keller > Dani Megert The project does not list any 'source repository' in its metadata; that needs to be done for Dash to figure out who's doing what. > > The portal says that 'Text' has no active committers. This is wrong. It should > > at least show: > > Markus Keller > > Dani Megert > > The project does not list any 'source repository' in its metadata; that needs > to be done for Dash to figure out who's doing what. OK, done that. When will the committer list be updated? I also noticed that JDT Core is missing as sub-project of JDT in http://www.eclipse.org/projects/listofprojects.php. JDT Debug is correctly listed. And http://www.eclipse.org/projects/project_summary.php?projectid=eclipse.platform.ui lists Boris twice as leader. >I also noticed that JDT Core is missing as sub-project of JDT in
>http://www.eclipse.org/projects/listofprojects.php. JDT Debug is correctly
>listed.
Same for (JDT) UI.
Also,
Resources
Runtime
Text
should be listed as sub-projects under 'Eclipse Platform' (same level as e.g. SWT).
(In reply to comment #98) > >I also noticed that JDT Core is missing as sub-project of JDT in > >http://www.eclipse.org/projects/listofprojects.php. JDT Debug is correctly > >listed. > Same for (JDT) UI. > > Also, > Resources > Runtime > Text > should be listed as sub-projects under 'Eclipse Platform' (same level as e.g. > SWT). Some of the projects were still historically marked as "components". I've updated the records. While looking, I noticed that our database has some inconsistencies wrt parent projects. "eclipse.platform.text"'s parent is incorrectly specified as "eclipse"; it should be "eclipse.platform". I'll generate a full list of culprits and an update query. Webmaster,
The following query shows that there are four 'eclipse' projects with incorrect values in the ParentProjectID field:
SELECT ProjectID, ParentProjectID, substring_index(ProjectID, '.', 2) as CorrectParentID FROM Projects where ParentProjectID = 'eclipse' and ProjectID not regexp concat('^',ParentProjectID,'\.[^\.]+$')
I believe that we can fix this with the following SQL:
UPDATE Projects SET ParentProjectID=substring_index(ProjectID, '.', 2) where ParentProjectID = 'eclipse' and ProjectID not regexp concat('^',ParentProjectID,'\.[^\.]+$')
Any idea how this happened?
I've updated the Projects table as indicated. Not sure where the differentiation occurred. -M. Closing as fixed. -M. |