> How about a compromise? Here is my proposal: > > Fork the metadata tree (perhaps putting the new one in SVN) and make it very clear that the gumpmeisters have no intention of maintaining the traditional metadata themselves (but anyone with commit priviledges may modify the traditional metadata if they so wish - the latter is no different to the way things are now). >
I think previous discussions prefers CVS (to SVN) so as not to force all potential Gump metadata maintainers (all committers) to learn SVN, until ASF has pretty much moved over. That said, we could have foked metadata in CVS, and code in SVN. This is what I proposed. > Whenever a project wants to switch from ant to maven builds, the gumpmeisters will strongly recommend that the equivalent traditional metadata is deleted from CVS, but the final decision will rest with the actual project team. This means that over time the traditional gump's view of the universe will shrink, but people can still make their private traditional gumps do whatever they want. Trouble is, take a few 'low level' projects out of the metadata and it all comes tumbling down.... > We state that Java gump is now in "sustaining" (or equivalent wording) - no new features will be added but we may choose to make critical bug fixes. Python gump is the version that people should be using. You proposal and mine are about the same, we just don't go back and touch/clean-up the 'traditional' metadata. Personally, I'd still call this retirement. > We leave retiring the traditional metadata until the Python performance problems have been addressed (congrats on the progress with this, by the way). Thanks. Wish me luck... regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
