Indemnification of the PMC

2003-12-23 Thread Geir Magnusson Jr.
Here is the clearest description I've found.  It's by Roy Fielding, ex  
chair and board member of the ASF, and from all appearances, extremely  
knowledgeable in these matters.  It was posted here :

http://nagoya.apache.org/eyebrowse/ReadMsg? 
[EMAIL PROTECTED]msgNo=2642

Indemnification is a promise by the corporation to pay the legal
  expenses of an *individual* if that *individual* becomes subject
  to criminal or civil proceedings as a result of their actions
  under a role identified by the corporation, as long as such person
  acted in good faith and in a manner that such person reasonably
  believed to be in, or not be opposed to, the best interests of the
  corporation.  In other words, a member is only indemnified for
  their actions as a member (not much).  A director or officer is
  only indemnified for their actions as a director or within the
  scope of their mandate as an officer.  A PMC member is indemnified
  under the category of who is or was serving at the request of
  the corporation as an officer or director of another corporation,
  partnership, joint venture, trust or other enterprise and only
  to the extent of that enterprise (the project).  A committer
  who is not a PMC member is not authorized by the corporation to
  make decisions, and hence cannot act on behalf of the corporation,
  and thus is not indemnified by the corporation for those actions
  regardless of their status as a member, director, or officer.
  Likewise, we should all realize and understand that the ASF's
  ability to indemnify an individual is strictly limited to the
  assets held by the ASF.  Beyond that, we are on our own as far
  as personal liability.
  It is a far better defense that an outside entity cannot
  successfully sue an individual for damages due to a decision
  made by a PMC, so it is in everyone's best interests that all
  of the people voting on an issue be officially named as members
  of the PMC (or whatever entity is so defined by the bylaws).
So in summary, a PMC member is indemnified for activities done on  
behalf of the corporation.  I think that this would be limited to the  
official activities of the PMC - things done on behalf of the board for  
the ASF, such as oversight and releases - and not general day-to-day  
committer activities, such as technical discussion and personal code  
commits.  Of course, that will probably need to be clarified too.

However, the key thing to remember is that the indemnification is only  
up to the limit of the ASFs resources, which isn't much.  So try to  
keep the litigation to a minimum :)

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED] 
 

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


Re: Indemnification of the PMC

2003-12-23 Thread Geir Magnusson Jr.
Oh, and thanks to Noel for the links...

On Dec 23, 2003, at 6:49 AM, Geir Magnusson Jr. wrote:

Here is the clearest description I've found.  It's by Roy Fielding, ex  
chair and board member of the ASF, and from all appearances, extremely  
knowledgeable in these matters.  It was posted here :

http://nagoya.apache.org/eyebrowse/ReadMsg? 
[EMAIL PROTECTED]msgNo=2642

Indemnification is a promise by the corporation to pay the legal
  expenses of an *individual* if that *individual* becomes subject
  to criminal or civil proceedings as a result of their actions
  under a role identified by the corporation, as long as such  
person
  acted in good faith and in a manner that such person reasonably
  believed to be in, or not be opposed to, the best interests of  
the
  corporation.  In other words, a member is only indemnified for
  their actions as a member (not much).  A director or officer is
  only indemnified for their actions as a director or within the
  scope of their mandate as an officer.  A PMC member is  
indemnified
  under the category of who is or was serving at the request of
  the corporation as an officer or director of another corporation,
  partnership, joint venture, trust or other enterprise and only
  to the extent of that enterprise (the project).  A committer
  who is not a PMC member is not authorized by the corporation to
  make decisions, and hence cannot act on behalf of the  
corporation,
  and thus is not indemnified by the corporation for those actions
  regardless of their status as a member, director, or officer.

  Likewise, we should all realize and understand that the ASF's
  ability to indemnify an individual is strictly limited to the
  assets held by the ASF.  Beyond that, we are on our own as far
  as personal liability.
  It is a far better defense that an outside entity cannot
  successfully sue an individual for damages due to a decision
  made by a PMC, so it is in everyone's best interests that all
  of the people voting on an issue be officially named as members
  of the PMC (or whatever entity is so defined by the bylaws).
