Re: Low level community
On Sun, Jun 29, 2014 at 7:27 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, On Sun, Jun 29, 2014 at 1:22 PM, Andy Seaborne a...@apache.org wrote: ...With a large number of TLPs, some are going to be in this state. Not attic-worthy, still useful, minimal active development... Agreed - and from the board's point of view it's good for such projects to mention in their reports that although their activity is minimal, they do have at least 3 active PMC members who can step in when needed. If that's the case, low activity and small communities are fine. +1 I've added a note to this affect to the Describe the overall activity in the project over the past quarter. bullet in http://www.apache.org/foundation/board/reporting -Bertrand - Sam Ruby - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
On Wed, Sep 15, 2010 at 12:50 PM, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Sep 15, 2010 at 11:23 PM, Joe Schaefer joe_schae...@yahoo.com wrote: I can appreciate that, but the stock answer to that is just give them commit. High barriers to committership is not what Apache is about. You may be interested to learn that the Open Participation Software for Java (htttP;//wiki.ops4j.org) was created with a Wiki brought to coding and No barrier attitude, as a result of what we perceived as high barriers at ASF. Ex. cell. ent. For some projects, the barriers to entry at the ASF are too high. I can live with that. For some projects, the barriers to entry at the ASF are too low. I can live with that too. I hope that projects that are a perfect match to the ASF find a good home here. I hope that the projects which are not a good match to the ASF find what they need. - Sam Ruby - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: Forking is a Feature reactions?
On Mon, Sep 13, 2010 at 6:21 AM, Isabel Drost isa...@apache.org wrote: On Sun, 12 Sep 2010 Jeff Hammerbacher ham...@cloudera.com wrote: I'd love to hear the reactions of other ASF members to the piece. I'd also love to be directed to previous discussions on the topic, as I know that adopting git for some projects has been discussed previously. IIRC there should be some discussions on the archive of the infra and community mailing lists that were caused back when the read-only git mirrors were set-up. However I agree it would be nice to have one page that summarises the results of these discussions - especially the problems that various people saw. That way re-checking from time to time whether these might be resolvable by additional tooling or a use of git different from how it was discussed on the lists becomes easier. I just can't resist the opportunity to fork this discussion: http://intertwingly.net/blog/2010/09/13/One-True-Way - Sam Ruby - To unsubscribe, e-mail: community-unsubscr...@apache.org For additional commands, e-mail: community-h...@apache.org
Re: [Blogs] planetapache ...
On Mon, Sep 22, 2008 at 3:15 PM, Carlos Sanchez [EMAIL PROTECTED] wrote: sorry about that, I forgot about planet apache I need to find a way to filter the personal category in the rss, so far I could just make an rss for a category, but multiple categories per post are not allowed Anyway, sorry for the noise Filtering *could* be done server side... it even could be set up to remove images from specific blogs only. Or the planet could be set up to provide two pages... one high bandwidth and one low bandwidth. http://planet.intertwingly.net/top100/ http://planet.intertwingly.net/top100/mobile.html - Sam Ruby On Mon, Sep 22, 2008 at 10:29 AM, Torsten Curdt [EMAIL PROTECTED] wrote: Hm I was about to write the same as Noirin but I have only been reading planetapache via newsreader which makes skipping such posts much easier :) Going onto the site I tend to agree with you though. There is a limit ..and this is way beyond :) Carlos, ever considered using flickr and show only your best shots in your blog? That would give us best of both worlds. Your pictures and a reasonable planetapache site :) cheers -- Torsten On Sep 22, 2008, at 18:05, Matthias Wessendorf wrote: eh... I appreciate some pics as well... but I am not really interested in watch 100 cars... ;-) Perhaps it is just the fact that my current wifi connection sucks... -M On Mon, Sep 22, 2008 at 8:57 AM, Nóirín Shirley [EMAIL PROTECTED] wrote: Isn't it great when people post pictures in their blog (from their holidays, or related to the post, or just to show us some of the beauty in the world?) I really like seeing these pictures, and I like that the Apache community is more diverse than just code and licenses. If somebody is really bothered by them, (s)he could easily collect the feeds of only the project blogs, and ignore the community stuff... Or is it just me, that likes the fact that we're a community of people, and not just automatons? Noirin On Mon, Sep 22, 2008 at 5:06 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi, isn't it annoying that some post tons of pictures in their blog (about cars, castles and what not ?). Is there a chance to not include those pictures on http://planetapache.org/ ? If somebody is really interested in the real blog, decorated with tons of pictures, (s)he could easily click on the reference link... Or is it just me, that thinks this is sometimes a bit annoying. Thx, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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] -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache track at OSCON
In case you missed it, OSCON put out a call for proposals that will close on Sunday. The conference itself is August 1-5 in Portland. As with prior years, there will be an Apache track. Tim in especially interested in talks that relate to his thesis of an Open Source Paradigm Shift: http://tim.oreilly.com/articles/paradigmshift_0504.html - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Avalon RIP
Henning Schmiedehausen wrote: On Tue, 2004-12-21 at 05:02, Rodent of Unusual Size wrote: If there's a reasonable reason, cool. Otherwise, maybe we can move on. There'll be no 'winner' here. But we could proclaim Stephen and Niclas winner. Maybe this thread would end then and then we all would win... Amen. What once was a monolithic Avalon project has given birth to a number of progeny... some within the ASF, and some have graduated to new homes outside the ASF. While the birthing processes was painful at the time, those participating in each of the new projects appear to be happy with their new homes. Now... may Avalon finally Rest In Peace? Please? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Style of community building
Niclas Hedhman wrote: On Tuesday 28 September 2004 09:30, Stefano Mazzocchi wrote: If you want to change my mind, that's how you start: tell me what is the benefit for the ASF in promoting this style of community building, despite its long-term history of social energy waste, frustration and contract instability. In all due respect, IMHO this thread was never meant to be about community style building. Initially I brought up an issue of knowing the playing field to a more explicit extent, and secondary about level of transparency. OK, new thread. If you want to change my mind, you also need to start at the same place as Stefano indicated. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Style of community building
Niclas Hedhman wrote: On Tuesday 28 September 2004 20:27, Sam Ruby wrote: Niclas Hedhman wrote: Rightly or wrongly so, the tone of competition in Avalon was set well before the emergence of Merlin. That was bad. So now the train was moving, and noone pulled the breaks, not any individual, not the PMC, not the PMC Chair, not the community, not the Board - noone. That was also bad. I can't fix the past, but... Sam reaches for brakes. Sam grasps brakes. Sam pulls. That (whatever the pull symbolizes) should have been done 18-24 months ago :o) Agreed. Hindsight is easy, and I am not sure whether your intention is to punish parts (not all) of those who made it happen, plus some people who hasn't been involved (for instance commercial users). The intent is not to punish anyone, at all. For example, how are commercial users damaged in any way by the way the ASF choses to organize its work into projects? This is not meant to be a rhetorical question, I am genuinely curious. Did my suggestion reach you at all, or is it considered, what Ken refers to as, a hand wave ? Since you asked, I'll share my perception. Warning: it might not be what you expect. When someone points out that Ken has erred, he investigates the root cause, shares it, and takes full responsibility for the error. In this case, somebody pointed out an instance where somebody has erred, and I interpreted the response as sure I erred, but everybody else did too, and here is some other irrelevant consideration. I consider those portions of the message to be hand waves. We can discuss other things if you like, but until there is a proposal which adequately covers the technical and community aspects, you won't have this director's vote. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Style of community building
Niclas Hedhman wrote: On Tuesday 28 September 2004 22:08, Sam Ruby wrote: Hindsight is easy, and I am not sure whether your intention is to punish parts (not all) of those who made it happen, plus some people who hasn't been involved (for instance commercial users). The intent is not to punish anyone, at all. For example, how are commercial users damaged in any way by the way the ASF choses to organize its work into projects? This is not meant to be a rhetorical question, I am genuinely curious. I will give you one particular example, as I personally feel somewhat responsible for dragging him into this mess. One of the most active users with Merlin is Andreas Oberhack, who works with financial institutions. He have just secured the first phase of a massive undertaking for a German bank. According to him, persuading the technical IT department of the downsides of J2EE and the really positive sides of Merlin in large and complex applications. However, the management in banks are generally very conservative about outside products in general and OSS in particular. He spent the majority of selling Merlin on the notions of the liberal ASL, the long-lived community behind it, access to the sources, and the usual arguments in favour of OSS and particularly BSD-styled products. How much that management based their decision on the solidity of the ASF is uncertain, but hate to envision that Andreas would loose any additional phases of work, or worse mis-representing the ASF and its longevity of products and be held liable, over this. I am not saying it will happen if we move Metro elsewhere, just the thought makes me at unease. I hope that puts things in a perspective. long-lived community is the key phrase. I started Gump. Gump has essentially been completely rewritten since I last made any major contribution to it. Yet the community remains. And the interfaces (in the form of data definitions, in this case) are stable. Successful communities outlast their leaders. In any case, this does not answer the question as to how the lack of a top level project for Metro would damage a commercial user. Did my suggestion reach you at all, or is it considered, what Ken refers to as, a hand wave ? When someone points out that Ken has erred, he investigates the root cause, shares it, and takes full responsibility for the error. Some miscommunication must have occurred. :o) I wasn't asking about Ken, just used a term he has used to dismiss statements from me previously. Hand wave == Nothing to take note of. Instead, I suggested that we learn from the Avalon experience, and try to establish a mechanism that safe guard all projects in the ASF from it happening elsewhere in the future. I spoke of Markers indicating something is not right, and Safety Valves (Aaron, not values) to steer things back on track, long before we issue ... severe reservations of ... being part of I will note that the key portion of my reply has been elided, and that another discussion has been inserted. People who know me will attest to the fact that I can be annoyingly patient and persistant. We can discuss other things if you like, but until there is a proposal which adequately covers the technical and community aspects, you won't have this director's vote. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Board Commentary: Metro and Avalon
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. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy (Was: Playboy mirror logo?)
James Mitchell wrote: [resend] For the record (and if I wasn't clear before) I am NOT against playboy being a mirror or Apache using the mirror (whether it is being blocked or not). I AM against putting a link and/or image that links from Apache to playboy. Trust me, I've been all over playboy.com for reasons I don't care to elaborate on (what can I say, I'm a guy ;). But I will not sit idly by and let others (who apparently don't run their own business) put my company at risk. I always try to give credit where credit is due (powered by logo and link). My clients (all but 1) are not skilled enough to want to download something from a mirror and realizeoh shit!!, look where its coming from!. That's not likely to happen. They _would_ have a problem if one of _their_ clients or customers called and said they clicked their way from their site to Apache, and on to Playboy. Hell, I might even get sued. Here's a little test for you. Ask the eclipse project and/or IBM if they would add playboy's logo and link if they agreed to provide some bandwidth for them. What answer do you think you will get back? I can almost assure you that if it is not no, it will be hell no. Do you even realize how many web sites out there have powered by logos and links to Apache and the various subprojects? I am begging you!! DO NOT put their logo or link on our (yes, OUR) web site. You can't even imagine what the media will do with this if you do. God help us all. If you do this, it will only hurt Apache's name and reputation. If the current mirroring policy is broken, then it should be said so with comments and suggestions on how to fix it. +1 for rethinking the policy rethinking the policy is NOT what Jim suggested. What Jim meant when he said that is that people should STOP saying things like I am begging you!! and God help us all., and START making concrete suggestions on how the policy itself should change. The closest thing I see to that in your email is a suggestion that we let the Eclipse Foundation be the final arbiter in who the Apache Software Foundation will allow to be listed as an official mirror. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF Board Summary for June 23, 2004
Stefano Mazzocchi wrote: Greg Stein wrote: * The Cocoon PMC Chair also switched over to Sylvain Wallez, after Steven decided to step down. Steven and Geir are both part of the new PRC, too. What new PRC? Three paragraphs earlier, in Greg's summary: * The Board approved the formation of the Public Relations Committee (PRC). This new committee replaces the Fundraising Committee and also rolls in the responsibility and management of our press activities, public relations, and management of our web sites. The intent is to present a coherent message to the press, our sponsors, and all interested parties. This new committee is chaired by Brian Fitzpatrick. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release management
robert burrell donkin wrote: i've heard many times (and repeated it to others) that all release managers should be on the pmc. i think (after listening to many comments by the board folks to the pmc) i came to understand what should means in the context. it means that release managers themselves should be demanding to be on the pmc (rather than 'release managers must be on the pmc' as an edict). I *like* that interpretation. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: talking about privacy
Stefano Mazzocchi wrote: I started looking up a bunch of US people I know and I found this: http://preview.ussearch.com/preview/preview.jsp?adID=10002101fc=NCSHORTx=0y=0searchFName=SamsearchMName=searchLName=RubysearchCity=searchState=searchApproxAge=40 Gosh, Sam, you really look younger than your age ;-) Anyway, such a site would be *SUPER ILLEGAL* in europe and, I'll tell you what, my gut feeling is that I'd really like it to remain so. That guy does exist. Want to see something scary? Type in Sam Ruby NC in google. You will find both of us, along with phone number and address. There is even links to maps. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun and the JCP 2.5
Andrew C. Oliver wrote: We've been through this before. The list is has no Sun employees on it. It has only Apache members. They make decisions on behalf of the ASF. You can choose to no longer be a member of the ASF. You can choose not to participate. At the moment, you have chosen the former and not the latter. Sigh. I have not signed any NDA. I have only signed the ASF membership application. We can take a list which gets virtually zero traffic and split it in two. We did that once before, and created a list which allows Sun to participate. It gets even less traffic. How you can prove a negative (i.e., that you had access to such information but never actually took advantage of it), is beyond me. What should we call this proposed list? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sun and the JCP 2.5
Andrew C. Oliver wrote: Yes, Apache is on the scholarship board. If you want to discuss this further, you might consider joining the [EMAIL PROTECTED] mailing list. The problem is that I might inadvertantly receive information covered by apache's non-disclosure agreements with Sun. This could limit my economic viability in the future should I wish to implement a technology which competes with Sun. Would it be possible to have a list set up for those who are either not members or whom do not wish to be bound by such agreements to discuss the Apache side of the JCP? We've been through this before. The list is has no Sun employees on it. It has only Apache members. They make decisions on behalf of the ASF. You can choose to no longer be a member of the ASF. You can choose not to participate. At the moment, you have chosen the former and not the latter. -Andy - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: anyone know the progress of the Maven top level proposal?
James Taylor wrote: So my question: is there anything preventing the project from reevaluating and refining our charter in the future as the project evolves? Is it even neccesary or do we just assume a project will evolve and that is just the way it is? The same process that is used to create a project (i.e., submitting a resolution to the board) can be used to ammend a project. -- jt - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven and community
Now that the initial board discussion on the Maven resolution has been held, a few thoughts... 1) It was made quite clear to me by a number of directors that it is expected that I have an interest and opinion on topics that come before the board. I received repeated requests not to abstain on this vote, but I held my ground. I believe that over the years I have amply demonstrated a preference to let a thousand flowers bloom, but in this case my integrity was called into question in a way that I very much did not appreciate. 2) The question that is foremost in my mind on the Maven proposal is as follows: what does the ASF as a whole gain by yielding a specific scope and responsibility to the set of five developers mentioned in the proposed Maven resolution? If these people want to work together, they can certainly do so in a number of venues, so what do they or the ASF benefit from doing so here? 3) A challenge to the Maven developers: what would it take to convert Xalan to use Maven? The reason for this challenge is simple: to demonstrate the the antipathy towards other ASF efforts is damaging not only to the ASF, but to Maven itself. - Sam Ruby P.S., and this is primarily to Jason: please don't try to twist any of this into coersion. #2 and #3 above are simply a question and a challenge. They are not a prerequisite for board approval, or even necessarily for my one vote out of nine directors on the subject when it comes up again. It is my belief that a number of efforts made by the Maven community can, will, and do benefit the ASF. I simply want to maximize the potential for this to occur. That is my interest. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven and community
[EMAIL PROTECTED] wrote: -Sam Ruby [EMAIL PROTECTED] wrote: - Now that the initial board discussion on the Maven resolution has been held, a few thoughts... 1) It was made quite clear to me by a number of directors that it is expected that I have an interest and opinion on topics that come before the board. I received repeated requests not to abstain on this vote, but I held my ground. I believe that over the years I have amply demonstrated a preference to let a thousand flowers bloom, but in this case my integrity was called into question in a way that I very much did not appreciate. 2) The question that is foremost in my mind on the Maven proposal is as follows: what does the ASF as a whole gain by yielding a specific scope and responsibility to the set of five developers mentioned in the proposed Maven resolution? If these people want to work together, they There are more than five members of the Maven team. Please see http://jakarta.apache.org/turbine/maven/team-list.html for a full list of committers and contributors. There are around 30 contributors to the effort overall. The ASF gains nothing new from these people, as they are mostly existing committers. The code is (c) ASF, so they gain no code from the proposal. The ASF would gain more assurance that the code being created is overseen by people directly responsible and involved in its creation, rather than the responsibility falling to the Jakarta PMC, who I'm sure haven't got the time and energy to cover it. They would also gain a focussed community of software developers with a passionate group of users. The proposed resolution is not the only organization which would achieve that goal. It might happen to be the best one, but it certainly isn't the only one. I do believe that a number of potentially fruitful discussions about potential synergies have been shut down during this process. This troubles me. can certainly do so in a number of venues, so what do they or the ASF benefit from doing so here? There are quite a few projects here (ASF) using Maven as a build tool. Maven heavily relies on other ASF code (Ant, Jakarta's Jelly, Jexl, Commons etc). There are obvious benefits to those projects in Maven's continued working with them, as we have done in the past. 3) A challenge to the Maven developers: what would it take to convert Xalan to use Maven? The reason for this challenge is simple: to demonstrate the the antipathy towards other ASF efforts is damaging not only to the ASF, but to Maven itself. Last things first: 'antipathy' == 'A strong feeling of aversion or repugnance'. I'm not very happy that you feel the 'Maven developers', all 30 or so people involved in a significant way, feel this way about 'other ASF efforts'. I do not believe that all Maven developers feel the same way. Need I cite a few IRC logs to show that that a number of them, particularly some of those listed as the proposed PMC, do? Or at the very least, look the other way when such sentiments are expressed? Given the involvement of most of the proposed PMC members in other ASF efforts I'm having trouble seeing how it is justified. I'm trying not to take it personally. As I have tried not to take the numerous and repeated comments that Gump sucks or is an embarrasment to the ASF personally. As for the challenge, I, personally, don't think that Maven needs to 'convert' other projects to use it. Other projects should use Maven if they feel it fits their needs. I personally don't feel that other projects (Forrest, Gump, Centipede, Ant, Make, Nant etc) should try to convert people. I'd rather people experimented and made up their own mind. I'd hate for someone to force a build tool on me. Here we strongly agree. That's why I am concerned when I see statements to the effect that threre is no need for certain other efforts (for example, an ASF jar repository). That said, Xalan could quite easily start using Maven as a build or site generation tool, but, Maven doesn't currently cover as much of Xalan's build process as a pure java project, and hence there would be work to determine how this would be best achieved. I see no problem or issue there. If the Xalan team would like help I'm offering. P.S., and this is primarily to Jason: please don't try to twist any of this into coersion. #2 and #3 above are simply a question and a challenge. They are not a prerequisite for board approval, or even necessarily for my one vote out of nine directors on the subject when it comes up again. It is my belief that a number of efforts made by the Maven community can, will, and do benefit the ASF. I simply want to maximize the potential for this to occur. That is my interest. Just so I understand that last bit, you'd like to 'maximize the potential' for the 'efforts made by the Maven community' to 'benefit the ASF'. Right? I certainly would like to see that. To be clear, I
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Jason van Zyl wrote: On Wed, 2003-02-26 at 09:34, Greg Stein wrote: On Wed, Feb 26, 2003 at 09:48:42PM +1100, [EMAIL PROTECTED] wrote: [I won't even get into the question of why those two can't be related projects under a single PMC] Read the Ant missionit specifically states the Ant build system as it's scope. Bah. The Board can easily change the scope if there are better ways to organize the software that we [the ASF] produce. Existing charters shouldn't get in the way of What Is Right. What Is Right ? So that's going to be the board deciding what is right? What project's themselves want is not right enough? That is frightening. What happened to project self direction/determination? The board changes things like scope based on resolutions provided to it. If the committers to Ant and Maven wanted to cooperate, then a joint proposal could be authored for consideration by the board. The idea of such committer initiated proposals do not concern me, unless such proposals attempt to establish responsibility for items that are within the scope of other, existing projects. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
I must stay that I find this entire exchange bewildering. I have provided infrastrure support for Maven and an occasional patch here and there. When asked about either Maven becoming a top level project or leaving the ASF entirely, I provided what I thought were helpful answers. I welcomed Jason as a committer to Alexandria (where Gump was at the time, and Maven initially formed). I supported his movement of Maven from Alexandria to Turbine. And now I have indicated that I will abstain when the actual board vote is held on Maven becoming a top level project. - Sam Ruby Jason van Zyl wrote: On Wed, 2003-02-26 at 11:02, Noel J. Bergman wrote: Since I am the one who asked why Ant and Maven aren't related projects under a PMC, you might was well yell at me for having the temerity to ask a rather obvious question. But for all of your railing this morning, you never actually answered the question. To expand, I think ultimately all that matters is that a project be given the space it wants in an attempt to let it flourish. If the Maven developers want to be left entirely alone why is that a concern? If we compete head-on with Ant why is that a concern? If we compete head-on with Centipede and it's satellite of related projects what's the concern? If we don't want to use Gump or talk to any of the Centipede so what? Compete with us! You cannot force relationships between groups when the desire to do so does not emanate in mutual proportion from both parties. We don't want to grouped under the same PMC as Ant. How's that? We want to go alone and I think we've done a pretty decent job so far. If we falter and require, desire or ask for help later on than we can do so. If we desire to collaborate or merge with other projects than we can do so. Give each project its own space and let the network of interaction form of its own accord. If it is easy to shuffle PMCs and alliances then let it occur when there is reason too. All I and any of the Maven developers want to do is try to make it better. But from day one I have had nothing but pressure from Sam Ruby. Starting from him asking me to use a huge mess of an xslt transformed gob of XML as the model for Maven to using Gump as tool of coercion to force unnatural paths of evolutuion. I ignored the first request and I continue to ignore gump because anything not taking the project into primary consideration won't work. - 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]
[Fwd: RE: [proposal] daedalus jar repository (was: primary distribution location)]
My opinion is that the board should take this suggestion very seriously. Original Message Subject: RE: [proposal] daedalus jar repository (was: primary distribution location) Date: Wed, 26 Feb 2003 14:54:20 -0500 From: Noel J. Bergman [EMAIL PROTECTED] Reply-To: community@apache.org To: community@apache.org CC: [EMAIL PROTECTED] My proposal is that Dion Gillard be asked to chair a repository committee. He is the most familar with the issues, he works with a lot of the Java technologies (Tomcat, Ant, Maven, James, Jetspeed, Struts, Turbine), and although he is a Maven fan, he is agnostic in terms of ensuring that all build technologies would be supported. As for where the committee is located, personally I don't care if it were under Ant, Maven, Jakarta, Infrastructure, or the Blue Moon. But based upon the personality clashes from this morning, and knowing Dion quite well, I propose that Dw's earlier suggestion of infrastructure be followed, and this be an infrastructure sub-project. I just gave Dion a heads-up that I was going to propose this, and he is amenable if that is what people want to do. --- Noel - 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: licensing issues and jars in Avalon
Nicola Ken Barozzi wrote: 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. Possible? Yes. Recommended? IMHO, and not as an official statement of Apache policy... no. Specifically for checkstyle, my recommendation would be to make this package optional yet easy to obtain. In Ant terms, this would translate to a separate target which does the get for you, and to make the target which actually runs checkstyle optional based on the availability of this package. I do most of my development on Linux, and use a wide variety of GPL tools to do it. I also have been known to use fully licensed versions of Microsoft tools on Windows. None of them limit in any way the license to which the code I produce is distributed. Being *able* to use these tools myself and *requiring* others to do so is two different things. For some people, it would be impractical or against some personal or corporate policy for them to do so. That's why I would seek to verify that there is a compelling compensating benefit before I would consider making such things a requirement. By necessity, such decisions need to be made on a case by case basis. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build systems vs. license issues [Re: Hashing it out ...]
Torsten Curdt wrote: Actually I think we could make our lifes much easier by having better build systems! So we would only have the Apache code in out repositories and let the build system get the external dependencies for us. AFAIK this should save us from legal troubles. No, not necessarely. The problem with LGPL is that it doesn't define (in java) where the library stops and where your program starts. Having it downloaded from another machine, doesn't change that at all. Hm... but the question is: if something relies on something terms of *uses* it's API does this make it a problem? I mean that would be really like a viral infection! You couldn't even connect to software that is under (L)GPL. (What about protocols?) Is it really like that? I mean: how does it work for the PHP guys with all the modules and libraries then? In the case of GPL, it is clear and works as you fear above. Protocols (such as XML RPC or SOAP) are fine. ISTR code being removed from PHP due to such considerations, but it has been a while since I have been involved with that project. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: build systems vs. license issues [Re: Hashing it out ...]
Justin Erenkrantz wrote: I believe the FSF has an ulterior motive for keeping the Java situation quite murky. -- justin I'd like to caution you against attributing motives to other's actions or inactions. I'm not making this suggestion with any official Apache hat on, but based on my experience that such statements rarely lead to productive consequences. As for me, I would like to observe that we have the public statements made by the FSF, including the text of the GPL license. We have the knowledge that this issue has been around for a long time and has never been resolved. And we know that that people like Brian have invested a fair amount of time on this topic. What I conclude from this is that it would be both difficult and unlikely for a successful resolution of this issue. Despite the fact that quite a number of us (myself included) would love to see this resolved. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Santiago Gala wrote: Second, in jetspeed, David removed activation.jar some time ago (I think because of those issues). But I have reviewed our repo just now, and we still have mail.jar, which, I think, we should remove also. (Sun Binary Code License). If you confirm, I will take care that it is removed from the repository (being careful to make sure we don't break build procedures, updating docs, etc.) Confirmed. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: primary distribution location
Noel J. Bergman wrote: Not to put too fine a point on this, but just to understand. A number of Java packages, such as JNDI and JavaMail, completely decouple the client code from the service provider. I realize that this is addressing a completely different point, but if you take a look at the license for either JNDI or JavaMail, you will see that item (i) in the second supplimental license term in the Sun Microsystems, Inc. Binary Code License Agreement reads: Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs This makes the following non-compliant with the license: http://www.ibiblio.org/maven/jndi/jars/ http://www.ibiblio.org/maven/javamail/jars/ The interesting question is: who is liable? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ATTN: Maven developers [was: primary distribution location]
Rodent of Unusual Size wrote: Roy T. Fielding wrote: In short, the answer is no, and this applies to any software with copyright of The Apache Software Foundation. which brings up a very good point that may have been overlooked: this applies to anything on ibiblio or elsewhere that is copyright the asf. it does not apply strictly to the repositories on the asf machines, but to the asf *code*. This issue has come up before. This time, let's flatten it. In two weeks, there is a board meeting. At that time, I would like to be able to report that the contents of the Maven repository conforms to the policies of the Apache Software Foundation. Code under the ASF License is clearly OK. As is the IBM Public License (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following public domain components are also approved: Antlr and Doug Lea's concurrency package. Licenses clearly not conforming to the ASF's policies for distribution: LGPL, GPL, Sun's Binary Code License. Please direct any questions or comments (including new licenses to be considered) to [EMAIL PROTECTED] Some we can resolve for ourselves (e.g., the specific public domain packages above). Others I'll batch up and forward to the board and/or licensing folk. By the board meeting after that (3rd week in March), I'd like to have the infrastructure issues resolved (where should this data should be hosted, mirrored, etc). - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: failure notice
Rodent of Unusual Size wrote: Roy T. Fielding wrote: In short, the answer is no, and this applies to any software with copyright of The Apache Software Foundation. which brings up a very good point that may have been overlooked: this applies to anything on ibiblio or elsewhere that is copyright the asf. it does not apply strictly to the repositories on the asf machines, but to the asf *code*. This issue has come up before. This time, let's flatten it. In two weeks, there is a board meeting. At that time, I would like to be able to report that the contents of the Maven repository conforms to the policies of the Apache Software Foundation. Code under the ASF License is clearly OK. As is the IBM Public License (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following public domain components are also approved: Antlr and Doug Lea's concurrency package. Licenses clearly not conforming to the ASF's policies for distribution: LGPL, GPL, Sun's Binary Code License. Please direct any questions or comments (including new licenses to be considered) to [EMAIL PROTECTED] Some we can resolve for ourselves (e.g., the specific public domain packages above). Others I'll batch up and forward to the board and/or licensing folk. By the board meeting after that (3rd week in March), I'd like to have the infrastructure issues resolved (where should this data should be hosted, mirrored, etc). - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Leo Simons wrote: recent board decree (saw it first on the infrastructure list) (paraphrasing): the ASF must not distribute software packages (in any form) licensed under LGPL, GPL or Sun Binary Code License in any way. Sun's Binary Code license permits bundling as part of your Programs. The short form of this: you can include such things in tars and zips for your release, but for individually download. In other words, users need not feel the pain, but developers do. Personally, if there are open source alternatives, my recommendation is that they should be supported instead. I've identified the following jars in avalon CVS repositories which seem like they should be removed based on the information above: - checkstyle (jakarta-avalon-apps/tools/checkstyle-all.jar and other places) (LGPL) If available, then checkstyle can be used during a build - this should not be any different than using EMACs. Preferably, the build should skip this step if checkstyle is not available. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where we are.. continued..
[Following Dw's lead and moving to community] Bill Stoddard wrote: Pretty interesting. Marry this to some of the satellite photos available off the net and you could actually zoom down right to someones house. I can see cars in my driveway from some of the sat images. Spooky. http://mapper.acme.com/?lat=35.708298long=-78.695515003scale=13theme=Imagedot=Yes Repetively click on in. ICBM, eh? Gulp. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to place Agora?
Stefano Mazzocchi wrote: so, I wonder, should I go down the path of 'incubation'?, should I move it under the committers/ CVS? or in the community CVS? move it on sourceforge? should we clutter this mail list or should we ask for another one? Since you are an established member of the community and there likely isn't any IP issues, I don't see the point of incubation in this case. I'd say use committers CVS and community mailing list for now. If/when it become a full fledged project, simply present a resolution to the board. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF use of Instant Messaging
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. 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. - Sam Ruby
Re: Do vs. Talk (Re: email notification done...sorta)
James Taylor wrote: On Wed, 2003-01-08 at 23:58, Jeff Turner wrote: it is better to have ANY Wiki (here, UseModWiki) than try to establish a nonexistent consensus on which Wiki everyone agrees is best. That can be sorted out later, if people want it sorted out badly enough. I agree in general, but the Wiki is a great example of a place where a little more forward thinking might have been a good idea. Because wiki's tend to fill with content rapdily, once you use them for a little while you are pretty much locked in. Especially given this comment: Counterpoint? (No, I don't want to become embroiled in this dicussion). It certainly is easier to migrate content that exists, even if it is in the wrong format, than content that does not exist. - Sam Ruby
Re: Apache Trove
Steven Noels wrote: and should be maintained by the respective project communities. I already went searching what Gump could offer me in terms of available data, but Gump is for obvious reasons limited to Jakarta and XML (Java) projects. Adding the Gump people to add a 'keyword' element to their descriptors wouldn't cause too much harm, but the problem is that I also store the project hierarchy in my data file, and this is slightly orthogonal to Gump's structure. So adding extra data to Gump's descriptors would help, but not enough and not for everybody (including perl/php/...) 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. - Sam Ruby P.S. Gump is capable of running anything that can be run via the command line and produces output to stdout/stderr.
Re: [RFC] prototype committers list with links
James Strachan wrote: Which is the correct mail list to submit patches to the members.xml file? Just in case this is the one, I've attached a patch :-). Would [EMAIL PROTECTED] be more appropriate? James, while the patch has already been applied for you, take a look at: http://cvs.apache.org/viewcvs.cgi/site/xdocs/foundation/members.xml As a member, you have commit access. - Sam Ruby
Re: [RFC] prototype committers list with links
Tom Copeland wrote: I had the same problem as James when I tried to check out the site module James was recently inducted as an Apache Member, but apparently his unix commit privs have not yet caught up with that status, but hopefully will shortly. For more details on what membership is all about, see the first few paragraphs on http://www.apache.org/foundation/members.html . Meanwhile, I see that you are a committer on Maven. What would be excellent is if the following page were made more complete and expanded to include more information on the individuals involved: http://jakarta.apache.org/turbine/maven/team-list.html If this were done, I would gladly aggregate the results back into the ASF wide committer list. - Sam Ruby
Re: [RFC] prototype committers list with links
Kurt Schrader wrote: Meanwhile, I see that you are a committer on Maven. What would be excellent is if the following page were made more complete and expanded to include more information on the individuals involved: http://jakarta.apache.org/turbine/maven/team-list.html That page is automatically generated. What other information would you like to see on it? At a minimum, a URL where I can find out more about the individual. Alternatively, here's an example of what httpd project provides by way of introduction to it's contributors: http://httpd.apache.org/contributors/#coar (I selected Ken's entry as his information looked a bit more complete than others). - Sam Ruby
Re: [proposal] creation of communitity.apache.org
Aaron Bannert wrote: That is a noble goal, and I support this goal, although I do not think that an organized soapbox is the right way to do this. The short little here's the link to my homepage, oh and I work on this and that project pages are great. Anything other than that is off limits in my book. First, I don't recall Stefano proposing an organized soapbox. Aaron, can you take a moment and take a peek at http://www.apache.org/~fielding/ and indicate specifically what you think should be on and off limits? Overall, I would like to see this discussion move away from http://www.intrepidsoftware.com/fallacy/straw.htm arguments (which, to be fair was in response to an argument which at best contained http://www.intrepidsoftware.com/fallacy/pl.htm, and quite possibly could be categorized as http://www.intrepidsoftware.com/fallacy/attack.htm ). What I would like to see this discussion move towards is concrete and specific proposals and objections. And towards building consensus. For starters, we have http://incubator.apache.org/whoweare.html . Now let's entertain the notion of augmenting this allowing each committer to specify (via a completely opt-in basis) with a single hypertext link to the page of their choice. As has been pointed out, this is not materially different that what has been in place on http://www.apache.org/foundation/members.html for quite some time. If acceptable, then lets explore what guidelines we need to place (if any) on the content of pages and how such guidelines are to be enforced. Should the guidelines be different for on-site and off-site content? I personally would advocate very minimal guidelines, if any, but would be willing to compromise if that would increase consensus. Is there anyone out there willing to contribute specific proposals along these lines? - Sam Ruby
Re: [RFC] prototype committers list with links
Justin Erenkrantz wrote: 'nother thought. do we want to include in the karma column modules which aren't available through anoncvs/viewcvs? Yeah, I was thinking the same thing - we shouldn't include ones that aren't publically available. Perhaps we should have a list of 'dead' CVS repositories to exclude - for example, apache-1.2 isn't active any more... So, why not either (1) remove the anoncvs symbolic link, or (2) remove the name from the avail file. Either action will cause these entries to disappear from this generated page. Clearly, side files can be created to address this, but I find processes such as these provide insightful perspectives into the way things are set up that may motivate people to DoTheRightThing(TM). My only other comment would be not to bold ASF members. There's no good reason (IMHO) to distinguish them here. I won't take credit for this, but I must admit that I kinda like it. The visual clues are not overwhelming, and at the Town Hall we heard some say that they were not aware that there was such a thing as ASF membership. As I understand it from discussions with a number of people at ApacheCon, the overall goal is to get everyone who both gets it and appears likely to be sticking around for a while to become a member. Perhaps, this will provide a subtle push. Meanwhile, there undoubtably are cases where someone like Jim is looking up an id and would find it useful to know if the person is a member. This provides a such information all in one place. If I get time, I might take a pass at Sam's perl script and tweaking it accordingly. If someone beats me, great. =) Other than that, it's a great step in the right direction! Go Sam! =) Thanks! - Sam Ruby P.S. I posted some meta commentary on this discussion on the web. It shouldn't be very hard to find. ;-)
Re: [proposal] creation of communitity.apache.org
Stefano Mazzocchi wrote: I would like to propose the creation of such a virtual host so that all apache homepages will be hosted at http://community.apache.org/~name That page should be hosted on your public_html directory on your cvs.apache.org account (all committers have one, unlike www.apache.org where only a few do) A very small adjustment to the proposal: make community.apache.org/~name redirect to ~name/public_html/community or some such. This makes it completely opt-in. Those that don't want to participate, are not affected. - Sam Ruby
Re: [proposal] creation of communitity.apache.org
Sander Striker wrote: Which is simply not the case if not all committers and members are represented on there. Here is an effort that I made last year http://cvs.apache.org/~rubys/ Here is much move visually appealing and more maintained version: http://www.apache.org/~jim/committers.html Would starting with Jim's effort address your objections? Suppose I took the initiative to merge Jim and Ken's work, and come up with a page that looks exactly like Jim's but converted their CVS id into a hypertext link for individuals that chose to opt-in? The ASF has supportted .forward files for e-mail for quite some time. Would the mere act of putting a one line .forward file into your ~/public_html directory with your favorite URL be OK? - Sam Ruby
Re: [proposal] creation of communitity.apache.org
Ben Hyde wrote: //www.apache.org/foundation/members.html I'd be more comfortable if the individual committer pages were hosted outside the apache.org domain, as is the case with this example. - ben With a few notable exceptions, for example: http://www.apache.org/~fielding/ - Sam Ruby
Re: [proposal] creation of communitity.apache.org
My opinions exactly match Ken's below. - Sam Ruby Rodent of Unusual Size wrote: it looks like several issues are getting conflated again. 1. should people be permitted to have/publish *.apache.org/~name pages? 2. should they follow any sort of guidelines? 3. should there be a list of them? 4. should a list be mandatory or opt-in only? 5. is it an all-or-nothing proposition (everyone has them or no-one does)? here's my personal take on these questions: 1. should people be permitted to have/publish *.apache.org/~name pages? +1 2. should they follow any sort of guidelines? -0 (+1 if it's no more than 'don't put anything here that might reflect poorly on the asf') 3. should there be a list of them? +1. data-driven, either through something in peoples' cvs.apache.org/~name/ directory, like the one-off '.nopublish' i mentioned earlier, or a ~/.homepage like sam (?) suggested, or whatever. 4. should a list be mandatory or opt-in only? opt-in, of course. 5. is it an all-or-nothing proposition (everyone has them or no-one does)? -1. someone tries to force its opinion on me about how i may choose to express myself and describe my participation in the asf, i tell it to sod off in no uncertain terms. if someone doesn't like it, then it should a) not do it, and b) not look at others. but don't obstruct people who think the idea has value, particularly since it won't affect *you* in any way. (generic 'you' there, not anyone in mind at all.)
Re: [proposal] creation of communitity.apache.org
David Reid wrote: file://www.apache.org/foundation/members.html I'd be more comfortable if the individual committer pages were hosted outside the apache.org domain, as is the case with this example. - ben With a few notable exceptions, for example: http://www.apache.org/~fielding/ http://www.apache.org/~stefano/ Oh, are we keeping score? If we are I'll have to point out that somebody is hosting .doc files on his pages at apache.org. That's worth some points isn't it? Humor aside what point are you folks making? I've given up trying to figure that out as well... I was *NOT* trying to be funny. As I said at the Town Hall meeting of the ApacheCon... I am a committer, a PMC chair, a member, and a director... and for none of these roles does there seem to be a rulebook. Now here we have Ben Hyde saying that he is concerned what impact there would be on the ASF if committers were allowed to have personal pages hosted by the ASF. Meanwhile, the then chair of the ASF has long since hosted his favorite board games, sports, and quotes on www.apache.org. Is that clear enough? If not, the point I was really trying to make was best expressed by Ken: someone tries to force its opinion on me about how i may choose to express myself and describe my participation in the asf, i tell it to sod off in no uncertain terms. if someone doesn't like it, then it should a) not do it, and b) not look at others. but don't obstruct people who think the idea has value, particularly since it won't affect *you* in any way. (generic 'you' there, not anyone in mind at all. The ASF I wish to be a part of is one and/or create is one that tolerates differences in points of view or approach to solving problems. - Sam Ruby
Convergence, vetoes, forks, and projects
One nice thing about conferences is it permits a number of high bandwidth conversations that aren't practical via e-mail. I've talked to a number of people about the topics that have been discussed on this mailing list, and thought I would share some of my notes. These are merely meant to capture my understanding at this point in time, and not meant to be interpreted as authoritative. - - - All ASF projects need to move towards a direction whereby participants with commit privileges, voting rights, and PMC membership are largely converged. The current model whereby an umbrella project is permitted to exist with separate code bases with separate communities and is administered by a PMC which is largely separate from those committers is neither sustainable nor legally defensible. This is not a statement about number of CVS repositories or mailing lists, but merely one of commit privileges and voting rights. Vetoes are, as a general rule, anti-social behavior and are to be used sparingly. They are to be used to draw attention to stop-ship types of bugs and resolvable design disputes. Simple bugs should simply be handled routinely via e-mail, bug tracking mechanisms, or by directly making the fixes. Significant design disputes should be handled via internal forking allowing a separate proposal directory or perhaps even CVS tree to be created whereby a speculative design is explored. Forks should be clearly identified with separate names per the rules for revolutionaries e-mail. For external forks, i.e., ones that reside outside of ASF servers, this is all that is necessary. For internal forks, it is important to realize that the PMC is still accountable for that code and the rules for voting and commit privileges still apply. In other words, the creation of such internal forks is to be done based on consensus on the scope, visibility, and design direction of such an effort. This does not mean that there needs to be consensus of opinion on the viability of the design approach; merely that the idea merits exploration - even if the ultimate result is only to prove that it is indeed a dead end. As long this code resides under the purview of an existing PMC, no separate voting or commit rights should be sanctioned for this code. Nor should vetoes be used after the fact to change the agreed upon scope of such an effort. Separate code bases with separate communities should be separate projects. Independent of the size of the codebase, if the size of the community is only a few people, then it is not an ASF project. Such efforts can be pursued outside of the ASF, be pursued inside the Incubator, or be incorporated inside an existing community as long as all participants in that larger community are treated as peers. - Sam Ruby
Re: Rules for Revolutionaries
Daniel Rall wrote: Do you really think that Tomcat 4's startup time would've remained significantly worse than 3.3.x if those working on 3.3.x had migrated to working on 4? They wouldn't have. They would have migrated to SourceForge. That's the problem with an all volunteer army. The can't be trusted to do as they are told. - Sam Ruby
Re: Rules for Revolutionaries
Rodent of Unusual Size wrote: no, not if the revolutionary code is never accepted back into the main branch. if it isn't merged back in, it *isn't* part of the product and release; it remains a branch, or maybe gets forked into a completely separate product. Revolutionary code can become the main branch. Catalina became Tomcat 4. vetoed never makes it into a release. at least it had better not. it might end up in a branch or fork where it hasn't been vetoed, but that would be a different product with its own release. The key question here - if there truly is a fork, not just of the codebase but of the community, which one gets to keep the name? no again. vetoed code never makes it into a release. what you are describing is a pathological situation. solutions to it include the majority 'routing around' by forking a revolutionary branch and taking the name with it, and executive decision by some authority (for which there are currently no guidelines). Pathological? It happens. More frequently than you might expect. I'll be more than glad to share specifics, but some people seem squeamish about discussing such things in public. again, pathological. if things get to this point, the pmc/chair should take corrective/punitive action. commit access is a privilege, not a right; such behaviour as you describe is an abuse of that privilege. Forks happen. Two people with different visions, neither provably wrong, wishing to explore the consequences of a given set of design choices. Generally what occurs is one dies of natural causes. In other cases, a merge occurs as the ultimately it becomes possible to objectively determine if some of the promised benefits are fact or fantasy. - Sam Ruby
Re: request: terms/definitions for the glossary
Rodent of Unusual Size wrote: how the voting rules are applied is a per-community thing, supposedly spelt out in the group's guidelines. the basic things that apply across all projects are the concept of majority rule for non-code issues, the significance and application of vetos, and (((plus_1 = 3) || lazy_consensus) (! veto)) for code decisions and other things decided by the community to require that form of voting. Just to be clear: it is an ASF wide policy that releases are majority rule, is it not? (It is not clear to me whether this qualifies as a code issue or not, hence the clarification request). - Sam Ruby
Re: request: terms/definitions for the glossary
Rodent of Unusual Size wrote: there have been several mentions over the last three weeks concerning the need for an apache glossary. i've started roughing this out; if you're interested, please take a look at http://incubator.apache.org/drafts/glossary.html and let us know what terms/definitions should be added/changed.. Probably the most important items I see as missing are ones related to voting: in particular the concept of binding votes, and lazy consensus. In Jakarta, these can be inferred from http://jakarta.apache.org/site/decisions.html, but a more direct definition would probably be better. I actually would recommend that this glossary goes a bit further and defines vote and veto as both imply specific obligations that may not be obvious to someone not familiar with the ASF. - Sam Ruby
Re: [Fwd: [DRAFT1] Jakarta Newsletter - October 2002]
Andrew C. Oliver wrote: It would be nice if other people gave Rob a hand and maybe we expanded this to a wider scope.. Just so people can see examples of what the finished product looks like each month: http://jakarta.apache.org/site/news/ - Sam Ruby
[discussion] Jakarta PMC bylaws change
I'm planning on submitting a proposal to change the bylaws of Jakarta to bring Jakarta's PMC structure closer to the HTTPD one. Before I do so, I would like to gather the opinions of a self selecting cross section of both Jakarta and non-Jakarta committers, and it occurs to me that this mailing list enables me to do exactly that. My intent is not to rush to put in place any radical change, or to address all issues in one sweeping proposal. My intent is merely to put in place enough bylaws to enable the necessary changes to be made. My current thinking is to propose this formally after the ApacheCon to give people adequate time to discuss this, but feedback on both the content and timing are welcome. Enough preamble. Here's the outline of the proposed changes: 1) Eliminate any upper limit to the number of PMC members 2) Allow new PMC members to be proposed at any time 3) Remove references to resigning, add an emeritus status 4) Reinstate all past PMC members as emeritus status In addition to these bylaws, I anticipate a set of non-normative guidelines. Proposed PMC members will normally already be committers. Typically, a proposed PMC member will have been actively involved on a sustained basis (no significant gaps) for six months since becoming a committer. I intend to nominate any ASF members who are also Jakarta committers as new PMC members. The intent is that this is intended to be orthogonal to any proposals to promote an existing Jakarta subproject to become a top level project. Of course, people involved may voluntarily chose to change their status to emeritus, but are under no obligation to do so. Thoughts? - Sam Ruby
Re: comments on the votes
Stefano Mazzocchi wrote: First of all, I was very happy to see that 'openness' doesn't appear to be a quality of any particular group of people. I perceive this somewhat reducing the value of Sam's thesis that jakarta has an 'open' attitude that the rest of the ASF doesn't have. +1 - Sam Ruby
Re: [VOTE] Openness
Stefano Mazzocchi wrote: VOTE 1: would you like to make it possible for non-committers to read this mail list thru a web archive? [X] +1 yes, let's make it readable VOTE 2: would you like to make it possible for non-committers to fully subscribe to this mail list? [X] 0 don't know/don't care - Sam Ruby
Re: [VOTE] Open this list
Craig R. McClanahan wrote: Interestingly, this vote also helps crystalize who we think the Apache community really is. +1 -Sam Ruby
