Derek (in his mentor role) and I are in search of a good name for the module that I'll develop during this Google Summer of Code. (...once again, as the directory in CVS will be recreated due to other reasons.) We need your input on this issue, as none of the options seems to be the ideal one. Objective of the module: To abstract the existing CVS integration into a separate API and an accompanying set of projects, so that we can more easily plug in other backends for different version control systems like Subversion, git, etc. Now, naming this thing is a bit hard, as there's no widely standardized term for these things which handle repositories and stuff. We can currently think of the following names for the module: - rcs.module / "Revision Control System API" Slightly suboptimal since there already is a revision control system that goes by the name of "RCS". As the predecessor of CVS, it's not very common these days, but people still use it. So when calling the module "RCS API" it might be mistaken for the original RCS. - vcs.module / "Version Control System API" Better, but the name is quite verbose. I'd personally prefer "Version Control API" because it's snappy and easy to grasp from the beginning. However, there are other drawbacks on this. - vc.module / "Version Control API" Fixes the previous issue, but occupies a top-level acronym ("VC") that is used for a common term like Venture Capitalists, selected indiviuals also think of Visual C when reading this acronym. So this screams for namespace clashes. Also, it doesn't immediately prompt associations for version control with most people, which is certainly the case for "VCS" or "RCS". - versioncontrol.module, and other long names Annoying as function prefixes in the code, I'd rather prefer short ones. - scm.module "Source Control Management API" Sounds reasonably good, looks reasonably good, but has the unfortunate drawback that it specializes on source control. There may be people though who use revision control for other stuff like client documents or config files, so this doesn't quite fit as well. - Other proposals? If you've got a good idea that we hadn't yet thought of, do tell us. Please chime in on this issue. The development list might not be the most fitting place for this discussion, but given that the feedback in the SoC group on the same issue wasn't all too extensive (say, none until I specifically promted my other mentor Andy) we thought it appropriate to bring this issue to the mailing list. What do you think would be the best name for this module? -- Jakob, SoC student