Re: Low level community
On Sun, Jun 29, 2014 at 7:27 AM, Bertrand Delacretaz wrote: > Hi, > > On Sun, Jun 29, 2014 at 1:22 PM, Andy Seaborne 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 wrote: > On Wed, Sep 15, 2010 at 11:23 PM, Joe Schaefer 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 wrote: > On Sun, 12 Sep 2010 Jeff Hammerbacher 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]
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: 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: 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. - 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: 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 realize"oh 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: OASIS
Dirk-Willem van Gulik wrote: On Mon, 28 Jun 2004, Gianugo Rabellino wrote: So, far, are there *ANY* volunteers? If we manage to sort out the infrastructure/logistics and all the other points Dirk correctly raised, count me in. The volutneers wil be an active part of that - though we'll make sure that wee offer as much assistance as needed; and help to make sure that what lessons learned during earlier interactions with, say, the JCP process, is not lost. The JCP process was, and remains, a time consuming activity. Prior to establishing a formal relationship between Apache and the JCP, there effectively were a number of ASF people who were participating as "independents" in the JCP process. And there was interest from the ASF in formalizing this. If we create a formal relationship with OASIS, I want to ensure that it is sustainable. - 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: OASIS
Leo Simons wrote: If there's enough volunteers. So, far, are there *ANY* volunteers? - 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: Java + Scripting languages
Craig R. McClanahan wrote: http://www.jcp.org/en/jsr/detail?id=223 The specification may include a Java API that can be used, possibly through JNI, by an scripting language engine to access the desired Java objects. Can anyone give us a more concrete description of what this is really about? The basis for this is exactly what that sentence states -- scripting language users have said they would like to be able to access business logic and data objects inside a servlet-based application from their scripts, in a portable manner. The point of the JSR is to make that sort of thing possible. As Stefano points out, Sam did indeed create some code to do this. Just two little problem though, it's non-thread safe (uses instance variables for per-request state), and it's not scalable. And, it only deals with PHP, but there's lots of other scripting languages (and scripting language users) in the world that could benefit from the same ability. What I did with PHP was only a proof of concept. My focus wasn't only on PHP, but on a wide number of languages. I met personally with Eduardo on more than one occasion trying to generate interest in the subject. At the time, it was clear that his focus on on the 'one true programming language'. Sometimes it sucks to be four years ahead of your time. - 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=10002101&fc=NCSHORT&x=0&y=0&searchFName=Sam&searchMName=&searchLName=Ruby&searchCity=&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: Sun and the JCP 2.5
Andrew C. Oliver wrote: Who is on the current "scholarship" board? Any apache folks? Are you able to comment? Yes, Apache is on the "scholarship" board. If you want to discuss this further, you might consider joining the [EMAIL PROTECTED] mailing list. - 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]
Re: ASF repository URI syntax
Noel J. Bergman wrote: Guys, does this have much to do with 'community' anymore? From what I've read, it looks like a Java specific project. (a) Dw could tell us if/where he'd like us to have this dicussion. I still think that infrastructure-policy@ would be a good new mailing list. (b) It need not be Java-specific. My proposal is specifically not specific to Java. I mentioned binaries for httpd, and CPAN federation. I'm in a "just do it" kind of mood. I just created a [EMAIL PROTECTED] mailing list. Noel is the initial moderator. If/when there is an infrastructure.apache.org set up, I'll move the list to there. (currently it is [EMAIL PROTECTED]). If there is significant dissent, or the list falls into disuse, I'll simply delete the list. - Sam Ruby - 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
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]
[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: 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: 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]
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: [proposal] daedalus jar repository (was: primary distribution location)
Leo Simons wrote: Leo Simons wrote: Normally, I'd just ask the infrastructure peeps to umask 002 mkdir /www/www.apache.org/dist/java-repository chown :apcvs /www/www.apache.org/dist/java-repository and get things started, but given the unusual (well, maybe not ;) amount of controversy okay, so it looks like controversy is actuallly just perceived controversy, just a reaction or two, and all positive. Root, could you invoke your infinite power and execute the above commands on the daedalus machine? It doesn't look like it took much power. Any ASF member could do it. I'm an ASF member. Done. thanks & cheers, - Leo (avalon pmc member acting sort-of on behalf of "the java peeps" using the lazy consensus model and the Just-Do-It-in-the-event-of-consensus mindset :D) I like that mindset. Note: the essence of lazy consensus is that such actions are immeditely rolled back if an issue is raised. I plan to do exactly that. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Prof Eben Moglen on L/GPL and jars]
Is this clarification sufficient? If not, what more do we require? If there is a list of unowned todos to be resolved, I'll follow up on them. Original Message Subject: Prof Eben Moglen on L/GPL and jars Date: Thu, 20 Feb 2003 09:59:02 -0800 (PST) From: J Aaron Farr <[EMAIL PROTECTED]> Reply-To: "Jakarta General List" To: general@jakarta.apache.org With all the discussion about licensing with LGPL stuff, I thought this might be interesting to everyone. Comes from the new Slashdot interview with Eben Moglen. (http://interviews.slashdot.org/interviews/03/02/20/1544245.shtml?tid=117&tid=123) 2) Clarifying the GPL by sterno One issue that I know has come up for me is how the GPL applies in situations where I'm using GPL software but I'm not actually modifying it. For example, I write a Java application, and it is reliant on a JAR that is GPL'd. Do I then need to GPL my software? I haven't changed the JAR in anyway, I'm just redistributing it with my software. The end user could just as easily download the JAR themselves, it's just a convenience for me to offer it in my package. Eben: The language or programming paradigm in use doesn't determine the rules of compliance, nor does whether the GPL'd code has been modified. The situation is no different than the one where your code depends on static or dynamic linking of a GPL'd library, say GNU readline. Your code, in order to operate, must be combined with the GPL'd code, forming a new combined work, which under GPL section 2(b) must be distributed under the terms of the GPL and only the GPL. If the author of the other code had chosen to release his JAR under the Lesser GPL, your contribution to the combined work could be released under any license of your choosing, but by releasing under GPL he or she chose to invoke the principle of "share and share alike." --- jaaron - 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 ...]
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: 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 ...]
Santiago Gala wrote: Torsten Curdt wrote: (...) ..the only drawback is that the distributions are not self-contained and not compile-able out-of-the-box. Be sure to blame the approprite culprit, so that user frustratin does not stand on us. Like "company XXX forbids us to bundle a essential component because of licensing issues. Please go to , download it and put it here". +1 OTOH, one of the main problems is Sun Binary License. This license *allows* redistribution with our products, just it does not allow individual download. So the problem is mainly for *new* developers, having more errors and steeper learning curve. +1 A nice workaround for Sun's jars would be to have a software release called "external_dependency_solver", where several or those jars could be bundled, together with version checking and some documentation. This would be aimed to developers, as part of the "Apache Java toolkit" Hei, experts, would this make a way out of this? Is it twisting things too much? This is twisting things too much. I am aware of other dicussions outside the scope of Apache. In those discussions on other topics, the crucial question is one of "value add". On the other side, negotiating exemptions or rewording of licenses is good, but it is a heavy and difficult path. It's sad, but we want to play by the rules until we manage to change them ;-) +1 Regards, Santiago - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath Licensing
Nic Ferrier wrote: > >> Serge: The Classpath author adds an addendum to allow bundling of >> this library into an executable, but that still won't allow us to >> distribute jars in CVS or downloadable with source builds (never >> mind Java doesn't have executables). ibiblio would still be in >> violation of the license, as would CVSWeb, CVS, and anything that >> allowed these Jars to be downloaded independently. > > This is not correct. The exception allows Apache (or any) code to > object link to ClasspathX code. > > Distributing the jar file is not a problem. > > Noel said: > >> By the way, if you are curious about the LGPL, I understand that >> one of the problems with the LGPL is this clause: "When a "work >> that uses the Library" uses material from a header file that is >> part of the Library, the object code for the work may be a >> derivative work of the Library even though the source code is not. >> Whether this is true is especially significant if the work can be >> linked without the Library, or if the work is itself a library. > >> The threshold for this to be true is not precisely defined by law." >> >> Because the FSF has thus far declined to clarify the picture for >> Java, the preceding clause is interpreted that simply an import >> could be construed to contaminate the importing class. > > The FSF is clear on the issue. You can object link LGPLed Java with > other code without special permission. This is because there is no > textual inclusion. > > The GPL+exception btw is well understood on this side of the fence > because it is the licence Guile has used for many years to protect > the source code but not preventing linking to other code. Can somebody provide a clear and unambiguous public reference that explicitly addresses such issues as the use of the Java import statement? IANAL, but I can tell you that lawyers who know far more about this matter than I have reviewed the license and not come to the same conclusion. Part of the issue is that the terms "object link" are not well defined for Java programs. In many was, import in Java operates much as #include does in C. - 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: 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]
ATTN: Maven developers [was: primary distribution location]
[Retry with a better subject line and the proper mailing lists addreses ... sigh] 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] - 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]
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: 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]
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.708298&long=-78.695515003&scale=13&theme=Image&dot=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: 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. 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. 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-dev&m=103936130220759&w=2 - Sam Ruby P.S. An example of the types of report that Gump produces: http://cvs.apache.org/builds/gump/latest/xref.html
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
Ask Bjoern Hansen wrote: In the case of Maven, it would seem to me that a or element inside elements in project.xml files would be most appropriate. Working on adding element as we speak. Gah; bike shedding at work! Just having each project (and the member list) keep it updated via their own pages seems much simpler and in a very simple way it makes it clear that the committer did an opt-in. Actually, I don't believe so. The proposed element will presumably be added to the input source from which the Maven Project Team page is generated. It will still be up to the individual to explicitly provide it, and will be monitored and maintained by the project. After that point, one of us will screen scrape it. ;-) - Sam Ruby
Re: [RFC] prototype committers list with links
James Strachan wrote: Actually now my brain's engaging (sorry its been one of those days) - maybe Sam's script could create a committers.xml file that things like the Maven build could use to auto-link to committers home pages (if available)? Which came first, the chicken or the egg? I'm looking for a set of pages from which I can gather links. To date, I am mining information from: http://www.apache.org/foundation/members.html http://jakarta.apache.org/site/whoweare.html http://httpd.apache.org/contributors/ I'd like the sources to be maintained by the committer, and monitored by the community/ies in which that committer participates. In the case of Maven, it would seem to me that a or element inside elements in project.xml files would be most appropriate. - Sam Ruby
Re: [RFC] prototype committers list with links
James Strachan wrote: Incidentally we could get Maven to automatically generate URLs of the form http://www.apache.org/~username/ then it'd be the apache committer's responsibility to create either a .forward or a html home page. How's that sound? It seems to me that you would generate a lot of 404's. And the consensus from the discussion that lead up to this prototype is that links should be explicitly opt in, and that people should be encouraged to host them off site (note: some expressed this in more stronger terms, others expressed a more tolerant view). Also, not all committers have access to daedalus, and some people have hosted other content there without intending it to be a home page. All in all, my suggestion is that if no URL is provided, then treat this as an indication that no further information is available. - 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: [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
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: [proposal] creation of communitity.apache.org
Stefano Mazzocchi wrote: Now, I wonder: why don't we use the 'community' CVS repository for personal pages? (or create another "community-pages" repository) what do you think? In general, it seems to me that an ASF wide repository is less likely to be actively monitored, maintained, and policed than a set of community specific repositories. Personally, what I would like to see is pages like http://xml.apache.org/cocoon/who.html lead the way, and the results get aggregated up into pages like http://cvs.apache.org/~rubys/committers.html . Also, putting the pages themselves in cvs also means that they must be statically rendered. While that might be OK for some, it would also exclude pages such as http://outerthought.net/wiki/Wiki.jsp?page=StevenNoels . Trust me, the results can still be spidered and the results put in a form suitable for input into your http://www.apache.org/~stefano/community/ page. - 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: [RFC] prototype committers list with links
Rodent of Unusual Size wrote: 'nother thought. do we want to include in the karma column modules which aren't available through anoncvs/viewcvs? Fixed. - Sam Ruby
Re: [RFC] prototype committers list with links
Rodent of Unusual Size wrote: Sam Ruby wrote: Fire away with comments, criticisms, suggestions, and most importantly, patches. I believe that this addresses most, if not all, of the concerns identified to date. If not, let me know. i would prefer to have my name link to my cvs.apache.org/~coar/ page. So update one or both of the following: http://cvs.apache.org/viewcvs.cgi/site/xdocs/foundation/members.xml http://cvs.apache.org/viewcvs.cgi/httpd-site/xdocs/contributors/index.xml and regen and publish the site. 1) The links were lovingly screen scraped so this isn't data-driven? feh. should be. future rev. It is very much data-driven. It just is opportunistic and uses existing data sources instead of requiring yet another repository which is less likely to be maintained and/or have the appropriate level of oversight. A ripe area for future exploration is a common format and/or locating scheme for community pages. - Sam Ruby
[RFC] prototype committers list with links
Web page can be found at: http://cvs.apache.org/~rubys/committers.html Source to the script can be found at: http://cvs.apache.org/~rubys/committers.pl Fire away with comments, criticisms, suggestions, and most importantly, patches. I believe that this addresses most, if not all, of the concerns identified to date. If not, let me know. Notes: 1) The links were lovingly screen scraped from the httpd, jakarta, and members pages. In the case where a multiple links are associated with an id, one is chosen essentially randomly (hint: community pages which provide actual apache user ids are taken as more authoritative as ones that merely provide names). 2) The list is all inclusive for committers, but in order to get a link to appear on this page you must have an entry on a community page and furthermore provide a link (i.e., presence of links are both community monitored/enforced and totally opt-in). 3) No validation of any kind of the content of the website referenced by the URL is enforced. 4) People are free to "deep link" to this page in its current location, but the ultimate goal is for this content to migrate to a more prominent and stable location. - Sam Ruby
Re: [proposal] creation of communitity.apache.org
Justin Erenkrantz wrote: --On Monday, December 2, 2002 8:39 AM +0100 Nicola Ken Barozzi <[EMAIL PROTECTED]> wrote: I don't think we are talking about complete personal websites with blogs and such, with rants and honeymoon pictures, but about some pages that explain what the person does, who he is, and not much more. Of course we are. We're saying that anyone can post whatever they want on their apache.org site. That's what I'm against. I don't want people posting their honeymoon pictures or their Beanie Babies collection. But, as soon as we say, 'you can post whatever you want,' that's what is going to happen. Saying otherwise is foolish. I agree with Nicola Ken. We *are* talking about different things. Stefano proposed a short bio, picture, etc. (Although, to date I have not had a significant problem with people mispronouncing my name). You are objecting to Beanie Babies. If it will help further consensus, I will object to Beanie Babies too. Unfortunately, Roy's site is sort of an example of what I don't want to see. However, what I believe Sam hasn't realized is that Roy *just* moved his site there from the UCI servers while he looks for a new home for his web site. (Roy will correct me if I'm wrong.) I trust Roy not to post anything inappropriate, so I'm not going to complain because I believe it's temporary. Yet, not every committer has earned my trust in the way Roy has. I trust Roy too, and find absolutely nothing offensive or counter to the goals of the ASF in his page. To the contrary, I believe that it is helpful for people to get to know their board members, the ASF membership in general, and peers. Is it a complete solution? Certainly not. But it is a start. Furthermore, I tend to start out from a position of trust. This certainly can benefit from being coupled with a little bit of education. Perhaps the incubator could help educate people that these pages are a community resource and that people should be mindful of putting content out there that might damage the ASF. Justin, if you would like to put forward a set of rules, guidelines, and suggest an enforcement mechanism, I would be inclined to endorse it if it would further consensus. And, what Andy is missing is that with a DNS alias, there would now be an implicit approval of these sites. Furthermore, there would be a directory of people who have sites publically linked. Right now, there is no such approval or directory. There is such a directory for members. And I'm pleased to report that I have yet to come across a Beanie Baby in any of the links I have visited. Now there is a directory for committers (several, actually). Let's combine the best from each, adding guidelines where necessary, and move forward. - 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: [proposal] creation of communitity.apache.org
James Cox wrote: Not meaning to pick on you Andrew but this comment really made me feel i had to respond. Sun has a long standing relationship with the ASF, one that has taken alot of time to build, as well as contributed alot either way with regards to both code and community development. I would hate to see a situation where just one person could destroy that relationship.. and the above comment suggests that you don't really understand [the benefits of] the ASF's association with Sun. I believe I have a fair appreciation of the value of this relationship. Now, look at what an *ASF*member* put on http://jakarta.apache.org/ at one point: http://cvs.apache.org/viewcvs/~checkout~/jakarta-site2/docs/index.html?rev=1.52&content-type=text/html One way to solve this is to remove all commit access to all apache.org web sites from all committers and members. And while we are at it, we should probably drop @apache.org e-mail addresses. Oh, and since this particular topic was discussed to death on the general@jakarta.apache.org mailing list, we should seriously consider whether or not the risks of having ASF hosted mailing lists outweigh the benefits. Another way to address this is via education and community pressure. - Sam Ruby
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
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
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
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: I'm concerned that a few highly vocal members might generate the impression that the foundation is taking positions that it's not. I would be much more concerned about committers having @apache.org mailing list addresses. - Sam Ruby
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
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
Costin Manolache wrote: On Wed, 2002-11-13 at 04:20, Rodent of Unusual Size wrote: not strictly true, although mostly. a product release may be effectively vetoed by the asf officer with oversight of the project, if it appears in that person's judgement that releasing it would be the Wrong Thing I'm curious - are those rules invented as we go ? Sam - you are the PMC chair for jakarta, did you know that rule ? Or the rules about direct ( and non-delegating ) oversight, or the non-protection for non-PMC members? You ask several questions here. Let me answer them one at a time. In http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html, a meeting that you were in physical attendance, one of the roles of the PMC was to act as the veto of last resort. One such instance where I would personally exercise such a veto is if the majority of committers to Tomcat were to want to create a release which is not compliant with the servlet APIs. This is not the only reference I have made to the phrase "veto of last resort". I am aware that the role defined for the chairman of a PMC is a special one. One that I do not, as a rule, chose to draw attention to. To be perfectly honest, I am not clear on rules which outright preclude delegation. However, one thing I will observe is that Jakarta has not effectively delegated the oversight of Avalon, something that must be corrected ASAP. As to the non-protection of non-PMC members, IANAL. But one thing I am pretty sure of is that if we cannot establish a clear set of accountability, the ASF itself is exposed. I would feel much better if you did - and decided to not tell the rest of us for whatever reasons. Because if you didn't - I think ASF has a very serious problem. I do believe that the ASF has a number of challenges at the moment. And in my perception of the scheme of things, the topic referenced by this subject line doesn't quite rank. Nearly two years ago, there was a near-complete fork of Tomcat. In consultation with Brian and Roy, the Jakarta PMC worked with the developers of Tomcat to build a plan. That plan explicitly allowed further releases of Tomcat 3, even with new functionallity. The hope was that ultimately the result would be a converged Tomcat 5. Now that that goal is within our collective grasp, there seem to be some who wish to reinforce the rapidly dampening waves. Ultimately, they will be unsuccessful. What is a more significant challenge that the ASF need to address is the problem of accountability and effective oversight. The proper path (again IMHO) is to establish groups that can be trusted to be self-governing and self-regulating. In my admittedly biased opinion, Jakarta largely meets this criteria, with some some glaringly obvious exceptions that are being addressed. - Sam Ruby
Re: Rules for Revolutionaries
Ovidiu Predescu wrote: I'm glad this actually didn't happen, since it took a long time for the 4.0 branch to become stable and usable. If it weren't for the "legacy" codebase being continually developed, we would have been stuck with a slow 3.2 and a buggy 4.0. I've used Tomcat 3.3 for more than a year before switching to 4.1, and I liked 3.3 a lot for its speed and features. What would have been more likely to happen is that Tomcat 3.3 would have continued on SourceForge, been known by a different name, had a fully supported servlet 2.3 facade, and would have been known as the production quality servlet engine. In retrospect, I think the decision to continue the development on both Tomcat versions was a good one. It let the time solve the frictions. The result is that now we have a very mature Tomcat community, and little of the past problems are reflected today on the mailing list. +1 - Sam Ruby
Re: @apache web pages
Andrew C. Oliver wrote: no statically generated. Basically committer dirs are registered in a config file and then the forrest goes and generates them all. yes. Only I envisioned it in cvs. Given this, why must Forrest run on icarus or daedalus? For example, I could run it on the machine that does the Gump runs and upload the results. - Sam Ruby
Re: Rules for Revolutionaries
Stefano Mazzocchi wrote: I still disagree. The rules of revolutionaries *MUST* (I repeat *MUST*!!!) protect the identity of the project more than they protect the freedom of innovation of the single developers. More than anything else, the fact that two different codebases were *released* with the same name at the same time, pissed many people off (myself included) and created a lot of problems in the users. We covered this at great length with Brian and Roy in the meeting in on 17 Jan 2001. This was covered briefly in the minutes: http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html, look for "Brian gave an overview of the FreeBSD release strategies". What was agreed at the time was that Tomcat 3.0 was the reference implementation of 2.2/1.1, and Tomcat 4.0 was the reference implementation of 2.3/1.2. Anything beyond this agreement was to be proposed as Tomcat 5.0. > How do you feel about this? I feel that this advice was followed extremely closely. - Sam Ruby
Re: Rules for Revolutionaries
Ceki Gülcü wrote: I keep wondering why you keep bringing up Duncan's Whoa Bessie... mail. I mean this one: http://marc.theaimsgroup.com/?l=ant-dev&m=97712718421034&w=2 I differed with the rendition that Stefano put forward. And I differ with the new rendition he has now put forward. Duncan immediately had respect as an equal. He did not need to re-earn it, he was immediately granted it. He had an immediate right to a vote. However, and this is an important point, his ability to influence was limited only by his ability to persuade others. I said as much then: http://marc.theaimsgroup.com/?l=ant-dev&m=97743388217180&w=2 - 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: Rules for Revolutionaries
Rodent of Unusual Size wrote: my curiousity has been set off again. there have been numerous mentions of the revolution concept as used in jakarta, and its widespread acceptance as policy. however, i don't see it mentioned in the jakarta guidelines; in fact, only in ted's proposal for new guidelines. is jakarta's semi-formal acceptance of it as an operating principle actually recorded anywhere, or is it actually just an 'everybody knows that' informal general acceptance? "general acceptance" is probably too strong a word. There are some, including apparently the original author, who now have doubts. But there can be no doubt that this document has strongly influenced the evolution of a number of Jakarta projects. For further reading, I'd recommend taking a look at topics 3 and 4 in http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html In my mind, the concepts of vetoes, revolutions, and releases being a majority decision are linked. Note: when Roy made the statement about releases, it sure sounded to me like he was stating it as if it were ASF policy. In any case, I would recommend that it be so. Taken together, provisions are made for individuals to get attention to be focused on issues that they feel are important, individuals or even small groups can flesh out concepts that may initially be controversial, and a safety valve is provided so that forward progress can still be made. - Sam Ruby
Re: Rules for Revolutionaries
Stefano Mazzocchi wrote: Duncan is the original author of both Tomcat 3.x and Ant. He became more and more involved into open source evangelization activity in Sun (where he worked at that time) and detached from the Ant development community. At some point, he came back, he didn't like some of the technical/design choices that were done and proposed his own. Since these changes were revolutionary, he wanted to use the rules for revolutionaries and start working on its own internal fork codenamed 'amber'. Dry story: he was told he had to re-earn committership in order to do that. He tried to fought that, but got pissed after slamming on some rubber walls and left, leaving a bad taste in many people's mouths. His own first. I differ with that rendition, and believe that it is harmful to the community for it to be propogated. Duncan rejoined Ant and was immediately accepted as a committer. He started work on an internal fork named "AntEater". This went on for a short while, until another fork came along named "AntFarm". At that point, Duncan said "Whoa Bessie" and started to put forward a case that he had a unique right to determine what codebase bore the Ant name. This lead up to a PMC meeeting with Brian and Roy in attendance where it was affirmed that the name of a project went with the expressed wishes of a majority of commmitters to that project. This has been the policy that we have followed in Jakarta ever since. References: http://marc.theaimsgroup.com/?l=ant-dev&m=97712718421034&w=2 http://marc.theaimsgroup.com/?t=97712745500023&r=1&w=2 http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html - Sam Ruby P.S. It is my understanding that what is now Apache HTTPD 2.0 is also the result of a number of forks, one of which ultimately emerged as being the one accepted by the community.
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: [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
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: [discussion] Jakarta PMC bylaws change
Rodent of Unusual Size wrote: Sam Ruby wrote: I'm planning on submitting a proposal to change the bylaws of Jakarta to bring Jakarta's PMC structure closer to the HTTPD one. btw, sam, where are the current bylaws? or do they go by another name? http://jakarta.apache.org/site/management.html - 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: ASF Membership Nomination
Ted Husted wrote: Lists are how we procreate. Eee... Perhaps there *are* some things that really should be done in private. - Sam Ruby
Re: ASF Membership Nomination
Andrew C. Oliver wrote: I'm looking for the text version of this: http://jakarta.apache.org/site/agreement.html which is supposedly in text form SOMEWHERE in CVS in some module... http://cvs.apache.org/viewcvs.cgi/~checkout~/jakarta-site2/xdocs/site/agreement.xml - 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: ASF Membership Nomination
Stefano Mazzocchi wrote: While I would like to continue with open processes that are kept private only when specific events require it. Why? mostly because of the perception given to the people. Perception is important, expecially in building a community. But at the end, I think there is very little difference between the two processes technically, what is important is just the perception given to the people of the community. And I think this list shows that Jakarta is much healthier than the rest of the ASF in that respect. Even if, sometimes, they have been even *too* open. But keeping things balanced is a very difficult thing. +1 - Sam Ruby
Re: idiot.html
Joe Schaefer wrote: With all due respect, you might be safer standing behind Jon than Sam. What's the point of local governance if the governing bodies are incapable of dealing with trivial issues like this one? FYI: Jon was the person who first nominated me as chair of Jakarta: http://jakarta.apache.org/site/pmc/01-01-17-meeting-minutes.html and this vote occurred on the general@jakarta.apache.org mailing list: http://marc.theaimsgroup.com/?l=jakarta-general&m=98028130104993&w=2 - Sam Ruby P.S. Jon was also the one who nominated me as an ASF member.
Re: ASF Membership Nomination
Greg Stein wrote: Sorry, but nominations for membership, commit status, or PMC membership really should be private. I absolutely will not participate in such an environment, and will encourage others to avoid it also. These kinds of discussions really don't enhance the community. Greg, At a minimum, please acknowledge that a large number of ASF commiters have never participated in (or even have access to) private ASF mailing lists, have only seen commiter nominations done in public (and many have done so themselves), and the only PMC nominations that they have seen have also been done in the open (Jakarta, XML). - Sam Ruby
Re: idiot.html
Stephen McConnell wrote: I like the love.html alternative - is embrassing, more depth, warmth, and has a level of empathy that somehow get's lost in the other document. Cheers, Steve. :-D FYI: [EMAIL PROTECTED] site]$ls -l love.* lrwxrwxr-x 1 jon jakarta 10 Jul 17 09:47 love.html -> idiot.html As I said before, Jon is unique. - Sam Ruby
Re: idiot.html
Joe Schaefer wrote: For the sake of argument, you may assume I have looked at every document in the http://jakarta.apache.org/site/ directory. If you don't see what I'm driving at yet, I encourage you to post the url of a similar document anywhere else in the ASF (outside of the jakarta family, of course). Careful. As I have been saying before, there are multiple ways to look at these things. It has been pointed out that Jakarta committers have had very little exposure to ASF members. Don't judge Jakarta committers by the actions of the few ASF members that have cared enough to participate. Like Jon. Here's an exercise for you: find a similar document created by a non-ASF member. - Sam Ruby
Re: idiot.html
Joe Schaefer wrote: If it doesn't reflect the attitude of the jakarta community, but instead represents the views of one individual, then doesn't the page belong in his subdirectory? I dunno, something like http://jakarta.apache.org/site/jon/idiot.html might be more appropriate. Hey - I've got an idea! Why don't *YOU* suggest this to Jon? I'll be right behind you. *WAY* behind you. ;-) - Sam Ruby
Re: idiot.html Re: [VOTE] Open this list
Joe Schaefer wrote: http://jakarta.apache.org/site/idiot.html What is the point of that url? Do other ASF projects (php?) have similar links on their support site? No, I think that's unique. It is a long story, and has everything to do with one individual. You can read more about that individual here: http://jakarta.apache.org/site/jon.html - Sam Ruby
Re: ASF Membership Nomination: Ted Husted
Craig R. McClanahan wrote: I hereby nominate Ted Husted. Ted has been a long term committer on Struts and Jakarta Commons, and his code contributions have been valuable. But, in addition to that, Ted has taken the lead at attempting to help us codify our policies and procedures, and helping us clarify what we mean by "the Apache way". This has been demonstrated during the development of Jakarta Commons, and is also clear in his frequent, positive, and constructive contributions to the ongoing discussions about the organization of Apache as a whole. Would any ASF member care to second this nomination? I enthusiastically second this nomination! Craig McClanahan
[NOMINATION] Morgan Delagrange for ASF Membership
I hereby nominate Morgan Delagrange for ASF Membership. Morgan has been a committer since December of 2000 on a number of Jakarta subprojects, including taglibs, commons, and watchdog. However, his coding efforts don't begin to capture his contributions efforts to the ASF - he was amongst the first to suggest the need for what became jakarta-commons, and contributed significantly to the charter thereof. He has also contributed significantly to the documentation of the processes that committers in these respective codebases are following. His contributions to general project discussions are frequent and constructive. Any current ASF member care to second this nomination? - Sam Ruby
Re: Apache Community (was Re: [VOTE] Open this list)
Rodent of Unusual Size wrote: "B. W. Fitzpatrick" wrote: Limit the list to committers (with no public archive or posting ability) but allow committers to nominate "users" who have contributed to the Apache community, but not in a developer role (or users could ask to be added)? It seems to me that this would satisfy concerns about dividing community. Or is it enough? i think this is the happiest medium. IMHO, the contentious issue is whether or not publicly accessible archives should be provided. - Sam Ruby
Apache Community (was Re: [VOTE] Open this list)
James Cox wrote: > > Whilst i agree with Sam -- we do have to be open -- we're still a > closed foundation, one that benefits from it's meritocracy of > interested experts. I sincerely compliment you on your courage, honesty and ability to clearly state this. Many people would avoid actually making that statement. Kudos. Craig R. McClanahan wrote: > > Interestingly, this vote also helps crystalize who we think the > "Apache community" really is. Now, take a look at the description of users on http://www.apache.org/foundation/roles.html For that matter, take a look at the last five words of the first paragraph of http://www.apache.org/ Sam Ruby wrote: > There are going to be culture [clashes] as we try to move towards > becoming one big happy family. Most of it is due to ingrained > assumptions that we have all built up over long periods of time. My > aim is to actively seek them out and surface them for all of us to > inspect, discuss, and learn from. As applied here, I would like us to come to a common understanding of what the term "Apache community" means, and make the name of this mailing list, the access policies thereof, and the usage of these terms on our public website (in particular prominent ones, like the ones I cited above) consistent with this common understanding. - Sam Ruby
Re: [PROPOSAL] Tapestry joins Jakarta
Andrew C. Oliver wrote: WHO needs to vote? Jakarta or Incubator? From reading this incubator.apache.org I would say the incubator. However I think that makes it a top level project. Otherwise its jakarta. Jakarta could vote right now, but the LGPL issue alone gives me the whillies. And it would be hard to get a 3/4 majority with my -1. The incubator will forward the code base to the appropriate home. Ken has indicated that Jakarta could be the right home. But we will never know until the process gets started. - Sam Ruby
Re: Why aren't they committers? (was: [VOTE] Open this list)
Rodent of Unusual Size wrote: Sam Ruby wrote: There are going to be culture classes as we try to move towards becoming one big happy family. did you mean 'clashes'? just want to make sure, since it changes the meaning a little.. :-) Ouch! Yes. Ever notice how many of your typos end up being amazingly close to keywords in programming languages that you happen to use... :-) - Sam Ruby
Why aren't they committers? (was: [VOTE] Open this list)
Peter Donald wrote: Why do non-committers care about how Apache is evolving? And if they care so much why aren't they committers? There are going to be culture classes as we try to move towards becoming one big happy family. Most of it is due to ingrained assumptions that we have all built up over long periods of time. My aim is to actively seek them out and surface them for all of us to inspect, discuss, and learn from. Peter, take a moment and glance at http://httpd.apache.org/dev/guidelines.html. Search for "Apache Developers". - Sam Ruby
