I'm -1 (non binding) on a seperate cocoon-docs module. -Andy
Nicola Ken Barozzi wrote: > Thanks to Andy and John for coming in :-) > > Morrison, John wrote: > >>> From: Sam Ruby [mailto:[EMAIL PROTECTED]] >> >> >> Hi Sam :) >> >> Andrew C. Oliver wrote: > > > > >>> > >>> > This is exactly the same kind of thing we want to do. Jon Stevens >>> > even said it was okay when I questioned if it was legitimate for >>> > lucene to do it ;-) >>> >>> It is also OK for cocoon to do it. >>> >>> This is all very straightforward. All that is needed is the name of >>> the cvs module (xml-cocoon-apps, perhaps?), >> >> >> I think it was agreed xml-cocoon-apps yes :) (+1) > > > Yes +1 > >>> where you would like the cvs commit messages to go >>> (xml-cocoon-cvs?), and who should be >> >> >> xml-cocoon-cvs is my favourite (+1), >> xml-cocoon-apps-cvs is the only other I can think of, > > > Till we have a single dev mailing list, we will have a single cvs > mailing list, as John says. > >>> granted karma (either by name or rule). >> >> >> Initially, everyone with xml-cocoon2 access I think. > > > +1 > > And then by vote on the the cocoon-dev list, by clearly stating if the > vote is for full cocoon karma (both CVSes) or only to the > cocoon-apps-cvs one. > >>> Subprojects are free to adapt the bylaws as appropriate for their >>> needs. All I would request is that they are clear, posted, and >>> auditable (e.g., votes are done on the mailing list). >> > > Here is a rewrite, anyone please modify it where important. > Then we will vote on it specifically, and then ask the pmc for the CVS > module and notify of the ratified addendum. > > An important NOTE: > > Reading the following mail it is quite evident that we should use a > CVS module with access to the documentation team. > IIRC it can be set up to link to the xml-cocoon rep, which means that > we can set up permissions for the xdocs dir to our documenters... is > it possible/auspicable? > > > > -oOo- > > > ---------------------------------------------- > * Xml.Apache Cocoon Sub-project bylaws addendum * > ---------------------------------------------- > > Communities > ------------- > The Cocoon community has decided to nurture child communities within > the Cocoon sub-project. > > These child communities have a more specific and narrow focus, and > have non-specific access to only a subset of the Cocoon Sub-project > resources. > > Committers on the father Cocoon Sub-project have automatic full access > to all the Cocoon Sub-project resources. > > Child Communities > ------------------ > Currently the Cocoon Sub-project has two child communities, with the > following goals, resource usage scope, and reference mailing list : > > Community: cocoon-docs > ----------------------- > > Goal > ---- > Create, organize and maintain the documentation > of the Cocoon Sub-project > > Specific Resources > ------------------ > cocoon-docs mailing list, bugzilla, xml-cocoon CVS access. > > Reference mailing list > ---------------------- > cocoon-docs > > Community: cocoon-apps > ----------------------- > > Goal > ---- > Create, organize and maintain applications based on > Cocoon. > > Specific Resources > ------------------ > xml-cocoon-apps CVS access > > > Reference mailing list > ---------------------- > cocoon-dev > > Repositories > ------------- > The Xml.Apache Cocoon Sub-project has the following CVS repositories: > > - xml-cocoon2 > > The repository containing the Cocoon program source code > > - xml-cocoon-apps > > The repository containing the applications managed by the > cocoon-apps child comminuty > > NOTE xml-cocoon is the 1.x branch repository, kept only for history > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
