Community
Participate
Working Groups
Currently each project must enter its own metadata in the portal. There is an "inherit" flag, but this causes *all* metadata to be inherited from the parent, regardless of whether some entries are redefined in a sub-project. With the introduction of arbitrarily nested projects, we need real fine-grained inheritance to make project metadata management possible. For example I may have ten sub-projects (components) that have separate mailing lists, but want to inherit all other data from the parent project. Today we must either inherit everything and list all mailing lists in the parent, or inherit nothing and copy all common metadata down into each of the sub-projects.
Moving to Phoenix.
Can this be implemented soon? Otherwise our sub-project metadata has lots of empty fields or we have to copy the information from the top-level project.
We're not planning to do this this quarter.
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.
I believe PMI is where it's at now.
I'm not convinced that this would be useful or desirable. For starters, the project hierarchy has been collapsed somewhat, so the problem is less. Further, I believe that we've moved on from projects being nothing more than a means of managing UNIX groups (if managing UNIX groups is the only reason that a project exists, we need to rethink the existence of the project). I think that it's completely reasonable to expect that every project have its own description and scope, so these should never be inherited. Likewise for source code repositories. I van see where we could make the argument that a project's build or downloads are inherited. In these cases, you can (and should) provide a textual description of the build/downloads with a pointer to the owner of the build. Anything that we might attempt to do automatically here is bound to just be plain wrong for at least a significant number of projects. Mailing lists, forums, and such can also reasonably be inherited. In these cases, it's not particularly difficult to just repeat the information. It might be an even better idea for us to add a text field for the "Contact Us" page that would let a project enter information that describes how the project leverages parent project resources for communication (or something like that). Or, maybe communication channels is a reasonable thing to just inherit. Maybe we should just *always* include the parent project's communication channels on a subproject's page. That sounds sort of useful. Open a bug if you agree. Closing as WONTFIX. Reopen if you think I've missed something important.
