On Monday, Aug 4, 2003, at 13:26 Europe/Rome, Christian Haul wrote:
On 29.Jul.2003 -- 11:05 AM, Steven Noels wrote:Dear all,
I've just checked in a verbatim copy of the Jakarta Guidelines (located
at http://jakarta.apache.org/site/proposal.html) in the cocoon-site
module, that could serve as a starter to base our own project guidelines
upon. Before we became a TLP (top level project), we were supposed to
follow the XML TLP guidelines (which are currently under debate, a
decent RC can be found at
http://cvs.apache.org/viewcvs.cgi/xml-admin/ charter.txt?rev=1.14&content-type=text/vnd.viewcvs-markup),
but after reading both, I believe the Jakarta guidelines might be a good
foundation to start working from. The guidelines are supposed to regulate
the day-to-day operations of the Cocoon TLP, which of course includes any
existing and possible new subprojects.
So in an attempt to start the debate about the Cocoon TLP guidelines, I
copy/paste/search/replaced through the Jakarta set of guidelines, and
provide this as a starter for further discussions.
Our DRAFT version is located at
http://cvs.apache.org/viewcvs.cgi/cocoon-site/src/documentation/ content/xdocs/guidelines.xml?rev=1.1&content-type=text/vnd.viewcvs- markup
Thanks Steven, it reads quite good.
Two points in addition to Carsten's: It states that "new features" need to be voted before committing. I believe that this is either unpractical (and sure not happening ATM) or/and not precise enough. Perhaps "major new features" would be better, but then, what's "major"? OK, it's only a guideline....
I would say that "anything that changes the contracts" has to be voted. New features that are added sideways, don't (say scratchpad or scratchpad blocks). But anything that enter the trunk should be voted.
Second, I feel tieing it so close to cvs and in particular wincvs is a little bit too strict. I'm quite looking forward to switch to subversion at some point :-)
I totally agree. Our guidelines should be technology-agnostic (maybe referring to another page for this, just like we do for mail lists)
Some topics which, IMHO, need further debate are:
- PMC composition and rules for admitting new PMC members (currently,
any committer can self.propose() to become a member of the PMC, and any
committer is allowed on the PMC list - but we need to discuss, maybe
change and at the very least formalize this)
Honestly, I believe that self.propose() is a very good way of doing it. We should change this only when we encounter problems with this model. Therefore I suggest to change the paragraphs accordingly.
+1
- rules and guidelines for incubating projects, w.r.t. PMC participation, cohabitation with Incubator guidelines
I would say that we remove that paragraph and avoid dealing with it altogether.
- basically do a sanity check of the lenghty Jakarta original and see what might be eradicated from it (less is more)
the part that indicates what to do with patches is too much to place there. I would remove it.
the part of new subprojects as well. if somebody asks, we send them to incubation right away.
- check voting guidelines
Look fine.
well, too much mentioning of vetos, IMHO, but I can live with that.
-- Stefano.