So in summary, a PMC member is indemnified for activities done on  
behalf of the corporation.  I think that this would be limited to the  
official activities of the PMC - things done on behalf of the board  
for the ASF, such as oversight and releases - and not general  
day-to-day committer activities, such as technical discussion and  
personal code commits.  Of course, that will probably need to be  
clarified too.

However, the key thing to remember is that the indemnification is only  
up to the limit of the ASFs resources, which isn't much.  So try to  
keep the litigation to a minimum :)

geir

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


cvs commit: jakarta-site2/xdocs/stylesheets project.xml

2003-12-23 Thread Tetsuya Kitahata
This message was too big for ezmlm...


tetsuya 2003/12/23 04:34:12

  Modified:docs index.html
   docs/site acknowledgements.html agreement.html binindex.html
bugs.html communication.html contact.html
contributing.html convert-to-mirror.html
cvsindex.html cvsonunix.html cvsonwin32.html
decisions.html dirlayout.html elsewhere-2003.html
elsewhere.html faqs.html getinvolved.html
guidelines.html guides.html idedev-rdeclipse.html
idedev-rdnetbeans.html idedev-rdtomcat.html
idedevelopers.html idiot.html
jakarta-site-tags-example.html
jakarta-site-tags.html jakarta-site2.html
jakarta-site2b.html jars.html jon.html
jspa-agreement.html jspa-position.html legal.html
library.html mail.html mail2.html management.html
methodology.html micromail.html mission.html
newbie.html newproject.html news-2000.html
news-2001.html news-2002.html news-2003.html
news.html os.html other-releases.html overview.html
packageversioning.html proposal.html roles.html
source.html sourceindex.html
understandingopensource.html vendors.html
versioning.html whoweare.html
   docs/site/news 200206.html 200207.html 200208.html
200209.html 200210.html 200211.html 200212.html
200301.html 200303.html 200305.html editor.html
index.html
   docs/site/pmc 01-01-17-meeting-minutes.html
01-01-17-pictures.html 01-03-19-meeting-agenda.html
01-03-19-meeting-irclog.html
01-03-19-meeting-summary.html
01-04-22-meeting-irclog.html
02-01-30-elections.html index.html
   xdocsindex.xml
   xdocs/site elsewhere.xml
   xdocs/stylesheets project.xml
  Log:
  Logging Services Project @ Apache Launched -- Log4j = Logging Services
snip/



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



cvs commit: jakarta-site2/xdocs/site elsewhere.xml

2003-12-23 Thread tetsuya
tetsuya 2003/12/23 04:42:58

  Modified:docs index.html
   docs/site elsewhere.html
   xdocsindex.xml
   xdocs/site elsewhere.xml
  Log:
  Logging Services Project @ Apache Launched -- Log4j = Logging Services
  
  Revision  ChangesPath
  1.352 +2 -2  jakarta-site2/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-site2/docs/index.html,v
  retrieving revision 1.351
  retrieving revision 1.352
  diff -u -r1.351 -r1.352
  --- index.html23 Dec 2003 12:34:06 -  1.351
  +++ index.html23 Dec 2003 12:42:58 -  1.352
  @@ -616,8 +616,8 @@
   lia href=#dbApache DB Project/a/li
   lia href=#httpdApache HTTP WebServer Project/a/li
   lia href=#incubatorApache Incubator Project/a/li
  -lia href=#loggingApache Logging Services Project/a/li
   lia href=#jamesApache James Project/a/li
  +lia href=#loggingApache Logging Services Project/a/li
   lia href=#mavenApache Maven Project/a/li
   lia href=#wsApache WebServices Project/a/li
   lia href=#xmlApache XML Project/a/li
  @@ -916,7 +916,7 @@
   /th
   th bgcolor=#039acc colspan= rowspan= 
valign=top align=left
   font color=#00 size=-1 face=arial,helvetica,sanserif
  -font color=#ffstronga name=james 
href=http://logging.apache.org/;Apache Logging Services Project/a/strong/font
  +font color=#ffstronga name=logging 
