You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2003/08/04 13:26:18 UTC
Re: Discussion of Cocoon TLP Guidelines
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....
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 :-)
> 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
> - basically do a sanity check of the lenghty Jakarta original and see
> what might be eradicated from it (less is more)
> - check voting guidelines
Look fine.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 14:03 Upayavira wrote:
> Minor typo:
>
> <note>"Lazy" means the action item has immediate tactic
> approval, and it is not necessary to tally the vote until a -1
> reply
> is posted. Once a -1 reply is posted, the vote must be tallied
> and
> reported before the action item is considered approved. All
> action-item votes are lazy except for a public release
> vote.</note>
>
> Surely tactic should read tacit:
Sure - will change.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Upayavira <uv...@upaya.co.uk>.
Minor typo:
<note>"Lazy" means the action item has immediate tactic
approval, and it is not necessary to tally the vote until a -1
reply
is posted. Once a -1 reply is posted, the vote must be tallied
and
reported before the action item is considered approved. All
action-item votes are lazy except for a public release
vote.</note>
Surely tactic should read tacit:
---From dictionary.com------------------
tac·it
1. Not spoken: indicated tacit approval by smiling and winking.
2a. Implied by or inferred from actions or statements: Management has
given its tacit approval to the plan.
2b. Law. Arising by operation of the law rather than through direct
expression.
3. Archaic. Not speaking; silent.
-----------
Regards, Upayavira
On Mon, 4 Aug 2003 13:26:18 +0200, "Christian Haul"
<ha...@dvs1.informatik.tu-darmstadt.de> said:
> 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....
>
> 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 :-)
>
> > 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
> > - basically do a sanity check of the lenghty Jakarta original and see
> > what might be eradicated from it (less is more)
>
> > - check voting guidelines
>
> Look fine.
>
> Chris.
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 13:26 Christian Haul wrote:
> 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 :-)
Sure.
>>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.
OK.
Thanks,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 14:02 Stefano Mazzocchi wrote:
>> 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.
Let's stick to contract or API changes of released versions requiring a
formal vote. New stuff - I honestly don't think so.
> the part that indicates what to do with patches is too much to place
> there. I would remove it.
OK - will look into that.
> the part of new subprojects as well. if somebody asks, we send them to
> incubation right away.
How does other people feel about this? Most commonly, an incubating
project needs a destination PMC, so we would be involved some way anyhow.
Thanks,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Steven Noels <st...@outerthought.org>.
On 4/08/2003 14:02 Stefano Mazzocchi wrote:
>>> - 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.
> the part of new subprojects as well. if somebody asks, we send them to
> incubation right away.
If the concept and process of incubation is properly defined and offers
more than bouncing off the ball to the incubating PMC, I would be
perfectly happy with that. So far, I think it is reasonable to say that
the Incubator is still FUD with the prospect of becoming something
valuable. Also, I loath to see projects being incubated without a clear
destination PMC in mind. While you are absolutely correct in theory,
practice is teaching us something else, so I'd like to discuss this
before moving either way. Off-loading work to a disfunctional project
isn't a way to get the work done. Closely collaborating with the
Incubator might be better, IMHO.
> well, too much mentioning of vetos, IMHO, but I can live with that.
Exactly - I will try and wordsmith along that way. Vetos are community
killers and a discourse of distrust.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Discussion of Cocoon TLP Guidelines
Posted by Stefano Mazzocchi <st...@apache.org>.
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.