Re: lists that don't require subscriber approval
On Thu, 6 Sep 2001, Pier Fumagalli wrote: > > 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] Done. > > 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... Please do. > > 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. Done. > > The following lists are set to -mU, which means all messages are > > moderated: > > > > announcements > > That should stay as-is... Yes. > > taglibs-user (this I don't understand) > > I'm going to change this one to be -mu... Cool. > Lists to moderate: > - slide-dev (Remy) > - slide-user (Remy) Email address? Er, I'll let you deal with it. > Lists to nuke: > - bugs > - library-dev Done > - check-dev > - docs > - josper-dev I'll let you do these. > 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) I'll let you do these. > Lists to modify (-mu instead of -mU): > - taglibs-user (Get me off moderation for this one please!) Done. On Thu, 6 Sep 2001, Ted Husted wrote: > > > > struts-dev > > > struts-user > > > > Moderator for those two should be Craig :) > > Or me. Craig keeps pretty busy with Tomcat these days ;-) Done. > > > > > taglibs-dev > > > > And for this one too (Craig? :) > > Or me. I'm the PMC contact. Done. Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Standardizing build.xml files
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]
Re: Standardizing build.xml files
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
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]
Standardizing build.xml files
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: lists that don't require subscriber approval
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]
Re: lists that don't require subscriber approval
"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
- Original Message - From: "Pier Fumagalli" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, September 06, 2001 3:44 PM Subject: Re: lists that don't require subscriber approval > "Vincent Massol" <[EMAIL PROTECTED]> wrote: > > > > 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@... > > And making a hell-of-confusion :) Joking, of course... I tend to agree with > Brian and with the "guidelines" he gave when we opened the new subprojects > (back in 99, I believe)... It's just that since (now) cactus is not a > top-level project, it shouldn't have a top level Mailing List, but it should > be always be prepended by the name of the project in which it resides... > I also agree. It was a mistake and I apologize for that. Please forgive me ... I promise not to do it again ... :-) > > 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. > > I believe that, if you developers want to be a "real" root-level project, > well, you have all the right to be... Did you have a vote on the commons > mailing list to "split out" ??? :) just sent a request for vote now on [EMAIL PROTECTED] ... :) > > > 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 ? > > Once the developers agree that they want to become top level, I believe that > it's only a matter of PMC "blessing" of that... I would be +1... > Thanks. > Pier -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: lists that don't require subscriber approval
"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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: lists that don't require subscriber approval
"Vincent Massol" <[EMAIL PROTECTED]> wrote: > > 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@... And making a hell-of-confusion :) Joking, of course... I tend to agree with Brian and with the "guidelines" he gave when we opened the new subprojects (back in 99, I believe)... It's just that since (now) cactus is not a top-level project, it shouldn't have a top level Mailing List, but it should be always be prepended by the name of the project in which it resides... > 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. I believe that, if you developers want to be a "real" root-level project, well, you have all the right to be... Did you have a vote on the commons mailing list to "split out" ??? :) > 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 ? Once the developers agree that they want to become top level, I believe that it's only a matter of PMC "blessing" of that... I would be +1... Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: lists that don't require subscriber approval
- 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
Pier Fumagalli wrote: > > - 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".. It seems that the commons people got tired of seeing all the cactus related traffic, and voted to have a separate list created. ;-) Re: archive: [apmail@daedalus apmail]$ls lists/jakarta.apache.org/cactus-user/archive 0 1 2 3 4 If there is anything amis with this mailing list, blame me as I did the dirty deed. - Sam Ruby P.S. Perhaps the right fix here is to create a jakarta-cactus subproject. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: lists that don't require subscriber approval
Pier Fumagalli wrote: > > 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. Go ahead and remove it. It was the precursor to the commons-dev list, and now obsolete. > > struts-dev > > struts-user > > Moderator for those two should be Craig :) Or me. Craig keeps pretty busy with Tomcat these days ;-) > > > taglibs-dev > > And for this one too (Craig? :) Or me. I'm the PMC contact. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 ;) -- 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
"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 (A