href=http://logging.apache.org/;Apache Logging Services Project/a/strong/font
   /font
   /th
   /tr
  
  
  
  1.107 +2 -2  jakarta-site2/docs/site/elsewhere.html
  
  Index: elsewhere.html
  ===
  RCS file: /home/cvs/jakarta-site2/docs/site/elsewhere.html,v
  retrieving revision 1.106
  retrieving revision 1.107
  diff -u -r1.106 -r1.107
  --- elsewhere.html23 Dec 2003 12:34:06 -  1.106
  +++ elsewhere.html23 Dec 2003 12:42:58 -  1.107
  @@ -199,9 +199,9 @@
   h318 December 2003 - Apache Logging Services Project Launched/h3
   /a
   p
  -The log4j developers are pleased to announce that the Board of
  +The a href=http://logging.apache.org/log4j/docs/;log4j/a developers are 
pleased to announce that the Board of
   Directors of the Apache Software Foundation unanimously passed a
  -resolution for the creation of the Apache Logging Services project. A
  +resolution for the creation of the a href=http://logging.apache.org/;Apache 
Logging Services project/a. A
   copy of the resolution can be found at:
   br /
   a 
href=http://nagoya.apache.org/wiki/apachewiki.cgi?LoggingApacheOrg/BoardResoluion;http://nagoya.apache.org/wiki/apachewiki.cgi?LoggingApacheOrg/BoardResoluion/a
  
  
  
  1.290 +2 -2  jakarta-site2/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v
  retrieving revision 1.289
  retrieving revision 1.290
  diff -u -r1.289 -r1.290
  --- index.xml 23 Dec 2003 12:34:12 -  1.289
  +++ index.xml 23 Dec 2003 12:42:58 -  1.290
  @@ -199,8 +199,8 @@
   lia href=#dbApache DB Project/a/li
   lia href=#httpdApache HTTP WebServer Project/a/li
   lia href=#incubatorApache Incubator Project/a/li
  -lia href=#loggingApache Logging Services Project/a/li
   lia href=#jamesApache James Project/a/li
  +lia href=#loggingApache Logging Services Project/a/li
   lia href=#mavenApache Maven Project/a/li
   lia href=#wsApache WebServices Project/a/li
   lia href=#xmlApache XML Project/a/li
  @@ -325,7 +325,7 @@
   /tr
   tr
   th/th
  -th align=centerfont color=#ffstronga name=james 
href=http://logging.apache.org/;Apache Logging Services 
Project/a/strong/font/th
  +th align=centerfont color=#ffstronga name=logging 
href=http://logging.apache.org/;Apache Logging Services 
Project/a/strong/font/th
   /tr
   tr
   td align=right valign=top
  
  
  
  1.70  +2 -2  jakarta-site2/xdocs/site/elsewhere.xml
  
  Index: elsewhere.xml
  ===
  RCS file: /home/cvs/jakarta-site2/xdocs/site/elsewhere.xml,v
  retrieving revision 1.69
  retrieving revision 1.70
  diff -u -r1.69 -r1.70
  --- elsewhere.xml 23 Dec 2003 12:34:12 -  1.69
  +++ elsewhere.xml 23 Dec 2003 12:42:58 -  1.70
  @@ -16,9 +16,9 @@
   h318 December 2003 - Apache Logging Services Project Launched/h3
   /a
   p
  -The log4j developers are pleased to announce that the Board of
  +The a href=http://logging.apache.org/log4j/docs/;log4j/a developers are 
pleased to announce that the Board of
   Directors of the Apache Software Foundation unanimously passed a
  -resolution for the creation of the Apache Logging Services project. A
  +resolution for the 

Re: [PROPOSAL] As it ever were

2003-12-23 Thread Ted Husted
 steward

The proposal is to expand the role of the moderator, rather than invent 
an overlapping role with similar responsibilities. If the volunteer is 
not up to task, then another volunteer can be sought. (Hence, the 
language about the Chair appointing another volunteer.) The idea is that 
they have *already* volunteered to moderate the list. If one individual 
doesn't want to volunteer, another can be found.

 delegate

The proposal does not delegate the board's responsibility. To be 
binding, anything voted on any DEV list would still need the a 3+ quorum 
of PMC members. PMC members would be voting on PMC business.

