cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Discussion of Cocoon TLP Guidelines
Date Mon, 04 Aug 2003 12:02:36 GMT

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 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
>> 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
>> 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.


>>  - 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  

>>  - 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.


View raw message