Community
Participate
Working Groups
It has been suggested that all projects have an eclipse.* top-level newsgroup. Today, newsgroups names are based on (mostly) the top-level PMC the project belongs to, e.g., eclipse.webtools.jst and eclipse.tools.cdt. There are advantages to this, such as having the name space indicate the project's PMC. There are disadvantages to this, such as requiring a newsgroup name change when a project moves from one PMC to another, e.g., from Technology (eclipse.technology.aspectj) to Tools (eclipse.tools.aspectj). Originally the top-level PMCs were conceived of as project maturity levels (Technology -> Tools -> Platform) but Eclipse has rapidly evolved away from this. Now the PMCs are technology areas. When the PMCs were maturity levels, the nested newsgroup names could be seen as indicating project maturity, but no longer. Thus the proposal that all projects have a top-level newsgroup name, e.g., eclipse.jst, eclipse.cdt, eclipse.aspectj, etc. Comments?
Be aware there is no "rename" feature on innd, and renaming a newsgroup is not an easy feat. This is why newsgroups to be renamed have been archived in favor of new groups at eclipse.org. innd is quite clunky this way, and if we were to attempt to rename all the newsgroups, I'd suggest we migrate away from NNTP newsgroups to a web-based forum. A few links: http://www.eyrie.org/~eagle/faqs/inn.html#S6.5 http://groups.google.ca/group/news.software.nntp/browse_thread/thread/2bf38d879a00d1ba/10bcce11209cdd4e?lnk=st&q=inn+rename+newsgroup&rnum=1&hl=en#10bcce11209cdd4e D.
The naming is all messed up in and around the Eclipse project and its subprojects. We should either a) make all NEW newsgroups be just eclipse.<tl or sub-project name> but leave current ones alone b) do (a) and actively rename all groups. c) continue with eclipse.<tl>.<sub> with the exception of the Eclipse project and its current and new sub projects. They curently follow the pattern eclipse.<sub-project> (e.g., eclipse.platform) Actively renaming all groups (b) seems like churn but does result in a consistent setup. a) is simple but will lead to the entire setup being inconsistent as new groups are added. c) leaves some inconsistency around the Eclipse newsgroups but is otherwise ok. It is brittle when things move but that happens very infrequently. +1 for c. If we eventually fix the Eclipse project's naming problem then the related subproject newgroups (e.g., Platform, Equinox, JDT, PDE) can be renamed to match the more general pattern. As for comment 1, I've never been a big fan of the web based forums but do agree if we end up renaming everything we can take the opportunity for some changes.
(In reply to comment #1) > Be aware there is no "rename" feature on innd, and renaming a newsgroup is not > an easy feat. This is why newsgroups to be renamed have been archived in favor > of new groups at eclipse.org. innd is quite clunky this way, and if we were to > attempt to rename all the newsgroups, I'd suggest we migrate away from NNTP > newsgroups to a web-based forum. -1 I don't think that a web-based forum is a valid migration path for NNTP. At least I prefere reading NNTP than all those web-based forums available. A web-based forum can't replace a newsreader. I don't know if there is a better NNTP server available.
I think the Foundation should move away from incubating all projects under the Technology PMC. It just doesn't scale well. Projects should be placed where you think they will end up, and the newsgroup should too. That won't totally eliminate moves but it will eliminate the biggest reason for them. And BTW, there haven't been very many moves to start with. -1 for changing newsgroup names. Since I started reading them with the web forum mirrors on EclipseZone.com I don't care what the names are anymore. EclipseZone will be mirroring *all* of the eclipse.org newsgroups and putting them in functional groups with nice long descriptive names. Even if that weren't an option, the dotted names give needed organization in my opinion. -1 to move away from NNTP. Regardless of what you pick there is going to be a vocal group that wants something else. I think NNTP is fine because content can be mirrored elsewhere easily and people are used to it. If the forums were only available in a web format, that would be tough to convert to some other form. The way it is now you can use a news reader, you can use a web browser, you can use email, you can use RSS, etc. It's very flexible.
Correcting the facts: re (c) in comment 2: the Eclipse project has one sub-project that, for grandfathered reasons, follows the eclipse.<sub-project> and that is eclipse.platform. All subsequence top-level and sub-projects have been following the Eclipse Naming Policy (http://www.eclipse.org/org/processes/project-naming-policy.html) which was proposed to, reviewed by, and then accepted by, the community. What we are discussing in this bug are two things: (1) a change to the Eclipse Naming Policy section labeled "Infrastructure > Newsgroups", and (2) whether or not existing newsgroups should be renamed to conform to such a change.
Regarding comment 4: the Foundation has already moved away from incubating all projects under the Technology PMC. There are already new incubating projects under WebTools and DSDP.
One more comment: not that we already use top-level names for all projects in the website URLs. For example, the Mylar sub-project of the Technology PMC uses http://www.eclipse.org/mylar/ rather than http://www.eclipse.org/technology/mylar. Why do we have one rule for naming newsgroups and another for URLs?
(In reply to comment #7) > Why do we have one rule for naming newsgroups and another for URLs? 1. Because Exhibit A* didn't exist back in 2001, when eclipse.org started. 2. Because Exhibit A* doesn't contain a rule for website names. * Exhibit A = http://www.eclipse.org/org/processes/project-naming-policy.html There are numerous naming conventions throughout eclipse.org -- some that are slowly ironing themselves out, others not. I think Exhibit A should be updated to include a convention for all the resources at eclipse.org, with a GrandFather clause that allows current resources to not be renamed for the sake of not breaking everything. I'm pretty strung up about making everything standard and consistent, so feel free to send me packing if some of these proposals are too "ambitious": CVS === Current: /cvsroot/toplevel/project/component for technology, /cvsroot/toplevel/component for eclipse, tools, webtools and others Proposed: /cvsroot/toplevel/project/component Web site ======== Current: www.eclipse.org/project for most, www.eclipse.org/toplevel/project for some exceptions (some eclipse projects, webtools project) Proposed: www.eclipse.org/toplevel/project Newsgroups ========== Current: eclipse.toplevel.project for most, eclipse.project for some exceptions Proposed: eclipse.toplevel.project Mailing lists ============= Current: project-listname (jdt-dev) Proposed: toplevel.project-listname (eclipse.jdt-dev) Downloads ========= Current: download.eclipse.org/toplevel/project for most, download.eclipse.org/downloads/drops for Platform (redirect to download.eclipse.org/toplevel/project) Proposed: download.eclipse.org/toplevel/project Bugzilla product names ====================== Current: Project (e.g. JDT) Proposed: toplevel.project (e.g. Eclipse.JDT) Wiki ==== It'll be here soon, so we should start this off on the right foot SubVersion ========== It's not here yet, but there are plans for an alternate Revision Control System, so we should plan ahead. E-mail aliases for committers ============================= Current: firstname.lastname@eclipse.org Proposed: no change proposed This is currently strictly enforced by strung-up webmasters. Infocenter help =============== Current: help.eclipse.org/helpXX, where XX is the version of Eclipse Currently only available for Eclipse projects, but bug 100635 proposes a contralized doc so we should plan ahead. Project vservers ================ Current: project.eclipse.org (e.g.: ecf.eclipse.org) Proposed: project.toplevel.eclipse.org (ecf.technology.eclipse.org) This is still relatively new... What am I missing? D.
(In reply to comment #8) > I'm pretty strung up about making everything standard and > consistent, so feel free to send me packing if some of these > proposals are too "ambitious": I also like the idee of make everything consistent but IMHO there should be only one rule: keep it simple. > CVS Proposed: /cvsroot/toplevel/project/component > WWW Proposed: www.eclipse.org/toplevel/project > NNTP Proposed: eclipse.toplevel.project > Lists Proposed: toplevel.project-listname (eclipse.jdt-dev) > Download Proposed: download.eclipse.org/toplevel/project > Bugzilla Proposed: toplevel.project (e.g. Eclipse.JDT) > Wiki > SubVersion > Email > Infocenter help > Project vservers As most of this looks clear to me, I feel that such a strict consitency is too complicated. Just a few thoughts: 1. I am one of those guys that remember a project by their "nick" name. I'm pretty sure there are more like me. Thus, it's absolutly inconvenient for me to type www.eclipse.org/toplevel/project as the URL. Mostly because it's too long and sometimes because I don't care about the toplevel the project is categorized in. I just want to find Mylar or GEF or JDT or the Platform. -1 for long URLs (WWW, wiki, downloads, whatever) -1 for long newsgroup names 2. I don't think that there will be ever two projects at Eclipse.org sharing the same project name but under different toplevel categories. 3. From my understanding a project can move from one toplevel to another. This means that everything (URLs, newsgroup, list and Bugzilla names) needs to be changed. If I would have the choice, I would try to drop the toplevel name everywhere. It's just a categorization/tagging that is useful within the various Eclipse processes. However, I don't think that uses will actually care.
Something I forgot to say: (In reply to comment #8) > Bugzilla product names > ====================== > Current: Project (e.g. JDT) > > Proposed: toplevel.project (e.g. Eclipse.JDT) Bugzilla 2.20 allows categorization of products. IMHO this fits better than complicated product names, which might make some lists look cluttered. > Wiki > ==== I assume that there will be a relation to WWW, i.e. www.eclipse.org/mylar wiki.eclipse.org/mylar download.eclipse.org/mylar svn.eclipse.org/mylar cvs.eclipse.org/mylar
(In reply to comment #9) +1 Keep it simple and eliminate top-level names. Few people really understand what is in what TL project or why it matters and sub projects definitely move around. That is how we got this bug report in the first place!
Re: comment 11 - eliminating hierarchical names because "few people understand what a top-level project is" is one potential solution. Another solution would be to make top-level projects truely effective. In fact, a counter-argument would be that we need to keep hierarchical names because we need to make the top-level projects more prominent. Summarizing the dicussion in this bug so far, we have 5 of the 500 committers expressing an opinion (that's 1%; not really a mandate in any way) and the opinion appears to be: * Everyone is for consistency * It's 50-50 as to whether consistency involves eliminating top-level.sub-project or including top-level.sub-project
A decision here will impact bug 116615.
A year without comment... Do we want to do anything with the newsgroups, keeping in mind that shuffling newsgroups around will be very disruptive? Change: +2 (Bjorn, Jeff) No change: -2 (Denis, Ed)
Withdrawing this bug due to a lack of interest by the community - I blogged about it (http://eclipse-projects.blogspot.com/2005/10/newsgroup-names.html), a year has gone by, indifference (http://www.despair.com/indifference.html), oh well, ...
closing