There is nothing anywhere that says all the PMC business has to take 
place on a single list. If PMC members want to subscribe to all the 
lists and monitor all the PMC business, that's their choice. Conversely, 
if PMC members want to abstain from the routine business surrounding a 
given codebase, they don't have to subscribe to that DEV list.

Meanwhile, through the steward's reports, the committee-at-large is 
being kept in the loop as to each subproject's big picture.

The proposal does the things.

* It realizes the fact that Jakarta doesn't have non-binding committers 
(meaning that all committers must become PMC members).

* It provides a clear mechanism for scoping the work of the PMC. The 
business of each subproject can be conducted by people who are in-touch 
with that subproject on that subproject's DEV list.

* It provides a clear channel for oversight.

The steward's reports are designed to ensure that someone is at least 
thinking about these matters on a regular basis. Since it's someone's 
role to report on these things, they are more likely to be reported. 
Some issues we had in the past would not be readily addressed, since all 
the committers will be on the PMC list. A PMC member won't have to go 
off and talk to a subproject and report back. The subproject 
committers can hash issues out on the PMC list, where other members can 
provide input. And, any committer/PMC-member who thought there *might* 
be a problem, can now bring it up directly on the PMC list, whether the 
steward brings it up or not.

-Ted.



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


Re: [PROPOSAL] As it ever were

2003-12-23 Thread Costin Manolache
Ted Husted wrote:
  steward

The proposal is to expand the role of the moderator, rather than invent 
an overlapping role with similar responsibilities. If the volunteer is 
not up to task, then another volunteer can be sought. (Hence, the 
language about the Chair appointing another volunteer.) The idea is that 
they have *already* volunteered to moderate the list. If one individual 
doesn't want to volunteer, another can be found.
They volunteer to moderate a mailing list, not send reports or be a 
sub-commitee secretary ( if sub-commitee would be allowed - which AFAIK 
is not ) :-)

My point was that there is no need for another role or hierarchy. 
Would we start organizing elections for mailing list moderator ?


  delegate

The proposal does not delegate the board's responsibility. To be 
binding, anything voted on any DEV list would still need the a 3+ quorum 
of PMC members. PMC members would be voting on PMC business.

There is nothing anywhere that says all the PMC business has to take 
place on a single list. If PMC members want to subscribe to all the 
lists and monitor all the PMC business, that's their choice. Conversely, 
if PMC members want to abstain from the routine business surrounding a 
given codebase, they don't have to subscribe to that DEV list.
I agree with that.
But keep in mind that any PMC member can subscribe to any jakarta 
mailing list he wants and vote or -1 if he sees a problem !

I still think that important votes should take place on jakarta pmc list 
- this will keep the entire PMC in the loop.


Meanwhile, through the steward's reports, the committee-at-large is 
being kept in the loop as to each subproject's big picture.

The proposal does the things.


What about changing from mail list moderator to the current release 
manager(s) ? Each codebase already has one ( or few ) release managers,
and they are already responsible for announcing releases and important
events.




* It realizes the fact that Jakarta doesn't have non-binding committers 
(meaning that all committers must become PMC members).
May. It is not mandatory.


* It provides a clear mechanism for scoping the work of the PMC. The 
business of each subproject can be conducted by people who are in-touch 
with that subproject on that subproject's DEV list.
+1 ( but votes should still be on [EMAIL PROTECTED] )


* It provides a clear channel for oversight.
+1



The steward's reports are designed to ensure that someone is at least 
thinking about these matters on a regular basis. Since it's someone's 
role to report on these things, they are more likely to be reported. 
Some issues we had in the past would not be readily addressed, since all 
the committers will be on the PMC list. A PMC member won't have to go 
off and talk to a subproject and report back. The subproject 
committers can hash issues out on the PMC list, where other members can 
provide input. And, any committer/PMC-member who thought there *might* 
be a problem, can now bring it up directly on the PMC list, whether the 
steward brings it up or not.
Well, a PMC member won't talk to a subproject - it may talk with 
fellow PMC members if he is not tracking that project.

Anyway - I think it's a good idea to have someone send reports, I just 
think that the release managers are a better choice. They are already 
responsible for making the proposal and vote for the release.

