Re: Wiki diffs

[jean-frederic clere]

Mark Thomas wrote:
> All,
> 
> I think the wiki is probably the best place to start drafting a new set
> of commit guidelines to cover what branches we have (and what state they
> are in), what is RTC, what is CTR, etc.

Great.

In the next steps we should create a ROADMAP the same way to define what
we are going to put in trunk ;-)

Cheers

Jean-Frederic

> 
> However, I didn't want to propose we use the wiki whilst we weren't
> getting wiki diffs on the dev list. I have just fixed this so, my
> suggestion is to use the wiki for this.
> 
> Once we have the agreed guidelines, we can add them to the Tomcat web
> pages, probably linked from get involved.
> 
> Mark
> 
> PS I would volunteer to write the first draft but I am meant to be on
> holiday and if I spend any more time on my laptop tonight, I am going to
> be in trouble ;)
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Review model final ?

[Remy Maucherat]

Hi,

After all these discussions, I think the review model as I proposed it 
puts commonly agreed development processes in black & white, which 
should help the project (while not hindering development in any way).


To address some points:
- It will do nothing to resolve ongoing conflicts, obviously, but in my 
mind it provides a strict mechanism to force discussions for possibly 
problematic changes (the root cause of the current issue is that the 
situation was left to rot for a few months, because the CTR process is a 
bit easy to abuse)
- The rules that are set are indeed common sense: it should have worked 
that way before (core changes should be discussed beforehand, and 
possibly risky ones should too); that's what I've been stating all along
- I don't understand where the idea of contesting vetoes as a first 
reflex came from, given the amount of patches that are veoted or 
disagreed with (much less than 1%; surely at least this amount of 
patches are so-so at best ...)
- I am a bit lost about where the thread went yesterday since I took a 
sday off, and I can't extract concrete stuff out of it (please try to 
post a bit less ;) )


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model final ?

[Jim Jagielski]

Remy Maucherat wrote:
> 
> Hi,
> 
> After all these discussions, I think the review model as I proposed it 
> puts commonly agreed development processes in black & white, which 
> should help the project (while not hindering development in any way).
> 

I think, after yesterday's marathon discussion, the methodology
crafted by Costin and I, which is pretty much a re-clarification
of normal ASF policies, addressed everyone's concerns. As such,
I think that is the model which should be accepted.

As noted in numerous Emails, your proposal was, in many ways,
normal ASF policies with some differences due to not understanding
all the normal aspects (like "formal review request")... Once
that was explained, I think, at least based on Costin's comments,
we have some sort of workable solution.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Jim Jagielski]

On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:



On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:


On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:



Just propose a polite way to move from the commit for a  
controversial

change ( i.e. when someone feels strongly it's going to the wrong
direction,
even
if technically code is ok ) to the majority and 3+1 process - and
we're
done.

As you know - some people are complaining that veto is abused ( and
that's
right ),
many Rs turn into flame wars and get personal - so the issue is how
to avoid

a technical code discussion for a non-technical or subjective  
issue.




First, it's important to recall that whether under CTR or RTC,
there is always Review. If people, after something has
been committed under CTR has issues with it, then
that is Reviewing it after all. We already discussed
technical voting, but what about "direction" or "vision"
review. Or, as you said in a previous Email:


... a polite way of  saying:

"Hey, nothing wrong with the code itself, but I don't think there
is enough
support from
the community for the direction you're going - could you confirm
that a
majority and
at least 3 people think it fits our goals ?"




That's still part of the review process... Vetoes are
there to prevent code from being committed, but not
all reviews are for the functional aspects of the
actual code but rather to determine how much support
there is for an implementation or feature... So I would
say that this is still a valid and expected part
of the R in *both* CTR and RTC.

The thing is, of course, one cannot veto code based
on non-technical reasons, but one can certainly review
it based on such reasons and ask for some guidance that
it makes sense. IMO, most of those types of cases
should fall into the following types:

   1. People who agree and will help support it,
  implement it, etc... (+1)
   2. People who don't care one way or another. (+0)
   3. People who don't like it, but hey, if it helps
  you out and there are other people behind it,
  I won't stand in your way. (-0.9)
   4. I don't like it and this is why. It would be
  a mistake. (-1)




+1

If possible, add 5 and 6:

5. I may like it, but as a module that is not enabled by default.

6. I may like it, but as a standalone module, easy to download and  
install,

but not bundled
in the base distro.



Assuming some sort of module impl exists, yes, of course.

Both 5 and 6 should be counted as -0.9 on the change itself, but  
as +0.9 if

the
concern is addressed.

Yes, if everyone understand this - and we stop using early commit/ 
lazy

