Re: IRC Channel?
On Aug 15, 2006, at 2:38 AM, Ian Holsman wrote: It isn't the individuals who make the decision, but the community as a whole. If they feel more comfortable using X to communicate then fine. If a individual doesn't like the method the project is communicating with then it is up to him to convince the rest of the community/project to change. No. All Apache development decisions are done on public email lists. I don't think the board has ever allowed a project to adopt guidelines that differed from that fundamental requirement. probably.. i tend to exaggerate. but email is a *very* hard medium to communicate ideas. take this thread for example. If we were talking on the phone or on IRC it would been settled in 20minutes.. but now there are 20 messages over 4 days, and people like me jumping into the middle of it, using HTML mail and all that. How can it be settled in 20 minutes when less than 1/3 of the group is on-line? It is settled only in the minds of the clique that you are aware of at that time, which is precisely why it is not allowed as a decision-making method at Apache. Email communication is hard -- it forces most people to think before they write a lot of mindless drivel, or at least think before they press the send button on the drivel they wrote. IRC does not have that barrier, true, but that shows both in the quantity of drivel and the quality of the decisions made. I know of a solution that will bridge the gap, but it is still a cloaked start-up right now -- I'll send more info on that solution when there is something that we can use. Note that the fact that we use email to make project-level decisions doesn't mean we *do* everything by sending email messages and then waiting for responses. The vast amount of real work is simply done first and communicated later, prototyped/tested and then proposed as a complete concept, or discussed vaguely at some point in the past and then implemented by someone else off-line. I've seen a lot of discussions where people lead off with an open-ended question and then wait for a response, but that is usually for long-term issues or bike-shed topics that can't be settled quickly anyway. agreed... without experimentation we won't know if IRC or VOIP is better, and produces a better quality/amount. Hmm, IIRC, we already experimented on that issue and discovered the result. I think it was before your time, but APR was mostly designed on IRC and various in-person meetings. I only have one thing to say about that: http://www.utahphillips.org/stuff/mooseturdpie.mp3 Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 16/08/06, Henning Schmiedehausen [EMAIL PROTECTED] wrote: Gee, now here is a sensitive subject. :-) IRC BTW is very flaky if you don't have good connection (as most people at AC currently experience). Mail is much better for that because it is not as volatile as IRC. Hmm, that's not universally true though - Over the last year or so, SF mailing lists have have various /prolonged/ outages whereas Freenode IRC has not (as far as I know). IRC is a not a good thing if you want to have a community discuss decisions unless all developers are in the same time zone (and not even then). Strictly, online at the same moment rather than in the same time zone. /Gwyn -- Download Wicket 1.2.1 now! - http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?
+1 On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote: On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository Noel, shall I go ahead and create the above? They get my +1 from a repository@ point of view. Pinging on this to make sure the Incubator is happy with the idea before I set it up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
You mean like this: http://docs.codehaus.org/display/MAVEN/IRC+Log+Design+Discussion+26+May+2005 On 8/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. geir Regards Jan Blok Jim Jagielski wrote: I think one way of looking at this is simply remembering that the ASF values community over code. Yes, IRC and other real-time communication methods means quicker code development, etc, but it places, IMO, an undue barrier to the development of the community. - 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] -- http://www.multitask.com.au/people/dion/ If you even dream of beating me you'd better wake up and apologize - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forming an ActiveMQ PPMC
On Aug 16, 2006, at 12:32 AM, James Strachan wrote: On 8/16/06, Brian McCallister [EMAIL PROTECTED] wrote: The ActiveMQ committers have decided to aim for TLP status (1), as such we need to get a PPMC in place. Thus far we have been working under a committer votes all count style (really, everyone's vote counts, it is on a public list without any of the mine is binding stuff that has become popular), so I would like to open the discussion of formalizing the PPMC as all current committers on ActiveMQ. FWIW we've had a PPMC in place for some time ;) which was mostly the committers plus anyone from Incubator/Geronimo PMCs who wanted to help too. (Brian search your mailbox for activemq-ppmc or activemq-private which is the latest name of the mailing list - I've seen at least 2 posts from you :) Hah, you are right! Okay, I feel stupid. /me is going to find a *lot* more coffee :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Noel J. Bergman wrote: Either way, separate lists and source control areas. Many of our specs are done JDK-style: as javadoc embedded directly in our implementation. We use javadoc tags to identify implementation-specific information, such that we can generate both spec and doc from a single source tree. We shifted to this style very deliberately (we started out doing specs as separate docs, and still have older specs in that form). - Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Sanjiva Weerawarana wrote: However, the current structure appears to be org.jini.* for APIs and com.sun.something.* for implementation. Clearly that structure says there can be multiple implementations - and in that case I'm against putting the two parts together. Can you expand on why you're against? (Aside: it's net.jini.*) - Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Sanjiva Weerawarana wrote: On Tue, 2006-08-15 at 17:36 -0400, Jim Hurley wrote: I'm not going to try and pull a Bill Clinton with it depends what the definition of is is but I'd answer that I believe the Jini Community views the project as *the* Jini implementation. But *the* as in: the main, the original, the most prominent, (what will be) the Community's implementation, and the one you'd recommend a developer go grab to get going with Jini. But not *the* as in the only. If the resulting code is in org.jini.* then I have no problem with this. However, the current structure appears to be org.jini.* for APIs and com.sun.something.* for implementation. Clearly that structure says there can be multiple implementations - and in that case I'm against putting the two parts together. doesn't make sense, let me give you two examples, the latter being extremely obvious 1. in Tomcat we have javax.servlet.*, org.apache.catalina.*, org.apache.coyote.*, org.apache.jasper.*, javax.mail.*, javax.annotation.* 2. Harmony, are we saying that harmony couldn't implement java.lang.String and org.apache.harmony.strings.StringImpl? Clearly harmony is a project for both spec and implementation, and yes, there are more than one implementation available, but that doesn't mean harmony doesn't create their own java.* library. Filip - 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: IRC Channel?
Geir Magnusson Jr wrote: Eelco Hillenius wrote: The community learns about each other in a shared, non-exclusionary method. Private Email/IM/IRC does NOT foster that. Public IRC, free for anyone to join, at a channel that is 'officially' published/ promoted however, does. No it doesn't.It's exclusionary in that email allows timezone independent participation, and IMO, reading an IRC chat after the fact is far different than being there. It's like reading a musical score - far different than being there. Let's not forget the fact that many users are behind a firewall. This also prevents the use of IRC. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 16 Aug 06, at 2:24 AM 16 Aug 06, Roy T. Fielding wrote: agreed... without experimentation we won't know if IRC or VOIP is better, and produces a better quality/amount. Hmm, IIRC, we already experimented on that issue and discovered the result. I think it was before your time, but APR was mostly designed on IRC and various in-person meetings. I only have one thing to say about that: http://www.utahphillips.org/stuff/mooseturdpie.mp3 What were the problems you encountered? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Jason, Here's the text version: http://www.awpi.com/Combs/Shaggy/A795.html I had to look up the word turd :) http://www.answers.com/turdr=67 -- dims On 8/16/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 16 Aug 06, at 2:24 AM 16 Aug 06, Roy T. Fielding wrote: agreed... without experimentation we won't know if IRC or VOIP is better, and produces a better quality/amount. Hmm, IIRC, we already experimented on that issue and discovered the result. I think it was before your time, but APR was mostly designed on IRC and various in-person meetings. I only have one thing to say about that: http://www.utahphillips.org/stuff/mooseturdpie.mp3 What were the problems you encountered? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jini : Separate Governance and Implementation Projects
Craig L Russell wrote: But I'd suggest that the com.sun.jini package should change to org.apache.newNameForJiniImplementation when it comes over. I can certainly understand the desire from ASF's perspective for this to occur. Such a renaming will have an impact on pretty much all of our existing users, though, so we're going to raise this over on the broader Jini community mailing lists to see what the general reaction to it is. - Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 16 Aug 06, at 9:40 AM 16 Aug 06, Dion Gillard wrote: You mean like this: http://docs.codehaus.org/display/MAVEN/IRC+Log+Design+Discussion+26 +May+2005 That particular discussion had everyone who even vaguely knew what the issue at hand was, even so you only know we talked about it because we logged it. Also, the use of our IRC has evolved over time just as people evolve their communication strategies. Geir's example below is exactly what he and I used to do *all* the time except we never posted anything to the mailing lists. We designed pretty much every last detail of Velocity over IRC and usually it was a private IRC conversation. So everyone changes to adjust to what best suits the situation. If you look at the Maven lists and how often we post topics for development discussion you'll often find no one outside the core set of committers answers any of them. Often times not even the core committers answer. Then it fades away and folks generally don't go hunting down the topic in the archives, except for the very few that have a mail flagging technique. But anyone interested in knowing what we're doing is here: http://docs.codehaus.org/display/MAVEN/Maven+2.1+Design+Documents Regardless of whatever else we do those are the items of discussion and nothing leaves the queue until it is resolved and we don't tackle any other new issues until a place in the queue frees sometimes pass in and out of the mailing list and sometimes devs/users leave comments in the wiki. We then vote on the mailing list, although I think a little voting app like we use for elections would be better for record keeping, or a little webapp. So what's makes it easier for a new person entering the community to get involved? Sifting through archives or looking at that one page. The one page I would think. If that page points at email threads (which we're working on), IRC logs or the Wiki then who cares what the medium is provided it's available to everyone. If people want to get involved they generally ask and that's about all they need to be involved. Bottom line is if you don't include other people then they aren't going stay around to help and the project will go to pot. Telling people they can't use IRC for discussions or even making decisions isn't going to prevent a project from spiraling downward. It's the attitude of the people involved that will keep a project afloat. I've adjusted from doing a lot of things myself like writing Velocity or large chunks of Turbine, the first incarnation of maven, the second incarnation of maven but it's not IRC discussions that kept others from being involved or feeling included it was my attitude. My attitude changed and my general mode of communication changed and that included how I used IRC. I think it's pointless to hammer on a point that some technology is going to make or break a project, or even help or aid a project to be more one way or the other. If the project is going to be a long term survivor the people involved in the project will figure it out. On 8/16/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. geir Regards Jan Blok Jim Jagielski wrote: I think one way of looking at this is simply remembering that the ASF values community over code. Yes, IRC and other real-time communication methods means quicker code development, etc, but it places, IMO, an undue barrier to the development of the community. - 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] -- http://www.multitask.com.au/people/dion/ If you even dream of beating me you'd better wake up and apologize - Muhammad
Re: Jini : Separate Governance and Implementation Projects
On Aug 15, 2006, at 12:50 AM, Noel J. Bergman wrote: : For example, what if we created [EMAIL PROTECTED] and jinn- [EMAIL PROTECTED] Forget the question of how many podlings --- I am simply talking about a list related to specification work, and a list related to implementation. Is that a starter? And if we have them both under a single podling to start, and we see how it goes, does that work for you? Separate mailing lists for source code development and API/spec discussions seems reasonable. Some developers in the Community might be interested in the details on how the impl work is going, and others might be only interested in API -related proposed changes. I think that would work fine for us. thanks -Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On 15 Aug 06, at 12:27 PM 15 Aug 06, Geir Magnusson Jr wrote: Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. That's a sweeping generalization which in many cases is not true. Email can be just as unclear and people going Sorry, I don't understand what you just said happens often. In IRC where you can iterate to the point of understanding and pastebin examples to get your point across works very well. I don't think the argument can be made that one form of communication has a better rate of conveyance. I would say IRC does, you would say email does. I think the argument here is one of persons/groups being excluded or not which is matter of project members' attitudes about inclusion. Jason. geir Regards Jan Blok Jim Jagielski wrote: I think one way of looking at this is simply remembering that the ASF values community over code. Yes, IRC and other real-time communication methods means quicker code development, etc, but it places, IMO, an undue barrier to the development of the community. - 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] Jason van Zyl [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Glasglow to Qpid
I have completed the rename on the wiki from Blaze to Glasgow to Qpid. The updated page (only the name and ASF resources to be setup have changed). The new page can be found at: http://wiki.apache.org/incubator/QpidProposal Project setup can now be done with Qpid for the name and qpid lowercase to be used for the resources. Details are in the proposal. Carl. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?
Tis done (Thanks Joe). It's for Incubator releases and not for snapshots. It's not for 3rd party jars that the Incubator projects need (these should go in the snapshot repository). I'll update the very young repository faq to mention these two new repos: http://www.apache.org/dev/repository-faq.html Hen On 8/16/06, Jason van Zyl [EMAIL PROTECTED] wrote: +1 On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote: On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository Noel, shall I go ahead and create the above? They get my +1 from a repository@ point of view. Pinging on this to make sure the Incubator is happy with the idea before I set it up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [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]
Re: Setting up a Maven 2 repo Was: Maven 2 repo for incubating project releases?
What is the real purpose of such a repository if it is not synced to ibiblio ? What if a user of an incubating project create an upload request ? There's no reason why Apache internal policies would affect such a request. AFAIK, Ibiblio repository is not owned by the ASF ... Jason van Zyl wrote: +1 On 14 Aug 06, at 5:03 PM 14 Aug 06, Henri Yandell wrote: On 8/7/06, Henri Yandell [EMAIL PROTECTED] wrote: people.apache.org/repo/m1-incubating-repository people.apache.org/repo/m2-incubating-repository Noel, shall I go ahead and create the above? They get my +1 from a repository@ point of view. Pinging on this to make sure the Incubator is happy with the idea before I set it up. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Jason van Zyl [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]
Re: Automating Report Reminders (and the Project Index)
Noel J. Bergman wrote: david reid wrote: Where is the information you maintain presently? The site is built from https://svn.apache.org/repos/asf/incubator/public/trunk/, and the specific stuff that you'd be looking for is in multiple locations: Projects (one file per): https://svn.apache.org/repos/asf/incubator/public/trunk/site-author/proj ects/ Had a quick look on the way here (Atlanta) and one immeadiate question springs forth... Is there any good reason why this is one huge file? It seems to make far more sense as smaller files which then are linked to get to the behemoth that exists today. david - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IRC Channel?
Gwyn Evans wrote: Henning Schmiedehausen wrote: IRC BTW is very flaky if you don't have good connection (as most people at AC currently experience). Mail is much better for that because it is not as volatile as IRC. Hmm, that's not universally true though - Over the last year or so, SF mailing lists have have various /prolonged/ outages whereas Freenode IRC has not (as far as I know). We don't use SF infrastructure. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Jason van Zyl wrote: On 15 Aug 06, at 12:27 PM 15 Aug 06, Geir Magnusson Jr wrote: Jan Blok wrote: Hi, What could be the problem of any real-time communication medium usage between some community members as long as every one agrees code and design decisions are made on the mailing list? Because the reality is that decisions are made on IRC, implicitly. It's hard to engage in an argument that already happened, especially when the discussion was very conversational rather than formal : A: what do you think? B: Well, like you said before... A : about the contstructor B : no, the other thing A : related to using =? B : right that it.. it would be better if that was done as Jim suggested versus the more formal statements people make in email I'm beginning to agree that ensuring that re-serializing the Properties preserves the original delimiter (= in Jim's example) that was used in the original file. That's a sweeping generalization which in many cases is not true. Of course - it was clearly contrived. And most people don't make single coherent statements in email as well. But I find it far easier to track a thread in email. Email can be just as unclear and people going Sorry, I don't understand what you just said happens often. In IRC where you can iterate to the point of understanding and pastebin examples to get your point across works very well. I don't think the argument can be made that one form of communication has a better rate of conveyance. I would say IRC does, you would say email does. I think the argument here is one of persons/groups being excluded or not which is matter of project members' attitudes about inclusion. It would be interesting to see if such things could be measured with language analysis, to find density or continuity of content. I know that I personally have a rough time reading IRC logs, even just backscrolling though what my client captures is always far different than being there in real time. My biggest problem with IRC is that fact that not everyone can be there. I understand how people find it more efficient - I actually prefer face to face or phone... :) geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
Jason van Zyl wrote: On 16 Aug 06, at 9:40 AM 16 Aug 06, Dion Gillard wrote: You mean like this: http://docs.codehaus.org/display/MAVEN/IRC+Log+Design+Discussion+26+May+2005 That particular discussion had everyone who even vaguely knew what the issue at hand was, even so you only know we talked about it because we logged it. Also, the use of our IRC has evolved over time just as people evolve their communication strategies. Geir's example below is exactly what he and I used to do *all* the time except we never posted anything to the mailing lists. We designed pretty much every last detail of Velocity over IRC and usually it was a private IRC conversation. So everyone changes to adjust to what best suits the situation. It would be interesting to go look back at the vel dev list and test that assertion. I remember a lot of private chatting throughout the day, but as that was 6 years ago, I don't remember much. I have trouble remembering last week sometimes... gier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Forming an ActiveMQ PPMC
James Strachan wrote: Brian McCallister wrote: The ActiveMQ committers have decided to aim for TLP status (1) OK we need to get a PPMC in place. Thus far we have been working under a committer votes all count style FWIW we've had a PPMC in place for some time ;) As James notes, you've already had a PPMC. And, the only votes that ever count are those from PMC members, in this case Incubator PMC members. So those would be you, Jason, James, etc. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[STATUS] (incubator) Wed Aug 16 23:53:33 2006
APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2006-02-05 04:40:19 -0500 (Sun, 05 Feb 2006) $] Web site: http://Incubator.Apache.Org/ Wiki page: http://wiki.apache.org/incubator/ [note: the Web site is the 'official' documentation; the wiki pages are for collaborative development, including stuff destined for the Web site.] Pending Issues == o We need to be very very clear about what it takes to be accepted into the incubator. It should be a very low bar to leap, possibly not much more than 'no problematic code' and the existence of a healthy community (we don't want to become a dumping ground). o We need to be very very clear about what it takes for a podling to graduate from the incubator. The basic requirements obviously include: has a home, either as part of another ASF project or as a new top-level project of its own; needs to be a credit to the ASF and function well in the ASF framework; ... See also: https://issues.apache.org/jira/browse/INCUBATOR Resolved Issues === o The policy documentation does not need ratification of changes if there seems consensus. Accordingly, the draft status of these documents can be removed and we will use the lazy commit first, discuss later mode common across the ASF for documentation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190) o Coming up with a set of bylaws for the project (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=517190) o All projects under incubation must maintain a status Web page that contains information the PMC needs about the project. (http://incubator.apache.org/guides/website.html) o Projects under incubation should display appropriate disclaimers so that it is clear that they are, indeed, under incubation (http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=504543) o Clearly and authoritatively document how to edit, generate, and update the Web site (three separate functions) (http://incubator.apache.org/guides/website.html). The Incubation Process == TODO: this does not belong in the STATUS file and probably was integrated into other documentation a while ago. That should be double-checked and then this section should be removed. This tries to list all the actions items that must be complete for a project before it can graduate from the incubator. It is probably incomplete. Identify the project to be incubated: -- Make sure that the requested project name does not already exist and check www.nameprotect.com to be sure that the name is not already trademarked for an existing software product. -- If request from an existing Apache project to adopt an external package, then ask the Apache project for the cvs module and mail address names. -- If request from outside Apache to enter an existing Apache project, then post a message to that project for them to decide on acceptance. -- If request from anywhere to become a stand-alone PMC, then assess the fit with the ASF, and create the lists and modules under the incubator address/module names if accepted. Interim responsibility: -- Who has been identified as the mentor for the incubation? -- Are they tracking progress on the project status Web page? Copyright: -- Have the papers that transfer rights to the ASF been received? It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. -- Have the files been updated to reflect the new ASF copyright? Verify distribution rights: -- For all code included with the distribution that is not under the Apache license, do we have the right to combine with Apache-licensed code and redistribute? -- Is all source code distributed by the project covered by one or more of the following approved licenses: Apache, BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with essentially the same terms? Establish a list of active committers: -- Are all active committers listed in the project status file? -- Do they have accounts on cvs.apache.org? -- Have they submitted a contributors agreement? Infrastructure: -- CVS modules created and committers added to avail file? -- Mailing lists set up and archived? -- Problem tracking system (Bugzilla)? -- Has the project migrated to our infrastructure? Collaborative Development: -- Have all of the active long-term volunteers been identified and acknowledged as committers on the project? -- Are there three or more independent committers? [The legal definition of independent is long and boring, but basically it means that there is no binding relationship between the individuals, such as a
Re: [doc] first call for review for http://incubator.apache.org/guides/participation.html
Hi David, Upayavira, Thanks, I figured it out from the instructions on the site. After I updated the site it successfully rsync'd to the live site. And now you can see it too. Thanks, Craig On Aug 16, 2006, at 6:17 PM, David Crossley wrote: Upayavira wrote: Craig L Russell wrote: Ok, I took the plunge and built the site. I checked in the updated participation.html page. Then, IIUC, you ssh to people.apache.org, cd to /www/incubator.apache.org/wherever/you/need/to/be, and do an svn up It may then take a few hours to rsync over to the live server. Upayavira, who could be wrong, though. Correct. First part is explained at: http://incubator.apache.org/guides/website.html For the rsync, etc. see the link at the bottom to: http://www.apache.org/dev/project-site.html -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