Costin



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


Re: [PROPOSAL] As it ever were

2003-12-23 Thread Ted Husted
 Make release managers the default stewards

Not every subproject has a clearly defined release manager. In Struts, 
we are even starting to have multiple people collaborate on the release 
manager role.

The key to oversight is persistence. Since it is not possible for every 
committee member to be personally aware of what's happening in every 
subproject, we need regular reports from someone who does -- just as the 
board needs regular reports from each chair.

We don't need for subprojects to have a chair, but we do need someone 
to tender regular reports as to the subproject's status. The keyword 
being regular.

The person making these reports should already have a working knowledge 
of the subproject and be able to report based on what they already know. 
Of course, what they know is based on reading and understanding the 
traffic on the lists.

Ideally, the DEV list moderator should also be someone who is plugged 
into the subproject. So, instead of starting out by creating two roles 
with overlapping responsibilities, I'm suggesting we try extending the 
list moderator's role first. List moderator is the only persistent role 
that must already exist for each subproject's DEV list.

In some cases, we may need to have different volunteers fulfilling each 
role. But, personally, I like to try making do with what we have before 
running out and creating something new.

I also don't want to get bogged down with finding a steward for each 
subproject. The DEV list moderators are there, so let's use them. If a 
list moderator doesn't want to steward, then I'm sure they can find 
someone who does. Hey, we all friends here. :)

The key point is that the chair, and its PMC, need consistent, reliable 
reports, so that the chair can report in turn to the board. We need each 
subproject to fulfill the responsibility of regular reporting by 
whatever means necessary. We also need to push that responsibility down 
to the subproject. The people working in the subproject are the only 
ones truly aware of its status.

Should we encourage subprojects to elect a steward? No. AFAIK, we 
don't elect roles like list moderator or release manager. People just 
step up and offer to do the job -- as it should be. But if a subproject 
wants to a elect a steward, or a list moderator, or a release manager. 
that's their business. All we need is for the job to get done.

-Ted.



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


Re: [PROPOSAL] As it ever were

2003-12-23 Thread Tetsuya Kitahata

On Tue, 23 Dec 2003 12:10:03 -0500
(Subject: Re: [PROPOSAL] As it ever were)
Ted Husted wrote:

   steward
 
 The proposal is to expand the role of the moderator, rather than
 invent an overlapping role with similar responsibilities. If the
 volunteer is not up to task, then another volunteer can be sought.
 (Hence, the language about the Chair appointing another volunteer.)
 The idea is that they have *already* volunteered to moderate the list.
 If one individual doesn't want to volunteer, another can be found.

You can check who is/are current moderator(s) of XX subproject,
by using the method which can be found at
/committers/docs/mailinglist-tips.txt (committers module)
'How to know Who is moderator of XX list / Number of subscribers'
section (resource.txt is also good)

You may post to the address which can be found there with this two
lines body -- 
===
[EMAIL PROTECTED]
gump
==(two lines)==

--

Hope this helps.

-- Tetsuya. ([EMAIL PROTECTED])



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



Re: [VOTE] ORO 2.0.8 maintenance release

2003-12-23 Thread Geir Magnusson Jr
+1

On Dec 23, 2003, at 8:39 PM, Daniel F. Savarese wrote:

I know now may not be the best time to have a vote, but I would ask
the PMC to vote on approving the release of jakarta-oro 2.0.8.
The current code base contains important bug fixes and has gone too
long without a public release.
[ ] +1  I approve the release of jakarta-oro version 2.0.8.
[ ] -1  I do not approve the release of jakarta-oro version 2.0.8.
This vote will last until the end of Saturday 27th, 2003 (72 hours
minus the Christmas holiday).  In accordance with
http://jakarta.apache.org/site/decisions.html, at least three binding
+1 votes are required for this vote to pass and the number of +1 votes
must exceed the number of -1 votes.  Non-PMC members are encouraged
to cast their non-binding votes (please indicate your vote is
non-binding to facilitate vote tabulation).
RELEASE INFORMATION:

The 2.0.8 release will be a maintenance release incorporating the  
following
changes since the 2.0.7 release made in January (taken from
http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content- 
type=text/plain):

 o examples moved to an examples package and com.oroinc migration tool
   moved to tools package.
 o Fixed bug whereby compiling an expression with
   Perl5Compiler.MULTILINE_MASK wasn't always having the proper effect
   with respect to the matching of $ even though
   Perl5Matcher.setMultiline(true) exhibited the proper behavior.  For
   example, the following input
 aaa bbb \n ccc ddd \n eee fff 
   should produce bbb , ddd , and fff  as matches for both the
   patterns \S+\s*$ and \S+ *$ when compiled with MULTILINE_MASK.
   Perl5Matcher was only producing the correct matches for the second
   pattern, producing only fff  as a match for the first pattern
   unless setMultiline(true) had been called.  This has now been fixed.
 o Fixed embarrassing bug whereby an expression like (A)(B)((C)(D))+
   when matched against input like ABCDE would produce matching groups
   of: A B  null D instead of A B CD C D.
These changes have been available to the public in the CVS repository
for testing since May 2003.  There are no outstanding/unresolved issue
reports for the code.
Daniel Savarese (dfs.apache.org) will serve as the release manager for
this release.  A release announcement will be sent to
{oro-dev,oro-user,[EMAIL PROTECTED]


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

--
Geir Magnusson Jr   203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [PROPOSAL] As it ever were

2003-12-23 Thread Henri Yandell

On Tue, 23 Dec 2003, Ted Husted wrote:

   Make release managers the default stewards

My suggestion:

Work out what people on the PMC are members of the PMC for. ie) I consider
myself a Taglibs and Commons developer [both umberella projects so not
great examples].

List which projects people are on the PMC for. These people are now
required to submit a report to the chair (PMC in general). Whether they
break it down further [ie) Commons], or choose one amongst themselves is
up to themselves.

So basically the PMC making a requirement of a part of their community to
be responsible for a part of their codebase.

Hen


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



[VOTE] ORO 2.0.8 maintenance release

2003-12-23 Thread Daniel F. Savarese

I know now may not be the best time to have a vote, but I would ask
the PMC to vote on approving the release of jakarta-oro 2.0.8.
The current code base contains important bug fixes and has gone too
long without a public release.

[ ] +1  I approve the release of jakarta-oro version 2.0.8.
[ ] -1  I do not approve the release of jakarta-oro version 2.0.8.

This vote will last until the end of Saturday 27th, 2003 (72 hours
minus the Christmas holiday).  In accordance with
http://jakarta.apache.org/site/decisions.html, at least three binding
+1 votes are required for this vote to pass and the number of +1 votes
must exceed the number of -1 votes.  Non-PMC members are encouraged
to cast their non-binding votes (please indicate your vote is
non-binding to facilitate vote tabulation).

RELEASE INFORMATION:

The 2.0.8 release will be a maintenance release incorporating the following
changes since the 2.0.7 release made in January (taken from
http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-type=text/plain):

 o examples moved to an examples package and com.oroinc migration tool
   moved to tools package.

 o Fixed bug whereby compiling an expression with
   Perl5Compiler.MULTILINE_MASK wasn't always having the proper effect
   with respect to the matching of $ even though
   Perl5Matcher.setMultiline(true) exhibited the proper behavior.  For
   example, the following input
 aaa bbb \n ccc ddd \n eee fff 
   should produce bbb , ddd , and fff  as matches for both the
   patterns \S+\s*$ and \S+ *$ when compiled with MULTILINE_MASK.
   Perl5Matcher was only producing the correct matches for the second
   pattern, producing only fff  as a match for the first pattern
   unless setMultiline(true) had been called.  This has now been fixed.

 o Fixed embarrassing bug whereby an expression like (A)(B)((C)(D))+
   when matched against input like ABCDE would produce matching groups
   of: A B  null D instead of A B CD C D.

These changes have been available to the public in the CVS repository
for testing since May 2003.  There are no outstanding/unresolved issue
reports for the code.

Daniel Savarese (dfs.apache.org) will serve as the release manager for
this release.  A release announcement will be sent to
{oro-dev,oro-user,[EMAIL PROTECTED]



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