consensus
 and veto to get around R by a larger set of people - big +1.

I  like CTR and having an official trunk where active development  
happens -
but I don't like the endless discussion about veto validity and  
some big

changes
made without consensus or consultation - that was the main reason  
I support

a partial RTC until people get used to the idea of getting a +3 for
important changes.

Costin



I think all this handles the obvious and some of the non-obvious
holes that had been in place...



I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).

   [ ] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Review model final ?

[Jim Jagielski]

On Sep 22, 2007, at 9:10 AM, Jim Jagielski wrote:


Remy Maucherat wrote:


Hi,

After all these discussions, I think the review model as I  
proposed it

puts commonly agreed development processes in black & white, which
should help the project (while not hindering development in any way).



I think, after yesterday's marathon discussion, the methodology
crafted by Costin and I, which is pretty much a re-clarification
of normal ASF policies, addressed everyone's concerns. As such,
I think that is the model which should be accepted.

As noted in numerous Emails, your proposal was, in many ways,
normal ASF policies with some differences due to not understanding
all the normal aspects (like "formal review request")... Once
that was explained, I think, at least based on Costin's comments,
we have some sort of workable solution.


I have call for a vote on the policy under the 'Review Model
Take 2' thread. In particular, it has been shown that the
normal ASF rules, as now clarified, are suitable to handle
the issues at hand, and, what with Tomcat being an ASF
project, we should follow those guidelines. No aspect
of the normal ASF rules invalidate your concerns nor
does your proposal add any capability not in line with
normal ASF rules as well.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Jim Jagielski]

On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote:



   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Yoav Shapira]

Hey,

On 9/22/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> [ X ] +1. Yes, the above works and addresses my concerns
> as well as the problems which started this whole
> thing.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43442] - mod_jk documentation modification

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43442


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-22 10:23 ---
Gerhardus,

you prepared the patch file between a file with unix line endings and one with
DOS line endings. As a consequence the patch includes every line of the file.
That way it is hard to tell, what was really changed, and applying the patch
e.g. on a unix system puts the file into the wrong line endings mode.

Please check, that the file gets checked out with your platforms native line
ending and don't change the line ending before doing the diff.

If you are using svn, this could be as easy as "svn checkout" to retrieve the
docs, and then after editing a file doing "svn diff".

As an example I took your patch, applied it, changed the line ending back end
produced a new patch, which I will now attach for reference.

Thank you for the docs fixes, I'll commit them in a couple of minutes.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43442] - mod_jk documentation modification

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43442


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #20863|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2007-09-22 10:26 ---
Created an attachment (id=20867)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20867&action=view)
Modified patch against xdocs/reference/workers.xml


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r578464 - /tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

[rjung]

Author: rjung
Date: Sat Sep 22 10:28:29 2007
New Revision: 578464

URL: http://svn.apache.org/viewvc?rev=578464&view=rev
Log:
Minor grammatical fixes to docs.
Contributed by Gerhardus Geldenhuis.

Modified:
tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

Modified: tomcat/connectors/trunk/jk/xdocs/reference/workers.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/reference/workers.xml?rev=578464&r1=578463&r2=578464&view=diff
==
--- tomcat/connectors/trunk/jk/xdocs/reference/workers.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/reference/workers.xml Sat Sep 22 10:28:29 
2007
@@ -242,18 +242,18 @@
 
 
 
-Socket timeout in seconds used for communication channel between JK and remote 
host.
-If remote host does not respond inside that timeout the JK will generate an 
error,
-and retry again. If set to value zero (default) the JK will wait for infinite
+Socket timeout in seconds used for the communication channel between JK and 
remote host.
+If the remote host does not respond inside the timeout specified, JK will 
generate an error,
+and retry again. If set to zero (default) JK will wait for an infinite amount 
of time
 on all socket operations.
 
 
 
 This directive should be used when you have a firewall between your webserver
-and the Tomcat engine, who tend to drop inactive connections. This flag will 
told Operating System
-to send KEEP_ALIVE message on inactive connections (interval 
depend on global OS settings,
-generally 120 minutes), and thus prevent the firewall to cut the connection.
-To enable keepalive set this property value to the True.
+and the Tomcat engine, who tend to drop inactive connections. This flag will 
tell the Operating System
+to send KEEP_ALIVE messages on inactive connections (interval 
depend on global OS settings,
+generally 120 minutes), and thus prevent the firewall to cut inactive 
connections.
+To enable keepalive set this property value to True.
 
 The problem with Firewall cutting inactive connections is that sometimes, 
neither webserver or Tomcat
 have information about the cut and couldn't handle it.
