commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [site] Non-Maven web sites
Date Sun, 23 Nov 2003 15:57:12 GMT
robert burrell donkin wrote:
> On 22 Nov 2003, at 21:36, Phil Steitz wrote:
>> robert burrell donkin wrote:
> <snip>
>>> i'd personally find it very difficult to read all the commit mails 
>>> from all the components in jakarta-commons if we started storing the 
>>> sites in maven. this would raise questions about whether 
>>> jakarta-commons can be properly supervised.
>> It seems silly to me that "supervising" the site means reading HTML 
>> diffs.  The xdoc diffs contain all of the relevant changes and, like 
>> code changes, the best way to validate changes is to update and build 
>> locally. I understand the argument about disaster recovery, but there 
>> are other (standard) ways to deal with that.
> supervising the source code means reading all commit messages. the 
> ability to read each and every commit message from jakarta-commons is a 
> crucial part of supervision. the jakarta pmc is responsible for legal 
> oversight. it might seem silly to you but being able to effectively 
> review all changes is a crucial part of that oversight.
> as a jakarta-commons committer, you should really read every commit 
> email for each component that you're interested in. all commits are 
> approved collectively by lazy consensus. if you have any reservations 
> about any change, you can post a -1 against the cvs commit email. you 
> should definitely -1 if you see any content that may put the ASF at risk.

I do that now, Robert (always for [collections], [lang] and [primitives] 
and usually for several other components as well).  My standard approach 
is to first review the diffs and then build locally and verify 
(sometimes with a couple of days lag, unless I see something that I 
don't understand). I do the second step after each significant change, 
in any case at least once a week, reviewing the modified code in context 
and running all tests. Is this OK?

What I meant above was that for maven-generated html, the xdocs diffs 
give me at least a better picture of what the content change is than the 
(redundant, IMHO) HTML diffs. I use the same approach for these -- look 
at the xdoc diffs and then (maybe with a little latency) build locally 
to verify that the generated content looks good.

Sorry if my comments above indicated that I did not see the need to 
review and validate all code and web site content. I certainly did not 
mean that.


> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message