Re: Collecting Proposed changes
Davanum Srinivas wrote: Brett, Let's take Tuscany, If the WS PMC had voted on the proposal before it hit [EMAIL PROTECTED], it would have probably passed the pmc VOTE. No - if the WS PMC was actually sponsoring it, it wouldn't need a PMC vote. and incubator would have had to accept it as-is. however fortunately, the proposal was sent directly to [EMAIL PROTECTED] and Roy (and others) had quite a few problems with it which got fixed. So it was a good decision in hind sight that the people who proposed tuscany went to [EMAIL PROTECTED] first. Because it wasn't a WS-sponsored project. I still don't think it needs to be WS sponsored :) geir thanks, dims On 1/2/06, Brett Porter [EMAIL PROTECTED] wrote: Some thoughts: # [ ] - Any proposal should hit [EMAIL PROTECTED] first, No PR before that. # [ ] - Any PR should be vetted by PRC, No Excuses. Agree, for the Apache side of things. I'm not sure we can stop companies doing what they are going to do, but we can certainly say that that they shouldn't be doing so and list the reasons why (because it mighr not be accepted, might have a different name, etc). Also, please define PR. Recent examples seem to think that an individual member of the proposal's personal blog is PR, which I'm not sure I agree with. # [ ] - A sponsoring PMC should hold their VOTE to sponsor a proposal or IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED] Seems back to front to me. How can you propose anything to the incubator that you haven't decided you want to do? - Brett On 1/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, Please review the items here: http://wiki.apache.org/incubator/ProposedChanges Please feel free to add/modify/delete or start a new thread here on any issue that you care about. Let's give it a week and then ask the incubator PMC to VOTE on items on that page. thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - 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: Collecting Proposed changes
How does a PMC agree to sponsor a thing w/o a VOTE? secondly, the guys who wrote the proposal asked me to check with WS PMC. why would i do that otherwise? -- dims On 1/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Brett, Let's take Tuscany, If the WS PMC had voted on the proposal before it hit [EMAIL PROTECTED], it would have probably passed the pmc VOTE. No - if the WS PMC was actually sponsoring it, it wouldn't need a PMC vote. and incubator would have had to accept it as-is. however fortunately, the proposal was sent directly to [EMAIL PROTECTED] and Roy (and others) had quite a few problems with it which got fixed. So it was a good decision in hind sight that the people who proposed tuscany went to [EMAIL PROTECTED] first. Because it wasn't a WS-sponsored project. I still don't think it needs to be WS sponsored :) geir thanks, dims On 1/2/06, Brett Porter [EMAIL PROTECTED] wrote: Some thoughts: # [ ] - Any proposal should hit [EMAIL PROTECTED] first, No PR before that. # [ ] - Any PR should be vetted by PRC, No Excuses. Agree, for the Apache side of things. I'm not sure we can stop companies doing what they are going to do, but we can certainly say that that they shouldn't be doing so and list the reasons why (because it mighr not be accepted, might have a different name, etc). Also, please define PR. Recent examples seem to think that an individual member of the proposal's personal blog is PR, which I'm not sure I agree with. # [ ] - A sponsoring PMC should hold their VOTE to sponsor a proposal or IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED] Seems back to front to me. How can you propose anything to the incubator that you haven't decided you want to do? - Brett On 1/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, Please review the items here: http://wiki.apache.org/incubator/ProposedChanges Please feel free to add/modify/delete or start a new thread here on any issue that you care about. Let's give it a week and then ask the incubator PMC to VOTE on items on that page. thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] bring in full code history on incubated project?
Geir Magnusson Jr. wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I don't see how the incubator can hold a single position on this one. There are good reasons both for and against, depending on your project. Rather than making a decision which is bound to fly in the face of some potential incubatees, why can it not simply be left to individual projects to decide for themselves? My understanding of the incubator's role, was that issues like this did not have to be resolved until a project sought promotion up out of the incubator. At this point, I might reasonably expect to have to shed a project history - if its acceptance into a first-level ASF repo caused problems - and live with a history divided between two repos. Why, though, a passage to this point, via the incubator, should further fragment a project, and leave me with my history in three places, I do not understand. Isn't the incubator meant to lower the bar for projects wishing to migrate into ASF ? Jules (WADI) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Solr
Hello Incubator PMC folks, I would like to propose a new Apache project named Solr. http://wiki.apache.org/incubator/SolrProposal The project is being proposed as a sub-project of Lucene, and the Lucene PMC has agreed to be the sponsor. -Yonik '''Proposal for new project Solr ''' Yonik Seeley -- yonik at apache dot org '''(0) rationale''' Solr is a search server based on Apache Lucene and focused on full-text search, relevancy, and performance. Some of the server features include: * Query and update interfaces over HTTP and XML. * Replication based on index snapshots and rsync. * A schema allowing declarative specification of fields and their types, including specification of text analysis filter chains. * External configuration for Lucene parameters, stopword lists, and synonym lists. * A web based admin interface with statistics and debugging. * An extensive caching framework for filters, queries, documents, and user caches. * Plugins for customizing query handling, caching and many other server aspects. Solr is currently an internal CNET project, and is used to power search and faceted browsing in a number of CNET sites. '''(0.1) criteria''' ''Meritocracy: '' Solr's developers are comfortable operating as a meritocracy. ''Community: '' Establishing an active open source community will be the top priority. ''Core Developers:'' Solr starts with three committers. ''Alignment:'' Solr currently uses the following Apache projects: Ant, Lucene. '''(0.2) warning signs''' ''Orphaned products: '' Solr is not an orphan, use within CNET is growing rapidly. ''Inexperience with open source:'' Solr's committers are experienced with open source and have made contributions to other open source projects. ''Homogenous developers:'' Solr's initial committers are all CNET employees since it's currently an internal project. ''Reliance on salaried developers:'' Some committers are currently paid to make contributions to Solr. ''No ties to other Apache products:'' Solr has strong ties to Lucene. ''A fascination with the Apache brand:'' The committers respect the Apache brand and feel that Apache is the right place to generate a strong open source community. '''(1) scope of the subprojects''' The scope of the project is to provide a stand-alone full-text search server. The proposal is that this project become a sub-project of Apache Lucene. '''(2) identify the initial source from which the subproject is to be populated''' CNET will donate the initial source code for this project. '''(3) identify the ASF resources to be created ''' '''(3.1) mailing list(s) ''' * solr-dev * solr-user '''(3.2) Subversion or CVS repositories''' * https://svn.apache.org/repos/asf/incubator/solr '''(3.3) Jira ''' * Solr (SOLR) '''(4) identify the initial set of committers ''' * Yonik Seeley, CNET (Lucene committer) * Bill Au, CNET * Chris Hostetter, CNET '''(5) identify apache sponsoring individual ''' * Doug Cutting, Champion * Lucene PMC, Sponsor (as defined in http://incubator.apache.org/incubation/Roles_and_Responsibilities.html) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Collecting Proposed changes
Davanum Srinivas wrote: How does a PMC agree to sponsor a thing w/o a VOTE? It wouldn't need an *Incuabtor PMC* vote. secondly, the guys who wrote the proposal asked me to check with WS PMC. why would i do that otherwise? I understand. I still don't think it needs WS sponsorship :) geir -- dims On 1/3/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: Brett, Let's take Tuscany, If the WS PMC had voted on the proposal before it hit [EMAIL PROTECTED], it would have probably passed the pmc VOTE. No - if the WS PMC was actually sponsoring it, it wouldn't need a PMC vote. and incubator would have had to accept it as-is. however fortunately, the proposal was sent directly to [EMAIL PROTECTED] and Roy (and others) had quite a few problems with it which got fixed. So it was a good decision in hind sight that the people who proposed tuscany went to [EMAIL PROTECTED] first. Because it wasn't a WS-sponsored project. I still don't think it needs to be WS sponsored :) geir thanks, dims On 1/2/06, Brett Porter [EMAIL PROTECTED] wrote: Some thoughts: # [ ] - Any proposal should hit [EMAIL PROTECTED] first, No PR before that. # [ ] - Any PR should be vetted by PRC, No Excuses. Agree, for the Apache side of things. I'm not sure we can stop companies doing what they are going to do, but we can certainly say that that they shouldn't be doing so and list the reasons why (because it mighr not be accepted, might have a different name, etc). Also, please define PR. Recent examples seem to think that an individual member of the proposal's personal blog is PR, which I'm not sure I agree with. # [ ] - A sponsoring PMC should hold their VOTE to sponsor a proposal or IP Clearance 72 hours *AFTER* it is posted on [EMAIL PROTECTED] Seems back to front to me. How can you propose anything to the incubator that you haven't decided you want to do? - Brett On 1/1/06, Davanum Srinivas [EMAIL PROTECTED] wrote: Folks, Please review the items here: http://wiki.apache.org/incubator/ProposedChanges Please feel free to add/modify/delete or start a new thread here on any issue that you care about. Let's give it a week and then ask the incubator PMC to VOTE on items on that page. thanks, dims -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - 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] -- Davanum Srinivas : http://wso2.com/blogs/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [policy] bring in full code history on incubated project?
Jules Gosnell wrote: Geir Magnusson Jr. wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I don't see how the incubator can hold a single position on this one. There are good reasons both for and against, depending on your project. We certainly can have a position, and then deal with exceptions. Rather than making a decision which is bound to fly in the face of some potential incubatees, why can it not simply be left to individual projects to decide for themselves? Because IMO the primary purpose of the incubator is to protect and promote the ASFs interests, not of the candidate individual projects. That's SourceForge. My understanding of the incubator's role, was that issues like this did not have to be resolved until a project sought promotion up out of the incubator. Well, things have to be complete by then, but this is a case of where if you don't do it from the beginning, you can't fix it later, unless you've made no changes to the code. At this point, I might reasonably expect to have to shed a project history - if its acceptance into a first-level ASF repo caused problems - and live with a history divided between two repos. Why, though, a passage to this point, via the incubator, should further fragment a project, and leave me with my history in three places, I do not understand. Isn't the incubator meant to lower the bar for projects wishing to migrate into ASF ? Where would the three places be? I can see two if we don't take history and only one if we do - here, at the ASF. geir Jules (WADI) - 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: [policy] bring in full code history on incubated project?
Geir Magnusson Jr wrote: Jules Gosnell wrote: Geir Magnusson Jr. wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I don't see how the incubator can hold a single position on this one. There are good reasons both for and against, depending on your project. We certainly can have a position, and then deal with exceptions. Rather than making a decision which is bound to fly in the face of some potential incubatees, why can it not simply be left to individual projects to decide for themselves? Because IMO the primary purpose of the incubator is to protect and promote the ASFs interests, not of the candidate individual projects. That's SourceForge. My understanding of the incubator's role, was that issues like this did not have to be resolved until a project sought promotion up out of the incubator. Well, things have to be complete by then, but this is a case of where if you don't do it from the beginning, you can't fix it later, unless you've made no changes to the code. if you didn't bring your history to the incubator, then you obviously didn't intend to bring it to ASF - case closed. if you did, then you are saying that you want at least one less fragmentation of your project's history, but this does not stop you from leaving your history behind when you are promoted from the incubator if this is requirement. At this point, I might reasonably expect to have to shed a project history - if its acceptance into a first-level ASF repo caused problems - and live with a history divided between two repos. Why, though, a passage to this point, via the incubator, should further fragment a project, and leave me with my history in three places, I do not understand. Isn't the incubator meant to lower the bar for projects wishing to migrate into ASF ? Where would the three places be? I can see two if we don't take history and only one if we do - here, at the ASF. 1. codehaus (history before move to incubator) 2. incubator (history after move and before promotion - many changes will occur to the project which it is in the incubator) 3. geronimo (history after promotion). History is an integral part of any project, an important technical reference, a record of contributions made to the project and much more. I don't understand why any constraints (legal, resource-based etc...) should be applied to a project on entry into the incubator, although I would expect them to be applied strenuously before any promotion could occur. respectfully, Jules geir Jules (WADI) - 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: [policy] bring in full code history on incubated project?
Jules Gosnell wrote: Geir Magnusson Jr wrote: Jules Gosnell wrote: Geir Magnusson Jr. wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I don't see how the incubator can hold a single position on this one. There are good reasons both for and against, depending on your project. We certainly can have a position, and then deal with exceptions. Rather than making a decision which is bound to fly in the face of some potential incubatees, why can it not simply be left to individual projects to decide for themselves? Because IMO the primary purpose of the incubator is to protect and promote the ASFs interests, not of the candidate individual projects. That's SourceForge. My understanding of the incubator's role, was that issues like this did not have to be resolved until a project sought promotion up out of the incubator. Well, things have to be complete by then, but this is a case of where if you don't do it from the beginning, you can't fix it later, unless you've made no changes to the code. if you didn't bring your history to the incubator, then you obviously didn't intend to bring it to ASF - case closed. That's true. I would assume that an OSS project moving here would indeed want to keep it though if you did, then you are saying that you want at least one less fragmentation of your project's history, but this does not stop you from leaving your history behind when you are promoted from the incubator. I can't imagine why you'd want to do that. At this point, I might reasonably expect to have to shed a project history - if its acceptance into a first-level ASF repo caused problems - and live with a history divided between two repos. Why, though, a passage to this point, via the incubator, should further fragment a project, and leave me with my history in three places, I do not understand. Isn't the incubator meant to lower the bar for projects wishing to migrate into ASF ? Where would the three places be? I can see two if we don't take history and only one if we do - here, at the ASF. 1. codehaus (history before move to incubator) 2. incubator (history after move and before promotion - many changes will occur to the project which it is in the incubator) 3. geronimo (history after promotion). History is an integral part of any project, an important technical reference, a record of contributions made to the project and much more. Right - so why would you want to abandon the history when going to Geronimo? I can see it happening going from codehaus to incubator if you chose to do that (although I wouldn't), but we should be able to keep it when going to G, right? The incubator is a grey area between outside and inside ASF. No - it's inside the ASF. I don't understand why any constraints (legal, resource-based etc...) should be applied to a project on entry into the incubator, although I would expect them to be applied strenuously before any promotion could occur. Because the incubator is a project of the ASF, and therefore responsible for what happens here. It's not a no-man's land. geir respectfully, Jules geir Jules (WADI) - 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]
Re: [policy] bring in full code history on incubated project?
We should take history! A snapshot does not solve any legal or social issues. Obscuring history does not change history and if code is a derivative of LGPL, then not having the history does not change that fact. If there is something in the real history, then it is best to have that explicit in the svn history. regards Justin Erenkrantz wrote: --On December 23, 2005 1:15:44 PM -0500 Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Sorry to change the subject... Can someone make a definitive statement on whether or not code history is brought into our repo from elsewhere when a podling brings code over? I say no. We should only take in a snapshot. If people want to see the history that was done elsewhere, they are free to maintain the old history outside. What happened before the ASF was involved is something we have no knowledge of and can't speak to. We can't be responsible for what happened before we were involved. By only taking in a snapshot, we create a clean break from a social and legal standpoint. All work from that point is done under our oversight mechanisms. We can operate in good faith that the snapshot we receive is in decent legal shape as we usually have a software grant for the bulk of that work. However, taking in complete source history that we have no knowledge of the oversight mechanisms that were in place is a bad thing in my opinion. There is a lesser point that taking in the author information from a separate project is awkward. This presents conflicts with our user account information and muddy things up if we ever have to do an audit. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experiment : Incubator site done in xdocs...
What is happening now? There was a flurry of +1 from PMC members. What is the next step in moving to Anakia? -David Geir Magnusson Jr wrote: I realize that many might have checked-out of this thread about 200 messages ago... if there's any interest or comment... (Note, this is just an experiment) Original Message Subject: Re: [RT] Super Simple Site Generation Tool Date: Sun, 01 Jan 2006 03:39:35 -0500 From: Geir Magnusson Jr [EMAIL PROTECTED] Reply-To: general@incubator.apache.org, [EMAIL PROTECTED] To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] Roy T. Fielding wrote: [SNIP] I don't see any point in having this conversation every year. Whoever is willing to fix the content on incubator, please feel free to remove the entire site (except the project status files) and start over with whatever tool you deem suitable. I have four other sites to work on that have higher priority, so chances are good that I won't be deleting the incubator site any time soon. Out of some sense of insomnia-driven inquisitiveness, I converted a good bit of the site to xdoc/Anakia. It took about 2.5 hours or so. http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site/ It's not done. I have to convert all the project stuff - I didn't have the internal fortitude and wherewithal to face cwiki - and there's a few other odds and ends. It became clear that we need to rework some of the content. If you want to see it : http://people.apache.org/~geirm/incubator/ Happy New Year geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Experiment : Incubator site done in xdocs...
Geir's experiment was incomplete and he reported difficulty with some docs. Perhaps the following will help, or perhaps you already have a better solution. There is a way to use Forrest itself to produce xml output ... 0) Assuming that forrest is installed as per: http://incubator.apache.org/guides/website.html 1) Temporarily add the xml-link. This will cause forrest to also generate an xml version of each page. edit site-author/skinconf.xml at line 46 - disable-xml-linktrue/disable-xml-link + disable-xml-linkfalse/disable-xml-link I gather that when Stefano built the orginal DTDs for Forrest that he might have started from the Anakia xml format. Anyway, whatever, the formats are close. 2) Clean up the output xml * Remove the document type declaration. It seems that Anakia xdocs don't have one. * Transform some elements: document/header = document/properties link = a 3) Copy all of the *.xml documents from site-publish/**.xml to incubator/site/xdocs/test2 In my experiment, i copied some test documents to infrastructure/site/ i.e. the www.a.o/dev/ etc. which also uses Anakia. They are processed reasonably well there. Geir's stylesheet seems to have different handling of section/title elements. 4) Run anakia. cd incubator/site; ant 5) Fix the links. This workaround is just saving the internal Forrest format to disk, so links that use Forrest's linking system are broken. 6) Fix some other issues. In my experiment, the site-author/projects/index.html table is transformed well, but not with Geir's stylesheet (perhaps same issue as above). I also tested some status reports, some transform okay but some do not, perhaps there are problems with some of the source html. It is interesting to note that Nicola Ken long ago moved the Incubator site to use html as the source format instead of the orginal xml - presumably people had problems editing xml. That has made it harder to convert the site back to xml again. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
