+1 On 7/5/05, robert burrell donkin <[EMAIL PROTECTED]> wrote: > 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] > >
-- Steven Caswell [EMAIL PROTECTED] Take back the web - http://www.mozilla.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
