Andrew C. Oliver wrote: > I'm -1 (non binding) on a seperate cocoon-docs module. > -Andy
PS note that I never talked about a *completely* separate module, but a hack to make doc committers have karma only to the xdocs dir of the xml-cocoon2 CVS module. > 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] > > > -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]