@@ -266,7 +266,7 @@
 It will limit the number of those connection that each web server child
 process can made.
 
-Connection pool size property is used only for multi threaded
+Connection pool size property is only used for multi threaded
 web servers such as Apache 2.0 (worker), IIS and Netscape. The 
connection_pool_size property
 should reflect the number of threads per child process. JK will discover
 the number of threads per child process on Apache 2 web server with worker-mpm 
and set



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Tim Funk]

Can we have a new VOTE with the six bullets (if it is that many - I'm 
losing track with all the responses).


I'm not quite sure what I'm voting for.

-Tim


I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).

   [ ] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r578466 - in /tomcat/tc6.0.x/trunk: java/org/apache/el/lang/FunctionMapperImpl.java webapps/docs/changelog.xml

[funkman]

Author: funkman
Date: Sat Sep 22 11:05:54 2007
New Revision: 578466

URL: http://svn.apache.org/viewvc?rev=578466&view=rev
Log:
bug 41797: CNFE/NPE thrown from function mapper when externalizing
Patch by Tuomas Kiviaho- tuomas.kiviahos at ikis fi


Modified:
tomcat/tc6.0.x/trunk/java/org/apache/el/lang/FunctionMapperImpl.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/java/org/apache/el/lang/FunctionMapperImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/el/lang/FunctionMapperImpl.java?rev=578466&r1=578465&r2=578466&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/el/lang/FunctionMapperImpl.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/el/lang/FunctionMapperImpl.java Sat 
Sep 22 11:05:54 2007
@@ -144,7 +144,7 @@
 public Method getMethod() {
 if (this.m == null) {
 try {
-Class t = Class.forName(this.owner);
+Class t = ReflectionUtil.forName(this.owner);
 Class[] p = ReflectionUtil.toTypeArray(this.types);
 this.m = t.getMethod(this.name, p);
 } catch (Exception e) {

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=578466&r1=578465&r2=578466&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Sat Sep 22 11:05:54 2007
@@ -98,6 +98,10 @@
 43338: Support '*' servlet-name mapping at filter-mapping.
 Patch provided by Keiichi Fujino. (pero)
   
+  
+41797: CNFE/NPE thrown from function mapper when 
externalizing
+Patch by Tuomas Kiviaho- tuomas.kiviahos at ikis fi
+  
 
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41797] - CNFE/NPE thrown from function mapper when externalizing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41797


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-09-22 11:06 ---
Patch attached was applied - marking as fixed - please confirm.

Committed revision 578466.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Jim Jagielski]

Here is the synopsis:

   o Existence of release and development branches
 in parallel with each other (dev are odd numbered,
 release are even numbered).
   o Development branches are CTR. If code or patches
 to this branch change the API, advanced warning
 is required even before the commit. It may be
 open to a vote if there is debate. Larger patches,
 as well as far-reaching patches should also be
 community gauged before implemented.
   o Release branches are RTC, with patches obtained
 from the development tree. Thus, backports refer
 to the SVN revision on the development tree which
 adds that feature.
   o Both branches have a STATUS file. For the release
 branch, STATUS is also used to note backport
 proposals.
   o Reviews are *always* appropriate. One can call
 for a formal review of a patch at any time.
   o Voting is via normal ASF rules.
   o Regarding large and/or API changing patches, use of
 a sandbox is recommended to allow for SVN history to
 be maintain, to encourage outside interest and
 involvement ("Hey, I'm working on Foo. Here is the
 SVN url. Come and help or at least follow along").
 This also allows for more complete understanding of
 the impacts before it reaches the dev branch.

As previously mentioned, this is simply detailed information
about normal ASF development mechanisms, with some SVN
best practices thrown in to ease the collaborative efforts.
(The numbering in the 1st bullet is not required, of course,
but parallel dev/release branches are key. It ensures that
no code enters release without 2 review phases: the 1st
via CTR in the development branch and the 2nd via RTC
when backported to the release branch).

On Sep 22, 2007, at 1:42 PM, Tim Funk wrote:

Can we have a new VOTE with the six bullets (if it is that many -  
I'm losing track with all the responses).


I'm not quite sure what I'm voting for.

-Tim


I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).
   [ ] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:
The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Tim Funk]

Jim Jagielski wrote:

   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41797] - CNFE/NPE thrown from function mapper when externalizing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41797


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2007-09-22 11:29 ---
The patch editing feature that I used wasn't as clear as it should have been.
This issue is now only partially completed, that is the CNFE has been fixed, but
NPE still remains. Comment number #3 is the result of patch edition containing
both aspects.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Remy Maucherat]

Jim Jagielski wrote:

   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:


