there doesn't see any enthusiasm for those new ideas and no objections to phil's draft. i think we should go ahead and make the changes suggested by phil.
- robert On Sun, 2005-07-03 at 22:39 +0100, robert burrell donkin wrote: > On Sun, 2005-07-03 at 13:13 -0700, Phil Steitz wrote: > > Here is a stab at replacement text for 15, 17 and 18. > > great :) > > looks good but threw up some ideas... > > > 15-1 Any member of the community may propose a new package. To be > > accepted, a package proposal must receive majority approval of the > > subproject committers and at least one committer must volunteer to serve > > as an initial package team member. Proposals should identify the > > rationale for the package, its scope, its interaction with other > > packages and products, the <insert-subproject-name> resources, if any, > > to be created, the initial source from which the package is to be > > created, and the sponsoring committers. > > > > 15-2 The subproject will maintain an svn repository, referred to as the > > <i>sandbox</i>, as a workplace for new packages. Once approved, new > > packages must all begin in the sandbox. Any apache committer may > > contribute code directly to the sandbox and this code may form the > > initial source for new packages. Code from existing apache projects > > can, with the support of the contributing projects, also be imported > > directly into the sandbox. Finally, patches contributed incrementally > > by community members may be committed to the sandox by a subproject > > committer. If the initial source for a new package is from outside of > > apache, the new package must be brought into apache via the apache > > incubator. > > not sure but wonder whether we might need to tightening this last > sentence so that it can't be read as implying that having only a portion > of the initial source from external sources is ok. opinions? > > > 15-3 A majority vote among subproject commiters is required to > > "graduate" a package from the "sandbox" to become a proper package. Only > > proper packages may make releases. If a package remains in the sandbox > > for more than six months, a majority vote will be required to prevent > > its being archived from svn and removed from the subproject web site and > > any other public locations (e.g. nightly or continuous integration > > builds). Proper packages may not release code with dependencies on > > sandbox packages. > > 1. i wonder whether it'd be better to have bi-annual reviews to simplify > administration. in january, review all sandbox components which were > created before the previous july. could run them as a single vote. > > 2. i wonder whether we actually need to remove them from svn: just could > copy them into an archive directory. > > - robert > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
