Re: Subtle barriers to entry
Martin van den Bemt wrote: We can always write a maven plugin to get the unified form spit out, for mavenized projects (don't know forrest, so cannot talk about that..).. Yes, this is sort of what I was thinking, we can easily do the same. Personally I prefer to have two files: one describes the project, and it stays basically fixed; the other is more dynamic and changes frequently. _projectinfo.xml_ - goals - credits - license - resource URLs (site, mailing lists + archives, VCS stuff) - description - short description - what it does _status.xml_ - committers - todos - changes - votings ? Comments? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Common XML Project descriptor ( Re: Subtle barriers to entry )
Nicola Ken Barozzi wrote: Personally I prefer to have two files: one describes the project, and it stays basically fixed; the other is more dynamic and changes frequently. _projectinfo.xml_ - goals - credits - license - resource URLs (site, mailing lists + archives, VCS stuff) - description - short description - what it does _status.xml_ - committers - todos - changes - votings ? Martin van den Bemt wrote: The general impression that that is too much info for a generic approach. Unless your goal is to redefine the project pages ;) I was more thinking in line of a quick view page, with all the projects with the most basic info (description, lists, cvs repo, latest version, project page link) So people can go to eg http://www.apache.org/projects-info.html and get all quick info over there.. This way you don't have to go through the process of every project changing their sites again.. Well, _projectinfo.xml_ is basically what you would need for it, with some aggregtation, while the second file is more about project management - decision making process. Let me try a second stab at _projectinfo.xml_ alone then. _projectinfo.xml_ ?xml version=1.0? project id=myproject site url=http://mysite.org/; hostname=mysite.org remotedir=/home/groups/m/my/myproject/htdocs/ vcs type=subversion root=http://myvcs/; url=http://myvcs/cgi-bin/viewcvs.cgi// bugtrack url=http://myproject.org/mybugziulla// mailing-lists mailing-list mail=[EMAIL PROTECTED] subscribe=[EMAIL PROTECTED] unsubscribe=[EMAIL PROTECTED] user=developer archives archive name=one url=http://etc1/ archive name=two url=http://etc2/ /archives /mailing-list /mailing-lists description abstract=My project is about this. This is about my project in detail. /description what goalIt will do this./goal goalIt will do that./goal /what why This project started because... /why vendorApache Software Foundation - apache.org/vendor licence legal=./legal This software is released under the Apache Public License 1.1. /licence credits creditThis software includes software developed by.../credit /credits /project -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Martin van den Bemt wrote: See inline ;) _projectinfo.xml_ ?xml version=1.0? project id=myproject site url=http://mysite.org/; hostname=mysite.org remotedir=/home/groups/m/my/myproject/htdocs/ vcs type=subversion root=http://myvcs/; url=http://myvcs/cgi-bin/viewcvs.cgi// bugtrack url=http://myproject.org/mybugziulla// mailing-lists mailing-list mail=[EMAIL PROTECTED] subscribe=[EMAIL PROTECTED] unsubscribe=[EMAIL PROTECTED] user=developer archives archive name=one url=http://etc1/ archive name=two url=http://etc2/ /archives /mailing-list /mailing-lists description abstract=My project is about this. This is about my project in detail. /description what goalIt will do this./goal goalIt will do that./goal /what /project -- end here -- why This project started because... /why Nice for the project page itself. Hmmm... vendorApache Software Foundation - apache.org/vendor licence legal=./legal This software is released under the Apache Public License 1.1. /licence Also vendor + license seems a bit obvious, or am I missing something (I assume incubator projects will adopt APL immidiately). I intend to make this descriptor of more general use than in Apache only. credits creditThis software includes software developed by.../credit /credits Also nice for the project page, not for a quick overview. Maybe it is a communication problem, so let me know if my assumption is wrong : We are talking about generating a centralized page (= not on the project webpage) with the project information specified above, so that people that want a quick look what's out there or want to quickly find where mailinglist of project X is, can go to ? Yes. If the answer to above is yes : cool and from a maven perspective the above is what can be offered, based on the maven project.xml, and I can write a maven plugin to generate that xml. If you had something different in mind, please explain ;) What you propose is simply a subset of what I envision. With the above descriptor, we can create both a centralized page with the summaries for all projects *and* project summary pages. Actually, I also started with the status.xml format also, to be able for all to see what's going on easily in every project, in a *centralized* way, regardless to which build-documentation system is used. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Costin Manolache wrote: Can someone summarize what's wrong with the gump descriptor used by all jakarta and xml projects ? I understand we may need to add more stuff ( maybe using some ns: ), but I don't quite understand why we need to change existing definitions. If you look at the proposed DTD, apart from the root element, there is basically nothing that the Gump descriptor cannot cope with. It's the route we've taken with Forrest, and my proposal takes from that. These are Gump project descriptors that already embed the proposed elements: http://cvs.apache.org/viewcvs/xml-forrest/module.xml?rev=HEADcontent-type=text/vnd.viewcvs-markup http://cvs.apache.org/viewcvs/jakarta-poi/module.xml?rev=HEADonly_with_tag=HEADcontent-type=text/vnd.viewcvs-markup http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/krysalis/krysalis-centipede/module.xml?rev=HEADcontent-type=text/vnd.viewcvs-markup Also note that I've not included href attributes, as they are expanded by default by Gump. Since Maven has it's own descriptor, I initially thought it was better not to start another Gump VS Maven format debate that I've already gone through more than once on the Alexandria list and elswhere (if you want the details see the archives). But when I saw that Maven guys volunteered to make a plugin that outputs the descriptor, I proposed the DTD which is plainly from the Forrest extensions to Gump. Probably it means that it's just easier for Maven to add the elements in the Gump plugin? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Peter Donald wrote: On Wed, 6 Nov 2002 11:58, Daniel Rall wrote: Nicola Ken Barozzi [EMAIL PROTECTED] writes: Peter Donald wrote: Secondly make it so each project can have multiple vcs entrys (ie Avalon and it's 6 or 7, turbine with the same). Hmmm... this descriptor should have a 1-1 relationship with a single VCS entry, as it defines what in CVS is a module, as in the Gump descriptor. Then it's not really a project descriptor, now is it? We already have plenty of projects at the ASF which have multiple CVS repositories -- look at httpd. Even the new infrastructure project will have several (so it's a growing trend). We also have projects that propose one VCS ([EMAIL PROTECTED]) where codebases have subdirectorys (like serf/, httpunit/ etc). Other projects share mailing list for multiple codebases. Which sort to starts to get back to that icky state of flux that the alexandria (then gump) descriptors went through. The truth is that I think you are rught, we will never come to a solid relationship with these entities, and history is here to warn us. What happens when a particular resource is used across multiple codebases? Possible resources being; * mailing lists * VCS * issue trackers * developers * schedulers/task trackers If it was a normalized database model it would be simple because there would just be relationships between the entities. But because XML is a hierarchial data store then it no work. As you know, Gump resolves this by defining common entities separately and linking them, like CVS repository info, that can be defined in one place and linked in all project descriptors. Maybe it would be a good idea to start from a fully normalized database model and then work towards exporters that denormalize for particular purposes. The information could then be shared between different users and they could formulate it as they desire. Conceptually it's basically the same as with what Gump does, but I'm interested in pursuing alternative paths if they are better. What do you see in the Gump-like information-sharing system that needs to be redone or that cannot be done? Does this sound like a good idea? Sure clears up the picture :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
New Jakarta Logo, Apache affiliation now clear
Since in the discussions it has somewhat come out that Jakarta is sometimes not regarded as an Apache project, we've changed the Jakarta logo to match more closely the one on the main Apache site. @see http://jakarta.apache.org/ There is also a version for Mavenized projects :-) http://jakarta.apache.org/images/jakarta-logo-blue.gif -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Apache Trove
Sam Ruby wrote: Steven Noels wrote: Sam Ruby wrote: It would really be nice if the Maven/Gump/Forrest/Trove/etc. descriptors could be converged. With a base vocabulary that all can share, and an ability to have namespace qualified tool extensions. Yup - so what do you think: should/could this be something to be added to/triggered by Gump? Or do you prefer it to live outside, and only trying to define that convergence w.r.t. descriptors...? I'm only focused on convergence of the descriptors. It really doesn't make much sense for a project to maintain a separate set of largely overlapping metadata, one for each tool. Krysalis Centipede decided to use the Gump descriptor and enhance it where needed. Jakarta POI for example uses it. Areas were being part of Gump might help are existing buy-in by a lot of projects (even non-Apache ones!), and the description and uri already being there. Problem is that Gump only maintains a linear 'classification' of projects, whereas I want some hierarchy, and the notion of keywords that needs to be added. I don't know enough about the Gump machinery to start extending it (but I'm downloading it ATM), so any guidance is welcome. Gump ignores tags it doesn't understand. But if we can get more tools to share metadata, we probably need to make this more formal via namespaces. FYI: Forrest is going down the route of adding tags to gump descriptors. Yup, and Centipede too. Also, on Forrest we are testing an xml version of the status file, that is complementary to the project descriptor as a container of community info. Maven invented their own descriptors, with the idea of eventually generating gump descriptors from this format. To date, this has not worked out as well as I would have liked, for example: http://marc.theaimsgroup.com/?l=alexandria-devm=103936130220759w=2 - Sam Ruby P.S. An example of the types of report that Gump produces: http://cvs.apache.org/builds/gump/latest/xref.html I'm looking into making these published via Gump, taking a parallel route to the one Steven has taken. We'll soon see the solution and work together on it. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Apache Trove
Steven Noels wrote: Nicola Ken Barozzi wrote: I'm looking into making these published via Gump, taking a parallel route to the one Steven has taken. We'll soon see the solution and work together on it. I have been background talking with Sam and moved towards using Gump as a datasource, too - but not running inside Gump since I have some Cocoon tricks in mind. Nothing committable yet, though. Do we need to work in parallel? Not necessarily. I was thinking of changing the stylesheets so that the Gump build outputs to the xdocs11 format. Actually all Gump does in this regard is aggregate the descriptors and xslt them. What are your ideas? Let's move this to the Forrest list where there are also the major Gump devs, and see what we can do. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Tapestry incubation
Henning Schmiedehausen wrote: So that would make up what? The fifth or the sixth Framework from the ASF? You're right, geez, we should only have Avalon as a framework and Cocoon as an app. Yup, in this case I agree. :- On Sun, 2003-01-05 at 03:34, Andrew C. Oliver wrote: [1] http://tapestry.sourceforge.net [2] http://nagoya.apache.org/wiki/apachewiki.cgi?TapestryProposal Tapestry is a component-based web framework. Its created by a great group of guys whom I have a lot of respect for. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: ASF use of Instant Messaging
Sam Ruby wrote: Noel J. Bergman wrote: Are there any policies regarding IRC use, and is there an infrastructure participation in setting on an IRC channel for a project, or do we just go do something? Several ASF projects use IRC, including tomcat, mod_perl, Struts, Jelly, and others. It appears that at least those hosted by Werken maintain IRC archives to supplement the mail archives (I suspect that all do). My own views on this: 1) People should not be any more upset about the use of IRC than they should if two committers on a project happen to bump into each other at an ApacheCon and take the opportunity to discuss a problem that they are working on. +1 I routinely talk over IM personally with other developers. I'm getting used to give them a good-morning respective to their time-zones :-) 2) This being said, no *DECISIONS* should be made on behalf of projects in this manner. In particular, VOTES should be on mailing list unless there is consensus by all the participants otherwise. I would add that also *discussions* are to be done on the mailing lists. Having just votes would be almost only a formality. IMs are great for Random Thoughts and birth of new ideas or quick problem solving, not to discuss things at lengths. Anyway, IMHO there are so many free IMs systems available that till it becomes a problem we can use those with no problem. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [poll] weblog package on apache.org
David Reid wrote: [...] I wish people would stop doing this... Nicola - while I appreciate your wish to push your project (don't we all) what you're talking about and what I was talking about are totally different! The project in itself has nothing to do with it. I'm just saying that there are possibilities to solve a need with a different solution. Solutions tend to be in conflict. Needs seldom are, if ever. What is the *need* that projects have for blogs? I was trying to say that I'm thinking of solving what I percieve as the need in a different way. Not a do we want blog software, but a how to make projects fulfill the needs they think blog software will placate. I'm not really sure how you made the jump from my statements to where you ended up either... David Reid wrote I agree that providing a forum where news can be made available for projects in an easier to find location is a good thing and soemthing we should aim to provide, /David Reid wrote I replied Forrest already gives the changes of the projects also as an RSS feed, that is the pivot of syndication, the blood of all blogs. I'm going to add soon a news.xml file so that projects can add news items for themselves and have them come out as RSS feeds. /I replied RSS feeds are IMHO the first step in provifing an aggregated view of project news. It's a trivial thing to do actually, just a simple xsl stylesheet. Anyone can put it in their favorite site publishing tool. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Roy T. Fielding wrote, On 11/02/2003 3.44: ... So if all of this is accepted, why does it matter that Checkstyle is licensed under LGPL? It is not being viral. It doesn't matter. However, it also doesn't need to be distributed from the ASF servers. There is no reason that developers couldn't use it -- we use dozens of such tools for httpd development. Please excuse me if I ask it once more, just to be clear. In this case, that is using LGPL such as checkstyle for the build, is it possible that the build system downloads it automatically for the developer? And /GPL/ buildtools, is it different? Would it have to ask permission of the developer to download given that it's GPL (ie making it clear)? I'm asking it again because we are talking about buildtools here, not jars used in the compilation, runtime, or linked in any way. Thanks. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How BSD hurts OpenSource
http://www.freewebs.com/sepero/index.html The author says: Notice: Please do not waste your time reading this if you care nothing about the promotion of OSS and it's community! This document is for the advancement of OSS, not just the contribution to it. If after reading this, you still consider BSD more beneficial to OSS than GNU, please have at least READ their software licenses before contacting me. *sigh* -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How BSD hurts OpenSource
Noel J. Bergman wrote, On 13/05/2003 22.24: ... In 1992, when GNU was nearly complete, Linus Torvalds released a free program that fit the last major gap. You'd think that Stallman's ego wouldn't require him to marginalize Torvald's work to boost his own. And given what he thinks about the publicity cause in the Apache License, that makes it incompatible with GNU, it's really amusing. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How BSD hurts OpenSource
David N. Welton wrote, On 14/05/2003 9.35: Justin Erenkrantz [EMAIL PROTECTED] writes: What I wonder is how many of those authors/copyright-holders have actually read the GPL and understand what it really means. -- justin Probably not the details, but on the other hand, the concept of the GPL is clever, and the idea of 'not getting ripped off' appeals to people. From what I've seen, many projects do not read the GPL in full, and just know that it prevents companies from freely getting money for their work. Which is not true of course, but it follows this reasonong: 1- companies distribute closed source 2- with GPL they cannot close the source 3- they will not use my product inside theirs' The LGPL becomes: they can use it but cannot make money on my work only, but only if used as a library. The reasonong is the same of the above. What surprises me is that AFAIK the GPL prevents closing the source not to prevent profitability, which instead is the main aim AFAIK of many that now choose GPL. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Wiki defaced
Henning Schmiedehausen wrote, On 07/06/2003 11.10: On Sat, 2003-06-07 at 10:40, Noel J. Bergman wrote: ... The wiki theory is that it is so easy to repair vandalism that the immature cretins basically lose interest in their juvenile activities. For more discourse on the subject, see: http://c2.com/cgi/wiki?SocialAcceptabilityOfWikiVandalism Hi, while I basically agree with you on the Wiki point of view, the question (at least to me) remains, whether the Apache Wiki is an experiment in communication or a tool for documentation. ... Imagine that someone calling up the page while doing a presentation in public... I love wikis. I thought that just checking commits was enough. But I am *COMPLETELY* *DISGUSTED* by what I in the page changes. It's the most revolting pic I've EVER seen! To be honest I almost cried. For all the love I have for Apache, this is a big fat slap in the face. I think that the rule must change ASAP to use passwords, even if they only have to be requested to the respective PMC. :,-( -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The cash of our lives / Dvorak
Greg Stein wrote, On 10/06/2003 21.01: On Tue, Jun 10, 2003 at 01:58:16PM +0100, Danny Angus wrote: ... Moving and re-naming files in an ssh terminal session is not crazily graphical nor easy enough for a 4 year old, but I bet there are enough people in Apache who can do it without sweating that it is, IMO, a poor excuse for throwing away useful information. Bah. ObPlug Use Subversion. /ObPlug :-) Cry4Help Release the baby! /Cry4Help ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How ASF membership works and what it means
Ben Laurie wrote, On 26/06/2003 18.54: ... Presumably the idea behind unit testing is that it reduces the time spent chasing bugs. Mostly in OS it reduces time spent *re*chasing bugs ;-) If the overall effect is not less developer time used per unit of functionality, then I have to wonder what the point is. Making a fix remain so. I can't remember how many times, without unit testing, the same error kept coming back. In OS it's even more necessary, as committers come and go... it's a way of writing down knowledge and keeping it there with the code. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WORA Considered Evil ;-)
Danny Angus wrote, On 29/06/2003 13.27: ... James has been described by someone as Apache's best kept secret. I met some guys (ASF members) a year or so ago and some of them were unaware that the ASF had a mailserver project. James is a killer project, based on solid ideas and in my company intranet it simply works (TM). The cool thing about it is that it's pipeline based, so that it's very very easy, I'd say near to trivial, to make messages do what you want by using mailets, and usually the ones you need are already there. My net admin loves the baby: MySql as a backend (she loves to be able to do queries and simple backups), a simple config file with spam blocking, the thing installed as a service, and nothing to touch :-) Oh, and memory usage is really stable, with no noticeable load problems on the server. Ok, the load is light (50 users), even if we have multi-mega attachments for the technical drawings, but it can do all and it's easy and stable. I love it :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Newsletter [Re: Jakarta Newsletter Issue 9 -- May-June 2003]
Mads Toftum wrote, On 11/07/2003 18.53: ... I like the idea of a (bi-)monthly newsletter, but I'd hate to see it being forced on people who didn't want it. Are there a lot of people here on community@apache.org that not want to know, or even care, of what is happening in Apache-land? Oh well... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] About Tetsuya decision....
Noel J. Bergman wrote: On the other way, I wonder how Tetsuya gives the job too easily. There was no strong criticism. I disagree. What I have percieved is quite strong criticism and something that in some cultures could have been seen as derision. All this for what I really think is a *trivial* matter, especially if compared with the hard work put in the newsletter and the actual results. I'm totally sure that this wat *not* the intent of anybody, and that nobody wanted to strongly criticize Tetsuya, but as I see it from this side if my email client, this is not the message that has passed. We are not all male Americans, so we should also keep in mind that others see and feel things differently. On cocoon-dev I just say this link, and I think it's quite appropriate: http://www.cozy.org/ben/nsf.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Information channels, Re: Inappropriate use of announce@
I recently read that the smaller an issue is, the bigger a discussion it gets, as everyone has something to say. This issue must be pretty trivial then. In any case, who decides? What is the PMC or something overlooking these things, that can give a reasonable decision and stop all this nonsense? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inappropriate use of announce@
Phil Steitz wrote: Craig R. McClanahan wrote: snip/ ... I don't think that effective decision-making in a large organization *requires* bureacracy. You're right. It requires responsibility. It's possible that an entity is responsible of something without having bureacracy in place. In Apache it's mainly meritocratic communities that decide through the Apache decision-making process (not necessarily voting). Here it seems that it's not clear who is ultimately responsible for this, or if there is lack of oversight, but I might be wrong. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Private mail lists [was: Inappropriate use of announce@]
Santiago Gala wrote: ... Another troublesome and interesting case is incubation processes. There are messages going back and forth between the incubator and the relevant pmc to take the project, and quite often the final acceptance decision is not documented anywhere, or barely so. And the process looks obscure from the outside, even when, reading the relevant (private) messages makes the process obvious and non-controversial. Should most of those processes be held in public? Yes. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy for Jakarta Wiki(s)
Santiago Gala wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El miércoles, 10 dici, 2003, a las 19:30 Europe/Madrid, Andrew C. Oliver escribió: infrastructure My issue with the PMCization of Apache is that everything is moving to private lists. How is this open??? Bzzz. Wrong. Nothing is moving to private lists. Creation of more PMCs and private lists are two extremely different things. Apache is in the process of creating more PMCs, as was intended since the beginning, so that community groups are responsible directly of the project without useless beaurocratic levels of indirection. All discussions that are not extremely sensitive must happen on public lists *as always*. If it doesn't happen, it should be rectified. Being out of all PMCs, I have been experiencing the same feelings. I suspect that we look more and more opaque from the outside, which I think is bad. If this is the case, it *is* bad. We must ensure that all discussions happen on public lists unless it's evidently necessary, for several reasons, that they remain private to PMCs. Overmore, all long term committers should be on the PMC, which should simply represent all the dev group. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Undermining the Incubator
Andrew C. Oliver wrote: From: Rich Bowen [EMAIL PROTECTED] ... First of all, thanks for this thorough resonse. Sure. True. This does belong on community@ I think it belongs in the Incubator, as the Incubator is exactly for these discussions (where constructive). Interested parties can subscribe to [EMAIL PROTECTED]@apache.org Andy, for one that rants about tricameral votes (which have been abandoned looong ago), you are pretty trigger-happy about cross-posting. :-PPP -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: automatic nagging for board reports?
Leo Simons wrote: (replies to community@ please) I believe many ASF projects are chronically late in sending in status reports in time for the board meeting. That's bad and they should be nagged about it. Since manual nagging is a chore, how about a small script in a crontab somewhere that automates sending out a timely reminder? +1 I'll volunteer to set it up if such a thing is desireable. I just need the report schedule and some time. The schedule is in committers/board/comitee-info.txt For time, you'll have to ask yourself ;-) I also have a script that nags about patched submitted in bugzilla, and have other nags that I'd like to have done, like for example reminding me to update the status file after 72 hours a PMC member is added etc etc, and some chore automation. I'll add what I have in the committers CVS module, we can start (and even change it all) from there. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF use spamassassin?
Stefano Mazzocchi wrote: Antonio Gallardo wrote: ... http://wiki.apache.org/spamassassin/CommercialProducts And we (on the ASF) are discusing right not about if will be fine to eat our own food. :-( I didn't say we aren't not going to use it. I just said that given the size of the email traffic and the variety of people (almost a thousand) that this move will impact, the ASF infrastructure team is considering this with great care and, as usual, doesn't want to rush things, but try to do them right. +1 In any case, we are using Apache HTTPD to run our servers, and this is a good test for developers. I guess the SA guys would benefit from using it at Apache, as it seems to be a good testbed. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inexpensive Lists
Justin Erenkrantz wrote: ... Again, a list is fine. I'd just prefer to find someone else to host it: the ASF isn't the end-all-be-all to all of your hosting needs. And, obviously, feel free to invite all of the ASF folks to that list. -- Apart from the fact that you have put much more energy in talking against this than creating the list (hint hint ;-) ... This reasoning it the one that makes Apache committers start projects at codehaus for example, where these things are not discussed to death but just done. People need more than just a dev list for a specific project to nuture aspirations and ideas. If we fail to give this, we will steadily loose involvment. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inexpensive Lists
Noel J. Bergman wrote: Apart from the fact that you have put much more energy in talking against this than creating the list (hint hint ;-) ... I don't think you have any idea how much goes into creating a new list. I just did a quick count. There are 16+ commands to execute on 3 ASF servers, plus a file in CVS that needs to be edited, committed, and updated on minotaur. Per list. And a dev or user list is different from a commit record list which differs from a private list. Then we have a *big* problem. An app or scripts to make this easy are not only a nice thing to have, but a hard necessity as I see now. Do it yourself scales, and I would think that any ASF member should be able to create a list, given evident consensus. We did the same for the Incubator files, remember? The fact that Apache members (that are thus trusted) cannot do it on their own (lack of knowledge and too much effort) and must bug the poor infra guys is a big problem. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Daffodil Replicator an Open Source : Suggestion
Ashish Srivastava wrote: Hi, We are a product based company named Daffodil Software Ltd, based in India. We have developed many good products using JAVA out of which our two premium product Daffodil DB (an RDBMS) and Daffodil Replicator (database utility software) is largely accepted by world software community. We are planning to make our Daffodil Replicator an open source project. How can we make it with www.apache.org please let us know how we have to proceed. I visited at http://incubator.apache.org but unable to find the answer how to proceed in order to make our product open source. I'm cross-posting to lists where there might be interest in helping you out on this. www.daffodildb.com -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Commentary: Metro and Avalon
Niclas Hedhman wrote: ... in effect anyone could potentially be at the whim of high ranking officers (Board) and to a lesser degree PMCs(?) Apache is a meritocracy, not a kolkhoz[1]. People are invited to join the PMC only if other PMC members see their merits and want them to come in, not because there is some rule that sums up the commits done or the length of the emails written. PMC members are there because they earned merit from their peers (not because of rules), and they have all the right to decide for the project. The same applies to the board, as it's an elected selection of members, that are also there only on invitation. If you don't understand this, you don't understand Apache. [1] http://www.britannica.com/eb/article?tocId=9045938query=kolkhozct= -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Commentary: Metro and Avalon
Sam Ruby wrote: Nicola Ken Barozzi wrote: Since you don't seem sensible to common sense [snip] Just don't expect to change people, as it will never happen, especially if you are attacking them. Consider taking your own advice. Thanks, will do. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Avalon Closed
J Aaron Farr wrote: ... The thing is, and the reason for sharing this with the community, is that PMC's and communities need to watch out for this sort of thing in your own community. Don't wait for the situation to get critical. PMCs and PMC Chairs can intervene and should rather than watch a community tear itself apart. I was an Avalon PMC Chair that had to deal with these issues, and what happened back then - that is two years ago - is remarkably similar to what has happened till Avalon's closure. If I were in the same position now, I would have been more resolute in pushing the community split. Time and non-intervention have only perpetuated problems, if not made them worse. As the saying goes, You can bring a horse to water, but you can't make him drink. So, to answer Stephen's question, communities are most important in the decision process, but individuals need to step up and step in when a community breaks down. +1 I can't agree more. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is ASL2.0 not GPL-compatible ??
Niclas Hedhman wrote: ... Does anyone know, and preferably have any authorative-like links ?? http://www.apache.org/licenses/GPL-compatibility.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