My proposal was to put the principles forward clearly:
- core changes need to be discussed beforehand
- calls for review (or vetoes, which in the end are sometimes very 
similar) should be considered rather than exclusively spend time to 
determine if they are legitimate


[Your proposal generally has more constraints and is identical to 
Jean-Frédéric rejected proposal; great, thanks a lot :) My only (minor) 
reservation is the lack of real criterion for determining which patch 
should be discussed beforehand or put to review in the development 
branch, which creates a room for interpretation, hence some "artistic" 
feeling.]


Since you brought forward this reasonable compromise vote, I vote in 
favor of it. I will trust you to monitor the Tomcat project in the 
future [since you've apparently decided to increase your involvement in 
the project] to see that this is properly respected.


Anyway, thanks a lot for your decision and involvement. I trust you to 
see how to help resolve the little "differences" I have with Filip now :)


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Filip Hanik - Dev Lists]

this email is so unclean, I'm a bit confused on the exact bullets, mind 
posting a new thread?


Filip

Jim Jagielski wrote:


On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:



On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:


On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:




Just propose a polite way to move from the commit for a controversial
change ( i.e. when someone feels strongly it's going to the wrong
direction,
even
if technically code is ok ) to the majority and 3+1 process - and
we're
done.

As you know - some people are complaining that veto is abused ( and
that's
right ),
many Rs turn into flame wars and get personal - so the issue is how
to avoid

a technical code discussion for a non-technical or subjective issue.



First, it's important to recall that whether under CTR or RTC,
there is always Review. If people, after something has
been committed under CTR has issues with it, then
that is Reviewing it after all. We already discussed
technical voting, but what about "direction" or "vision"
review. Or, as you said in a previous Email:


... a polite way of  saying:

"Hey, nothing wrong with the code itself, but I don't think there
is enough
support from
the community for the direction you're going - could you confirm
that a
majority and
at least 3 people think it fits our goals ?"




That's still part of the review process... Vetoes are
there to prevent code from being committed, but not
all reviews are for the functional aspects of the
actual code but rather to determine how much support
there is for an implementation or feature... So I would
say that this is still a valid and expected part
of the R in *both* CTR and RTC.

The thing is, of course, one cannot veto code based
on non-technical reasons, but one can certainly review
it based on such reasons and ask for some guidance that
it makes sense. IMO, most of those types of cases
should fall into the following types:

   1. People who agree and will help support it,
  implement it, etc... (+1)
   2. People who don't care one way or another. (+0)
   3. People who don't like it, but hey, if it helps
  you out and there are other people behind it,
  I won't stand in your way. (-0.9)
   4. I don't like it and this is why. It would be
  a mistake. (-1)




+1

If possible, add 5 and 6:

5. I may like it, but as a module that is not enabled by default.

6. I may like it, but as a standalone module, easy to download and 
install,

but not bundled
in the base distro.



Assuming some sort of module impl exists, yes, of course.

Both 5 and 6 should be counted as -0.9 on the change itself, but as 
+0.9 if

the
concern is addressed.

Yes, if everyone understand this - and we stop using early commit/lazy
consensus
 and veto to get around R by a larger set of people - big +1.

I  like CTR and having an official trunk where active development 
happens -
but I don't like the endless discussion about veto validity and some 
big

changes
made without consensus or consultation - that was the main reason I 
support

a partial RTC until people get used to the idea of getting a +3 for
important changes.

Costin



I think all this handles the obvious and some of the non-obvious
holes that had been in place...



I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).

   [ ] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Costin Manolache]

+1

On 9/22/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote:
>
> >
> >[X] +1. Yes, the above works and addresses my concerns
> >as well as the problems which started this whole
> >thing.
> >[ ]  0. Whatever.
> >[ ] -1. The above does not work for the following reasons:
> >
> > The vote will run for 96 hours instead of the normal 72 because of
> > the weekend. Only binding votes will be counted, but non-binding
> > votes will be used to address wider concern/acceptance of
> > the proposal.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Filip Hanik - Dev Lists]

Jim Jagielski wrote:



   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.


Filip



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Jim Jagielski]

Remy Maucherat wrote:
> 
> Jim Jagielski wrote:
> >[X] +1. Yes, the above works and addresses my concerns
> >as well as the problems which started this whole
> >thing.
> >[ ]  0. Whatever.
> >[ ] -1. The above does not work for the following reasons:
> 
> My proposal was to put the principles forward clearly:
> - core changes need to be discussed beforehand
> - calls for review (or vetoes, which in the end are sometimes very 
> similar) should be considered rather than exclusively spend time to 
> determine if they are legitimate
> 

