Community
Participate
Working Groups
The portal sends an email warning to projects that have not scheduled a future release: -- Projects are required to keep meta data up to date using the MyFoundation Portal (http://portal.eclipse.org/). The following problems were found with this project's meta-data: * There is no next/future release of this project. All Eclipse projects must have a "next release" planned and scheduled -- Many projects roll a release up with their parent projects. Some parent projects act like containers and do not do releases themselves. There are three choices here: 1) Just stop checking for future releases and assume that the projects are doing the right thing; 2) Use more complex logic; or 3) Add additional switches to the project metadata For #2, a project with no future release of its own is okay if an ancestor has a future release, or if one (all?) of its subprojects have a future release. For #3, we could add switches to the metadata that allow a project to set a "release strategy" of "releases with parent", "has own releases", or "does not do releases". Given that we are currently working on an reimagining of the project management infrastructure, I'm inclined toward #1 with a slant toward #3 in the new software.
(In reply to comment #0) > ... I'm inclined toward #1 with a slant toward #3 in the new > software. I think this is the right approach. I'll also point out two "special cases" .. a) Orbit; we do not do "releases" in the normal EDP sense, we used to just fill in "June" of every year, but seemed a forced and b) Permanently incubating projects (e.g. WTP Incubator). It is nice to know what what a project's plans are ... and guess there are a few cases where this auto check might remind people that they had simply forgotten to fill in the plan metadata ... but ... seems more focus on the plan would be better than focus on the date. And, let PMCs, and community "police" the overall frequency of releases.
Marking this as for consideration in the new project management infrastructure.
A project release record in the PMI is attached to a specific project and can include zero or more subprojects. Is this good enough, or do we still need the flag for subprojects to set?
(In reply to comment #3) > A project release record in the PMI is attached to a specific project and > can include zero or more subprojects. Is this good enough, or do we still > need the flag for subprojects to set? If the sub-projects don't get the nag mail when the parent already has a plan, then yes.
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.
We've made this a more manual process now. The EMO seeks out projects that haven't released in a while and connects with the project lead directly. Technically FIXED.
