On 3/15/06, Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > What makes a project with multiple codebases an umbrella is a gray > > area. > > I've posted *my* first-pass definition of the term: a TLP that > has no deliverable packages of its own, only from its subprojects. > There's no 'Apache Jakarta' package, so it's an umbrella. > There *is* an 'Apache HTTP Server' package, so that isn't. > Subject to exceptions, clarifications, and further refinements, > of course, but that's my working definition.
would jakarta have been any less an umbrella if three years ago we'd started rolling a huge jakarta.jar? my first pass definition is quite different: an umbrella is a project where there is the legal and formal organization structures do not coincide. symptoms include divisions between committers (sub-projects with separate karma and mailing lists) and the need for additional rules and management due to the inability to provide oversight over the entire codebase. IMO ken's comments do apply but in a slightly different context. jakarta also had the problem of a lack of scope and definition (in addition to the problems caused by being an umbrella). there is now a preference for tightly defined and scoped top level projects. the incubation process now bars projects without a defined scope so this shouldn't be something that needs to be worried about in the future. - robert
