Re: lists that don't require subscriber approval

2001-09-06 Thread Pier Fumagalli

Brian Behlendorf [EMAIL PROTECTED] wrote:
 
 this didn't seem to go through yesterday

It did :)

 -- Forwarded message --
 Date: Tue, 4 Sep 2001 19:24:32 -0700 (PDT)
 From: Brian Behlendorf [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Subject: lists that don't require subscriber approval
 
 Today, the tomcat-user list was spammed by an errant mailer-daemon out
 there that sent out nearly 300 email messages to the rest of the list.
 There are 1091 subscribers to that list, so 300K messages were sent out -
 or nearly that many, as Pier told me about it and I shut down qmail,
 removed the offending messages from the queue (after a half hour of grep
 and awk action to identify those bad messages and nuke them).  That was
 not fun, and it was a good thing I was back from Burningman today and
 could fix it, or all mail for apache.org would have been fuct for
 potentially days.

As I said, as soon as I noticed, I unsubbed anyone from that domain from all
mailing lists (thinking it was a some sort of auto reply to each single
message posted on the list). When I noticed that even after unsubbing those
guys I was still flooded by messages, I created the deny mail from list of
addresses and put that email address in there, but the queue was already WAY
backlogged... And I contacted Brian on the spot...

(BTW, I didn't create that mailing list, and I don't know who did it, I just
noticed what was happening, but - hey - it's not by fault! :)

 This was possible only because the mailing list was running with the -MU
 options set to ezmlm - which means basically anyone can post.  If that's
 changed to -mu, it changes the behavior of the list to subscribers can
 post, non-subscribers have their messages bounced to the moderators for
 approval.  I really really really recommend all lists run this option -
 the only place where I can see it not being appropriate are lists that
 intentionally welcome posts from outsiders, such as [EMAIL PROTECTED],
 where bouncing or delaying such a message would potentially be a serious
 problem.  Any list larger than a few people should have -mu set.

Agreed...

 Currently, the following lists have -MU set, and really should be
 reconsidered:
 
 bugs

Hmmm... This is unused... I would suggest converting it to an alias to
[EMAIL PROTECTED], and I would like to have a couple of volunteers to help
me out on that...

 jakarta-commons (which should be renamed to commons, btw)

[EMAIL PROTECTED], to be exact... I can go ahead and do the
conversion of the actual ML, and put [EMAIL PROTECTED] as
an alias for that list...

 library-dev

There's no whatsoever traffic on that list... I don't know what's it all
about even IF I am listed as the owner of it... Either someone claims its
usefulness (only spam received on that list since months), or I'll just
remove it.

 pmc

This is a small list... Could remain open, as we want anyone to be able to
post to the PMC, and subscription is (I believe) moderated...

 servletapi-dev

I propose collapsing this one with tomcat-dev... Servlet API and Tomcat are
more or less the same thing, and keeping a mailing list only for CVS
putbacks is (IMO) wrong... Also because I would love to see those putbacks
on the tomcat-dev mailing list, where they are more relevant...

 slide-dev
 slide-user

Moderator for those two too... (Remy?)

 struts-dev
 struts-user

Moderator for those two should be Craig :)

 taglibs-dev

And for this one too (Craig? :)

 The following lists are set to -mU, which means all messages are
 moderated:
 
 announcements

That should stay as-is...

 taglibs-user (this I don't understand)

I'm going to change this one to be -mu...

 Let me know if I can make this change.

I and Craig can take care of changing moderations/options for the lists, The
only thing you should do is check out that archives are generated correctly.

Things I also noticed:

- cactus-user

I don't know what this is all about... There is no archive, cactus is
related to the commons project, so, it should be really a
commons-user@jakarta...

- check-dev

No traffic since october 1999... I propose to erase this one...

- docs

This seems to be unused... I can't see any relevant traffic but various spam
on the archives...

- josper-dev

I believe this was erroneously created (josper? It's JASPER! :) Blast it

- watchdog-dev

It should be treated (IMO) as servletapi-dev... Collapse it with tomcat-dev.

To sum up:

Lists to moderate:
- slide-dev (Remy)
- slide-user (Remy)
- struts-dev (Craig)
- struts-user (Craig)
- taglibs-dev (Craig)

Lists to nuke:
- bugs
- library-dev
- check-dev
- docs
- josper-dev

Lists to rename:
- jakarta-commons (commons-dev)
- cactus-user (commons-user or commons-cactus-user)
- servletapi-dev (collapse into tomcat-dev)
- watchdog-dev (collapse into tomcat-dev)

Lists to modify (-mu instead of -mU):
- taglibs-user (Get me off moderation for this one please!)

Please advise (ASAP, please)...

Pier (CCing general@jakarta since there 

Re: lists that don't require subscriber approval

2001-09-06 Thread Peter Donald

On Thu, 6 Sep 2001 23:44, Pier Fumagalli wrote:
 Things I also noticed:

 - cactus-user

 I don't know what this is all about... There is no archive, cactus is
 related to the commons project, so, it should be really a
 commons-user@jakarta...

I think when it was initially voted on it was to be named 
commons-cactus-user@ or commons-cactus@ or similar. Not sure what 
happened though. The reason for keeping it separate was that it was 
generating a fair number of messages that most commons users didn't want to 
see ;)

-- 
Cheers,

Pete


 Beer is proof that God loves us and wants 
 us to be happy. -- Benjamin Franklin


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




Re: lists that don't require subscriber approval

2001-09-06 Thread Vincent Massol


- Original Message -
From: Peter Donald [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, September 06, 2001 2:45 PM
Subject: Re: lists that don't require subscriber approval


 On Thu, 6 Sep 2001 23:44, Pier Fumagalli wrote:
  Things I also noticed:
 
  - cactus-user
 
  I don't know what this is all about... There is no archive, cactus is
  related to the commons project, so, it should be really a
  commons-user@jakarta...

 I think when it was initially voted on it was to be named
 commons-cactus-user@ or commons-cactus@ or similar. Not sure
what
 happened though. The reason for keeping it separate was that it was
 generating a fair number of messages that most commons users didn't want
to
 see ;)


You're right. The name [EMAIL PROTECTED] was the voted
name. I seem to remember that the list name was changed at the last minute
to be cactus-user@... because there was the intention to make Cactus a root
project in the future and a name change being a major change it was
preferred to name right away cactus-user@... However, you're right and I
don't think it was done in a orderly manner and I don't remember any voting
on the subject.

Maybe now is the right time to vote for making Cactus a top level project ?
Are there conditions for that (like number of hits,downloads, community) ?
Who decides, PMC members ?

Thanks
-Vincent Massol



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




Re: lists that don't require subscriber approval

2001-09-06 Thread Pier Fumagalli

Vincent Massol [EMAIL PROTECTED] wrote:
 
 just sent a request for vote now on [EMAIL PROTECTED] ...
 :)

Since you're at it already, can you please also tell them that I'm going to
change the mailing list name from [EMAIL PROTECTED] to
[EMAIL PROTECTED] ? :)

Let me know...

Pier


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




Re: lists that don't require subscriber approval

2001-09-06 Thread Jon Stevens

on 9/6/01 7:45 AM, Pier Fumagalli [EMAIL PROTECTED] wrote:

 Sam Ruby [EMAIL PROTECTED] wrote:
 
 P.S.  Perhaps the right fix here is to create a jakarta-cactus subproject.
 
 Agreed... I would kindly ask to the Jakarta-Commons people, to vote on
 making Cactus become a top-level subproject of Jakarta, we'll move from
 there...
 
   Pier

Or:

jakarta-commons-cactus

-jon (who is enjoying the current low creation rate of top level projects)



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




Standardizing build.xml files

2001-09-06 Thread Berin Loritsch

I propose that we all use a standard target convention for
all Ant based projects.  This is something that helps adopters
of GNU software all over.  A person who has never seen GNOME
or GCC knows they can compile it by running ./configure
and make all check install.  These conventions make it
easier for the newbie to come up to a fresh project and
get it to compile.

One of the reasons I have come up with the proposal is that
every project has its own conventions.  I have been involved
in at least seven Apache projects in some capacity or another
and have contributed code to four of them.  They each have
different conventions.  One of the ways I work is building
the project completely fresh before testing--I uncover more
bugs that way.  I would very much like to run ./build clean all
but most projects have a different target name for the default
build target.  Already most projects use the following target
names: clean, docs, dist, and javadocs.  Most clean
targets leave some artifacts behind, and only a couple projects
have the concept of distclean.

I propose we borrow a number of conventions from the GNU
make utility manual
(http://www.gnu.org/manual/make-3.79.1/html_chapter/make_14.html).

If a program can be installed, then a build file must
use these properties (which can be overridden by a user's
.antrc file).  The properties and default values follow:

* install.dir=.
* install.bin.dir=${install.dir}/bin
* install.lib.dir=${install.dir}/lib
* install.data.dir=${install.dir}/conf
* install.doc.dir=${install.dir}/docs

By using these properties, Ant is able to customize how the
program is installed and filter the scripts to point to the
proper jars, etc.

The standard targets I propose we all adopt are similar to
the Make utility conventions ('all' is the default target):

'all'
Compiles the program with debugging enabled by default.
This target is not required to build documentation.  Standard
compilation properties and defaults are:
* build.debug=on
* build.optimize=off
'install'
This target ensures that everything is built, including
documentation.  It then copies the files in the corresponding
directories already mentioned above.  All jars should be
considered libraries, and scripts should be provided to run
them.  If installation is not provided by a project,  the
build script should display a message to that effect.  Optionally,
{build.optimize} could be set to on for this target.
'uninstall'
This target removes all the project files from the afformentioned
directories.  IMPORTANT:  The uninstall script should NOT
assume that the {install.[*].dir} directories are direct decendants
of the {install.dir} directory.  If installation is not provided
by the project, the build script should display a message to
that effect.
'clean'
This target deletes all files that are generated by the build
process--but does not delete files used to configure the build
process.
'distclean'
This deletes all files that are left from clean and returns the
project to its distributed state.
'docs'
This generates all documentation for a project.  This includes
user docs and javadocs.
'javadocs'
This simply generates the javadocs for the project.
'printerdocs'
This generates a printer friendly version of the documentation.
Most projects dynamically build their documentation from XML
anyway. They should provide a nice and simple stylesheet that
avoids all the HTML tables embedded in tables approach most
site docs use.
'dist'
This target should be used for generating all the artifacts used
for a distribution.  That means the tar ball and zip file used to
distribute projects, and any dynamically generated announcement
files.
'check'
This target is used to compile and execute any unit tests that
are built into the project.

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




Re: Standardizing build.xml files

2001-09-06 Thread Berin Loritsch

The Alexandria project with Gump, Maveric, et. al.
are doing a great job of keeping all the builds working
with each other.  It also helps with notifying projects
of changes in the API.

But there hasn't been any official documentation or requests
for target naming conventions like I just proposed.  If everyone
likes the approach, Ant should place the information in their
manual (like gnumake does with its conventions)--and all project
leaders should either make the modifications to the build
files or propagate the information to the team (someone will do
it).

Personally, I will copy the proposal to the Avalon and Cocoon
development lists.  It seems that the proposal struck a couple
cords on this list, so we will see if the build scripts change :).

Jon Stevens wrote:
 
 Please join the alexandria project's mailing lists. Gump, Maveric, JJAR,
 etc, are all trying to do this in one way or another.
 
 I think that the first priority is to get CJAR* working. Once we have that,
 using the information provided by Gump to create standardized build files
 for projects becomes a whole lot easier.
 
 * I like CJAR better than CJAN as a name now. CJAR == Comprehensive Jar
 Archive Repository.
 
 -jon
 
 -
 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: Standardizing build.xml files

2001-09-06 Thread Sam Ruby

Berin Loritsch wrote:

 Jon Stevens wrote:
 
  Please join the alexandria project's mailing lists. Gump, Maveric, JJAR,
  etc, are all trying to do this in one way or another.

 The Alexandria project with Gump, Maveric, et. al.
 are doing a great job of keeping all the builds working
 with each other.  It also helps with notifying projects
 of changes in the API.

 But there hasn't been any official documentation or requests
 for target naming conventions like I just proposed.  If everyone
 likes the approach, Ant should place the information in their
 manual (like gnumake does with its conventions)--and all project
 leaders should either make the modifications to the build
 files or propagate the information to the team (someone will do
 it).

The project definition files used to feed Gump and Maven are concrete
representations of the amount of unique information content required to
build that project.  The more standardized builds become, the smaller and
easier it becomes to maintain these project definitions.  If there was a
common place to find the build.xml, a common way to represent dependencies,
a common target, a common place into which outputs are placed, then my job
would be simpler.

I see Berin's proposal as the welcome next step in the process started by
Ceki in producing the following web page:
http://jakarta.apache.org/site/dirlayout.html

- Sam Ruby


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