Community
Participate
Working Groups
The level of noise on cross-project-issues-dev@eclipse.org is getting to a point where it's becoming annoying. Note, I use "annoying" in the following meaning: - noise increases chance of missing important info - abuse as a quick way to get quality responses (eg., where is bundle XYZ comming from, how to configure Tycho, etc.) - valuable discussions happen in a smaller (not to say "closed") group cutting of the larger community (eg., incubation@eclipse.org) Therefore I've opened this request. I'd like to see "everything cross-project" renamed to "release-train something". The goal is to make it clear what the intention of the mailing list (and this Bugzilla component) is.
+1 for this proposal
As I mentioned on the call, I've been told that new projects are being told to join the cross-projects list, whether they are an IDE project or not. I think there is still a need for such a list. Maybe we can create a separate IDE release train list?
(In reply to Doug Schaefer from comment #2) > As I mentioned on the call, I've been told that new projects are being told > to join the cross-projects list, whether they are an IDE project or not. I > think there is still a need for such a list. That would be incubation@eclipse.org. Every new project should sign up there.
(In reply to Gunnar Wagenknecht from comment #3) > That would be incubation@eclipse.org. Every new project should sign up there. incubation is for project that feel like they're incubating and don't know better channels to reach for assistance. I don't think it fits the purpose of the current cross-project minus simrel. Before choosing the names of list and which one is supposed to do what, we probably need to sort out what lists are actually needed/useful and for which purpose: * cross-project-issues-dev is IMO a good list and well named. It's just "polluted" by SimRel stuff; but we definitely need a place where to get informed and allowed to answer about infrastructure, new technical constraints... I think this list fits this goal very well and as such, it should be kept. All committers should be recommended to join. * incubation is for incubating project that needs assistance in finding the entry-points. This list seems also right on point and useful, so no need to change it. As you have guessed, I'm more in favor of creating an ide-simultaneous-release@eclipse.org mailing-list (whose named should be aligned on the upcoming decision of Planning Council about the name). This list would cover the typical announces related to current SimRel and the IDE stack and the related discussions, rants, congratulations... This list would be mandatory for projects participating to IDE SimRel, just like the cross-project-issues-dev mailing-list is or used to be mandatory for projects participating to SimRel.
Just a couple of comments: 1) Renaming mailing lists has basically no support, so we'd be creating a new one. 2) Can we try to keep the new list name reasonably generic? simrel-issues perhaps? -M.
(In reply to Eclipse Webmaster from comment #5) > 2) Can we try to keep the new list name reasonably generic? simrel-issues > perhaps? This needs to scale with the different of release trains. There might be more than one in the future. Only one targeting the IDE.
I was never under the impression that the release train / simultaneous release is reserved for IDE components / tools. I'm sure that the categories "EclipseRT Target Platform Components", "Application Development Frameworks", and "Modeling" contain many components that do not primarily target an IDE. Has this changed now? Are these components forced off of the train now? I agree that the traffic on cross-project-issues-dev@eclipse.org increased over the years and that many threads are the result of some people being too lazy to figure out (and subscribe to) a more dedicated mailing list. I think it's okay to fight these occasional abuses with respective replies. We'd need criteria that are simple and concise, so that everybody can easily judge whether a post is adequate for the list, or not. For inadequate posts we could prepare a canned response that explains the problem, points to the criteria, and possibly some standard alternatives. FWIW., the level of traffic on cross-project-issues-dev annoys me not so much anymore since I've unsubscribed from that mailing list and registered a news account at Gmane: news://news.gmane.org:119/gmane.comp.ide.eclipse.cross.project
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/404.