See the bulleted EMail which was in response to Tim's
request :)

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Remy Maucherat]

Jim Jagielski wrote:

Remy Maucherat wrote:

Jim Jagielski wrote:

   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:

My proposal was to put the principles forward clearly:
- core changes need to be discussed beforehand
- calls for review (or vetoes, which in the end are sometimes very 
similar) should be considered rather than exclusively spend time to 
determine if they are legitimate




See the bulleted EMail which was in response to Tim's
request :)


I thought paraphrasing a little bit would not hurt, and it explains my vote.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Mark Thomas]

Jim Jagielski wrote:
>[X] +1. Yes, the above works and addresses my concerns
>as well as the problems which started this whole
>thing.
>[ ]  0. Whatever.
>[ ] -1. The above does not work for the following reasons:
> 

With the following caveats:

- There is only one dev branch. I am -1 for creating separate dev
branches for 3.3.x, 4.1.x, 5.0.x and 5.5.x on the grounds it is too much
overhead for branches that are in maintenance mode where 99% of the
patches will be ported from 6.x

- Where a patch for 3, 4 or 5 is required that just doesn't make sense
in the dev branch then the patch is applied using RTC.

- We review this process in 3 months time to see if it is providing the
expected benefits without excessive overheads.

- We improve the "Which version?" web page to make clear which branches
are supported and at what level. I'll start a wiki page as a draft of this.

- The "Get involved" pages are updated to document this process

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Tomcat Wiki] Update of "FrontPage" by markt

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The following page has been changed by markt:
http://wiki.apache.org/tomcat/FrontPage

--
   
  
   * '''["GettingStarted"]''' - Getting started with Tomcat.
+  * '''["TomcatVersions"]''' - A list of every Tomcat version and its current 
status (draft).
   * '''["PoweredBy"]''' - A list of sites powered by Tomcat.
   * '''["Tomcat/Links"]''' - Useful Links.
   * '''["HowTo"]''' - How to as linked by the FAQ.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Tomcat Wiki] Update of "TomcatVersions" by markt

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The following page has been changed by markt:
http://wiki.apache.org/tomcat/TomcatVersions

New page:
= Draft =
To Do
 - Add new 6.x branches / releases
 - Resolve TBDs

= Template =
For each version provide the following information:
||Spec versions:||Servlet X.X, JSP Y.Y||
||Stable:||Yes/No||
||Enhancements:||Yes/No||
||Bug Fixes:||Yes/No||
||Security Fixes:||Yes/No||
||Listed on download pages||Yes/No||
||Release Manager:||None||

= Tomcat 4.0.x =
||Spec versions:||Servlet 2.3, JSP 1.2||
||Stable:||Yes||
||Enhancements:||No||
||Bug Fixes:||No||
||Security Fixes:||No||
||Listed on download pages||No||
||Release Manager:||None||

= Tomcat 4.1.x =
||Spec versions:||Servlet 2.3, JSP 1.2||
||Stable:||Yes||
||Enhancements:||No||
||Bug Fixes:||No||
||Security Fixes:||Yes||
||Listed on download pages||Yes||
||Release Manager:||Mark Thomas (markt)||

= Tomcat 5.0.x =
||Spec versions:||Servlet 2.4, JSP 2.0||
||Stable:||Yes||
||Enhancements:||No||
||Bug Fixes:||No||
||Security Fixes:||TBD - currently Yes||
||Listed on download pages||TBD - currently Yes||
||Release Manager:||TBD||

= Tomcat 5.5.x =
||Spec versions:||Servlet 2.4, JSP 2.0||
||Stable:||Yes||
||Enhancements:||TBD - currently ???||
||Bug Fixes:||Yes||
||Security Fixes:||Yes||
||Listed on download pages||Yes||
||Release Manager:||Filip Hanik (fhanik)||

= Tomcat 6.0.x =
||Spec versions:||Servlet 2.5, JSP 2.1||
||Stable:||Yes||
||Enhancements:||TBD - currently Yes||
||Bug Fixes:||Yes||
||Security Fixes:||Yes||
||Listed on download pages||Yes||
||Release Manager:||Remy Maucherat (remm)||

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Back to ASF Basics (Was: Re: Review model take 2)

[Mladen Turk]

Jim Jagielski wrote:



   [X] +1. Yes, the above works and addresses my concerns
   as well as the problems which started this whole
   thing.
   [ ]  0. Whatever.
   [ ] -1. The above does not work for the following reasons:



If voted (and it looks it will) we should put them somewhere
for easier future reference.
I already proposed
http://tomcat.apache.org/getinvolved.html or
http://tomcat.apache.org/svn.html

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]