Re: [VOTE] Graduation resolution for ManifoldCF
+1 Jukka Zitting 1.5.2012 14.18 "Karl Wright" kirjoitti: > > Thanks, Jukka, I'd be honored to take on the role of VP in a > ManifoldCF top-level project. > > Incorporating Jukka's invaluable advice, I've updated the proposed > resolution, and am opening a vote on it. Please vote +1 if you agree > that this is the resolution that should be presented, in total, > including myself in the role of Vice President, or -1 if you see > changes you would like to make (or if you'd like to nominate someone > else and hold a formal vote on the VP role). > > == >WHEREAS, the Board of Directors deems it to be in the best interests >of the Foundation and consistent with the Foundation's purpose to >establish a Project Management Committee charged with the creation and >maintenance of open-source software for transferring content between >repositories or search indexes, for distribution at no charge to the public; > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee >(PMC), to be known as the "Apache ManifoldCF Project", be and hereby is >established pursuant to Bylaws of the Foundation; and be it further > >RESOLVED, that the Apache ManifoldCF Project be and hereby is >responsible for the creation and maintenance of open-source software for >transferring content between repositories or search indexes, for distribution >at no charge to the public. > >RESOLVED, that the office of "Vice President, ManifoldCF" be and hereby >is created, the person holding such office to serve at the direction >of the Board of Directors as the chair of the Apache ManifoldCF >Project, and to have primary responsibility for management of the >projects within the scope of responsibility of the Apache ManifoldCF >Project; and be it further > >RESOLVED, that the persons listed immediately below be and hereby are >appointed to serve as the initial members of the Apache ManifoldCF >Project: > >* Shinichiro Abe (shinich...@apache.org) >* Erlend Garåsen(rid...@apache.org) >* Piergiorgio Lucidi (piergior...@apache.org) >* Hitoshi Ozawa (hoz...@apache.org) >* Tommaso Teofili (tomm...@apache.org) >* Simon Willnauer(sim...@apache.org) >* Karl Wright (kwri...@apache.org) >* Jukka Zitting (ju...@apache.org) > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Karl Wright be >appointed to the office of Vice President, ManifoldCF, to serve in >accordance with and subject to the direction of the Board of Directors >and the Bylaws of the Foundation until death, resignation, retirement, >removal or disqualification, or until a successor is appointed; and be >it further > >RESOLVED, that the initial Apache ManifoldCF Project be and hereby is >tasked with the creation of a set of bylaws intended to encourage open >development and increased participation in the ManifoldCF Project; and >be it further > >RESOLVED, that the initial Apache ManifoldCF Project be and hereby is >tasked with the migration and rationalization of the Apache Incubator >ManifoldCF podling; and be it further > >RESOLVED, that all responsibility pertaining to the Apache Incubator >ManifoldCF podling encumbered upon the Apache Incubator PMC are >hereafter discharged. > == > > +1 from me. > > Thanks again for the vote of confidence! > Karl > > > On Tue, May 1, 2012 at 5:16 AM, Jukka Zitting wrote: > > Hi, > > > > On Mon, Apr 30, 2012 at 3:13 PM, Karl Wright wrote: > >> Looks like we missed a step; we need a graduation resolution for the > >> board to vote on. Here's my proposal, basically copied from Apache > >> Chemistry's, but I have a question. Since no distinction is made > >> between the PPMC members and committers in this resolution, and since > >> many of the original committers/IPMC members have become inactive, and > >> others have not yet been voted in as PPMC members, how should we deal > >> with that? > > > > * Overall the resolution looks good, though note my comment on the scope below. > > > > * As discussed before, I don't think making a distinction between > > committers and (P)PMC members is useful for us. IMO such a setup only > > makes sense for "umbrella" projects like the Incubator and Lucene > > before it split out most of its subprojec
Re: [DISCUSS] Graduation resolution for ManifoldCF
Hi, On Mon, Apr 30, 2012 at 3:13 PM, Karl Wright wrote: > Looks like we missed a step; we need a graduation resolution for the > board to vote on. Here's my proposal, basically copied from Apache > Chemistry's, but I have a question. Since no distinction is made > between the PPMC members and committers in this resolution, and since > many of the original committers/IPMC members have become inactive, and > others have not yet been voted in as PPMC members, how should we deal > with that? * Overall the resolution looks good, though note my comment on the scope below. * As discussed before, I don't think making a distinction between committers and (P)PMC members is useful for us. IMO such a setup only makes sense for "umbrella" projects like the Incubator and Lucene before it split out most of its subprojects. So my recommendation would be to make all (still active) committers also PMC members and stick with that policy going forward. * As for inactive people, you're already doing a good job asking them whether they still want to be involved. In case someone doesn't reply and hasn't shown up on the lists over the last year or so, it's fine to simply drop them from the resolution for lack of response. > Also, do we need to vote on who the vice president will > be? I believe we do... but maybe we can do this as part of the vote > on the resolution itself? You're already doing all the stuff a VP should be doing, and more, so I hereby nominate you to be the VP, Apache ManifoldCF. We can have a vote if other nominations are made, or consider you selected by lazy consensus otherwise. > WHEREAS, the Board of Directors deems it to be in the best interests > of the Foundation and consistent with the Foundation's purpose to > establish a Project Management Committee charged with the creation and > maintenance of open-source software providing a framework for > transferring > content from source content repositories to target repositories or > indexes, > including a security model permitting target repositories to enforce > source > repository security, for distribution at no charge to the public; This is a pretty lengthy scope definition. Can we simplify it a bit? For example something like: "... open-source software for transferring content between repositories or search indexes". The details of how this is achieved (framework, security model, etc.) are IMHO best left outside the scope to allow more freedom down the line for the project to evolve. > RESOLVED, that the Apache ManifoldCF Project be and hereby is > responsible for the creation and maintenance of software providing a > framework for transferring content from source content repositories to > target repositories or indexes, including a security model permitting > target > repositories to enforce source repository security, for distribution > at no charge to the public. This should also be updated as discussed above. PS. If you don't mind, I'd be happy to stay on board the new ManifoldCF PMC at least for some time to help out with the transition to TLP. BR, Jukka Zitting
Re: [VOTE] Propose graduation of ManifoldCF from the Incubator as a Top Level Project
Hi, On Tue, Apr 24, 2012 at 12:08 PM, Karl Wright wrote: > Please vote +1 if you think we should propose to the Incubator that we > graduate as a top level project at this time. +1 BR, Jukka Zitting
Re: Thoughts on graduation?
Hi, On Mon, Apr 23, 2012 at 2:05 PM, Tommaso Teofili wrote: > However I'm confident we can graduate soon. +1 I'm very happy with the way the community dealt with the recent release trouble. That, if anything, is a great indication of your readiness to graduate! BR, Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC6
Hi, On Mon, Apr 9, 2012 at 3:04 AM, Shinichiro Abe wrote: > You can download the release candidate from > http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC6/ > and there is also a tag in svn under > https://svn.apache.org/repos/asf/incubator/lcf/tags. +1 to release BR, Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Hi, On Mon, Apr 2, 2012 at 8:15 PM, Karl Wright wrote: > Possible solutions include: There's also the alternative that I brought up earlier: (5) Extract all dependencies from the existing pre-CONNECTORS-437 source tree to a separate -lib package like this: $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz $ find apache-manifoldcf-0.5-incubating -type f -name '*.jar' > lib.txt $ echo apache-manifoldcf-0.5-incubating/LICENSE.txt >> lib.txt $ echo apache-manifoldcf-0.5-incubating/NOTICE.txt >> lib.txt $ tar zcf apache-manifoldcf-0.5-incubating-lib.tar.gz -T lib.txt We can then publish that -lib package along with the official source release and include build instructions like the following: $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz $ tar zxf apache-manifoldcf-0.5-incubating-lib.tar.gz $ cd apache-manifoldcf-0.5-incubating $ ant build That gives us something that's immediately releasable even with the newly reinterpreted Apache rules. And it gives us more time and breathing room for following up on the various improvement ideas that in terms of simplifying the build and the way dependencies are handled would make sense even regardless of policy requirements. BR, Jukka Zitting
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC3
Hi, On Mon, Apr 2, 2012 at 2:31 PM, Karl Wright wrote: > The only other potential problem is that the > license/notice/dependencies files may not conform strictly to > incubator guidelines. Specifically, we are not including a different > set of files with a bin release vs. a source release, and also it was > unclear whether our format (which was once again based on Lucene/Solr) > is still acceptable or not. The thread in general@i.a.o provided some > examples, but it is not clear whether those were the ONLY acceptable > formats. I am hoping for Jukka and Tommaso's feedback here before we > present this artifact to the incubator. Ideally the licensing metadata (i.e. the LICENSE and NOTICE files) should only cover material contained in that specific package. See [1] for a related discussion from a few years ago. At least back then it seemed acceptable for a project to also only maintain a single set of license metadata that covers the contents of both source and binary distributions. AFAIUI that approach is in use by many Apache projects. About the RC more generally, I find the download-via-svn target a bit troublesome as it makes the release depend on content in svn. That essentially turns the svn server into a release distribution channel, which it definitely shouldn't be. I think it's fine to manage the set of binary dependencies (that aren't available in a stable third party location like Maven Central) in svn, but a release should not try to access them from there. Instead we should for example package them up in a separate -lib or -deps archive and make it available for download along with the source release through the standard Apache mirroring network. That archive should also come with appropriate licensing metadata that's currently lacking in bin-dist. [1] http://markmail.org/message/bttmkavpicxxg7gl BR, Jukka Zitting
Re: Heads up
Hi, On Fri, Mar 30, 2012 at 6:53 PM, Karl Wright wrote: > Is there any indication we cannot take a week or two to make the new > release process repeatable and automated? No problem with that. BR, Jukka Zitting
Re: Heads up
Hi, On Thu, Mar 29, 2012 at 2:28 PM, Karl Wright wrote: > FWIW, I'm working on CONNECTORS-437 in a branch. Given the extent of > the changes required, and the limits on my time, I'd expect this work > to require at least another week to reach a point of rough equivalency > to where we are now. If we want to push out the release now, the following steps should produce a close enough approximation of what people on general@ are asking for: $ tar zxf apache-manifoldcf-0.5-incubating-src.tar.gz $ find apache-manifoldcf-0.5-incubating -type f -name '*.jar' > lib.txt $ find apache-manifoldcf-0.5-incubating -type f \! -name '*.jar' > src.txt $ tar zcf apache-manifoldcf-0.5.1-incubating-lib.tar.gz -T lib.txt $ tar zcf apache-manifoldcf-0.5.1-incubating-src.tar.gz -T src.txt BR, Jukka Zitting
Re: Heads up
Hi, On Wed, Mar 28, 2012 at 2:37 PM, Karl Wright wrote: > Our build and release process was modeled, unfortunately, on other > Apache Java projects, and these too have come under fire from the > Board because the same practice has been followed, in some cases for > more than a decade. I'm not sure what ManifoldCF did to become the > focal point of this discussion, but there it is - and my personal > opinion is that there is no chance of us releasing 0.5 without making > significant changes. I'm very sorry about this situation. In the Incubator we've been hoping to avoid cases like this where someone on the IPMC comes up with a veto based on some new or previously unclear interpretation of Apache policies. Having such issues block releases that were previously considered OK is very unfortunate and I can only apologize for this situation. I'm hoping to drive the discussion on general@ to some reasonable consensus on what the actual problem is here and how affected projects should deal with it. Meanwhile, unless there's a rush to get the 0.5 release out, I wouldn't recommend taking too hasty actions in terms of CONNECTORS-437. BR, Jukka Zitting
Re: Proposed March incubator report
Hi, On Fri, Mar 2, 2012 at 3:19 PM, Karl Wright wrote: > Thanks for the advice; I've updated the ticket to include some useful > references. As for writing up clauses restricting use of IPA within > Apache, which is what you seem to have done for LEGAL-36, I'm not > clear exactly where that should live. Does that go into the project > license, or somewhere into the main Apache site? The guidance on specific licenses is recorded in [1]. If I understand the IPA license correctly (haven't reviewed it thoroughly yet), it seems like it could be covered in similarly as CC-SA [2], or perhaps even just as an extra entry in the Category B list [3]. [1] http://www.apache.org/legal/resolved.html [2] http://www.apache.org/legal/resolved.html#cc-sa [3] http://www.apache.org/legal/resolved.html#category-b BR, Jukka Zitting
Re: Proposed March incubator report
Hi, Looks good to me too! Signed off. On Thu, Feb 23, 2012 at 2:53 PM, Karl Wright wrote: > We have an outstanding request to Apache Legal to determine whether we > can distribute PDF files containing Japanese characters rendered with the IPA > family of fonts. It would be great to know the answer prior to the release of > ManifoldCF 0.5-incubating. A ticket is open (LEGAL-123) but no activity > has taken place on it. See LEGAL-36 [1] for an example of how you can drive the process of getting a license approved. In this case I'd recommend explaining how the IPA license fits the existing license guidelines [2] and refer to other sources like [3] and [4] where the license has already been reviewed. Since the license has a copyleft nature, it would be good to highlight that the fonts are clearly meant only to be used, not modified. For borderline cases like this, the legal team generally prefers to avoid making too broad statements about allowed use. So suggesting a narrow definition that only covers using such fonts in generated documentation is probably easiest to get approved. [1] https://issues.apache.org/jira/browse/LEGAL-36 [2] http://www.apache.org/legal/resolved.html#criteria [3] https://fedoraproject.org/wiki/Licensing/IPAFontLicense [4] http://lists.debian.org/debian-legal/2009/05/msg00075.html BR, Jukka Zitting
Re: Please welcome Hitoshi Ozawa to the ManifoldCF community!
Hi, On Tue, Feb 7, 2012 at 3:39 AM, Karl Wright wrote: > Hitoshi is now officially a ManifoldCF Committer. Congratulations, Hitoshi! Welcome to the team, Hitoshi! BR, Jukka Zitting
Re: Site publish mirroring question
Hi, On Fri, Feb 3, 2012 at 12:49 PM, Karl Wright wrote: > I'd love to do a generic ref of some kind but to do that I'd need > access to the Apache web server config. Would you know how this > works? Do I open an infra ticket or is there a way to do it without > any special karma? See http://www.apache.org/dev/project-site.html#configure BR, Jukka Zitting
Re: Site publish mirroring question
Hi, On Fri, Feb 3, 2012 at 12:36 PM, Karl Wright wrote: > I verified that the area under /www/incubator.apache.org/connectors > has just what it is supposed to have. The question is what to do > about the mirror(s)? Do we want to tie ourselves into knots and > publish stubs at all the old page URLs? Suggestions welcome... If I understand correctly, the publish process normally only updates new and modified files, not deleted ones, which is probably why the old content is still showing. A less frequent full sync should take care of that eventually. If it doesn't happen within a week or so, contacting infra@ to find out what's wrong is a good idea. That said, I think it would in any case be a good idea to place redirects (perhaps just a generic /* -> /en_US/* one) to avoid breaking any existing links out there. BR, Jukka Zitting
Re: Apache licensing restrictions for PDF distribution?
Hi, On Mon, Jan 30, 2012 at 12:20 PM, Karl Wright wrote: > The specific case would be the inclusion of user documentation, > specifically end-user-documentation.pdf, which is now being generated > in both English and Japanese. The PDFs formerly were generated using > whatever Forrest used as the default font, but now they will be using > the IPA family of fonts. A link to the IPA license can be found in > CONNECTORS-387. It is redistributable, and open-source, but you are > not allowed to make any changes to it, as I understand the license. Sounds similar to the specification and font information licenses I dealt with earlier. See [1] for the resulting policy. It's probably best to file a LEGAL issue [2] for this. Include a copy of the IPA license, a reference to CONNECTORS-387 and a suggestion to add the IPA fonts to the list in [1] of allowed materials. [1] http://www.apache.org/legal/resolved.html#no-modification [2] https://issues.apache.org/jira/browse/LEGAL BR, Jukka Zitting
Re: Apache licensing restrictions for PDF distribution?
Hi, On Mon, Jan 30, 2012 at 9:30 AM, Karl Wright wrote: > Apache has well-defined descriptions of what licenses open-sourced > software can have to be redistributed. But does anyone know whether > this applies to fonts that get embedded in a PDF when the PDF is > generated? As I understand it, unless the font itself is marked > "redistributable" in code, it will not be embedded in the PDF, so > there should be no actual legal issues. But what does Apache say > about requiring the sources to those fonts to be distributed along > with the PDF that was generated from it, and getting the font license > approved? I'd hope there was some kind of exception for this case > since otherwise it would be near impossible to distribute PDFs. What's the specific case you're thinking about? A specific PDF you want to include in a ManifoldCF release? Discussing licensing in abstract is often pretty difficult. BR, Jukka Zitting
Towards graduation
Hi, As you know I was a bit hesitant about graduation the last time the topic came up. I still am, but the developments over the past month or so have looked pretty good so I think we're on a good path here. The main improvements I see are Piergiorgio's many commits and the fact that the PPMC was able to reach the three +1s for the component releases without help or prodding by the mentors. And the stream of incoming patches from new contributors looks healthy. I think we should be able to invite new committers again soon. So nice work everyone! At this rate I think we should start preparing for graduation sometime early next year. BR, Jukka Zitting
Re: [RESULT][VOTE] Release apache-manifoldcf-sharepoint-3.0-plugin 0.1-incubating
Hi, +1 from me too (binding also for the upcoming IPMC vote) I checked the apache-manifoldcf-sharepoint-3.0-plugin-0.1-incubating-src.tar.gz package with SHA1 checksum 4400b19cf0940bae30778e9fdcb992122ecbc142. Without Windows or SharePoint readily at hand I couldn't build the package, just statically review it. One comment (not blocking) that applies also to the other components is that since these components (AFAIUI) don't contain or use any crypto code, we should remove the "Cryptographic Software Notice" entries from the README files. Those notices should only be included in components referenced in http://www.apache.org/licenses/exports/. BR, Jukka Zitting
Re: [RESULT][VOTE] Release apache-manifoldcf-solr-4.x-plugin 0.1-incubating
Hi, +1 from me too (binding also for the upcoming IPMC vote) I checked the apache-manifoldcf-solr-4.x-plugin-0.1-incubating-src.tar.gz package with SHA1 checksum 84065fe25707beec3b25831a9df56579ad685a50. See my comments for the Solr 3.x plugin. BR, Jukka Zitting
Re: [RESULT][VOTE] Release apache-manifoldcf-solr-3.x-plugin 0.1-incubating
Hi, +1 from me too (binding also for the upcoming IPMC vote) I checked the apache-manifoldcf-solr-3.x-plugin-0.1-incubating-src.tar.gz package with SHA1 checksum 14adbae8c05dc589a707208a172901cddd5c19d5. Some comments, none blocking: * The release signing guide [1] recommends to have also SHA1 checksums for the release. * The approach to do an svn checkout as a part of the build is a bit troublesome. The build will fail as soon as Lucene rearranges their svn tree. * Would it make sense to contribute this code directly to Solr instead of having it in ManifoldCF? Especially since the code has no direct ManifoldCF dependencies. [1] http://www.apache.org/dev/release-signing.html BR, Jukka Zitting
Re: Delivery of source of integration packages for 0.4-incubating
Hi, On Fri, Dec 9, 2011 at 5:07 PM, Karl Wright wrote: > These components rev based on the repository or search engine, not > based on ManifoldCF, and their dependencies are primarily on the > repository or search engine, not on ManifoldCF. Some of them can only > be built on Windows, for instance, and some require different versions > of Java than the base version we need to build the main ManifoldCF > code. I posted about this perhaps 2.5 months ago, and repeated my > query a few times; nobody seemed to have a better idea than to make > each plugin essentially a separate package. Sorry for missing the discussion at the time. It still sounds like conditional compiling would be a good solution to this, but you certainly understand the issues better so I trust your judgement here. To answer your original questions 1 and 2: 1) It sounds like it would be best to also include binaries as a part of the component releases if we're in any case going to be including those bits in the main ManifoldCF release. 2) As Tommaso already noted, the release process is essentially the same regardless of the kind of component being released. PS. As for component naming, "Apache SharePoint 3.0 ManifoldCF Plugin" is a bit unfortunate since it could be read as compoing from an "Apache SharePoint" project! A better one would be "Apache ManifoldCF plugin for SharePoint 3.0". BR, Jukka Zitting
Re: Delivery of source of integration packages for 0.4-incubating
Hi, On Thu, Dec 8, 2011 at 2:02 PM, Karl Wright wrote: > The manifoldcf 0.4-incubating release does not include sources for the > following components that are meant to be installed on repositories, Is there a particular reason why we shouldn't keep these components inside the main trunk and thus include them also in 0.4-incubating? BR, Jukka Zitting
Re: Delivery of source of integration packages for 0.4-incubating
Hi, On Fri, Dec 9, 2011 at 3:14 PM, Karl Wright wrote: > Essentially, this is a relatively minor piece of the whole Meridio > connector puzzle. In my view it would be unfortunate to discard the > rest of the puzzle because we did not have source for that one piece. > If Apache found that problematic, it could easily be checked in under > googlecode or some such, with a reference. What is Apache's position > regarding that kind of solution? IIUC we're talking about an extra service that needs to be installed along with the Meridio server being accessed. We could treat that as a system dependency just like we treat Meridio itself. The only problem then would be for end users who want to use the connector to figure out the licensing terms under which they can use this extra component. Since we can't distribute it from Apache, it needs to be made available from somewhere else preferably with good enough licensing documentation. ManifoldCF can then point to that location from the connector documentation. BR, Jukka Zitting
Re: Delivery of source of integration packages for 0.4-incubating
Hi, On Fri, Dec 9, 2011 at 2:45 PM, Karl Wright wrote: > So, what we have out of this is a redistributable .msi, and test code, > and that's it. > [...] > Assuming I get nowhere with the consultant, what is your advice about > the plugin? If we don't have (and can't reproduce) the source for the plugin, then it needs to be dropped as it's by definition not open source. BR, Jukka Zitting
Re: 1.0 release, and graduation
Hi, On Tue, Sep 27, 2011 at 3:05 PM, Karl Wright wrote: > The nature of this project is unique in that only a few committers are > interested in any given connector. This is very similar to the concern we used to have with Tika, that most people are only really interested in a narrow subset (i.e. a specific file format) of functionality. This in fact did turn out to be true for most contributors and committers, but the fact that they still need to cooperate on the core of shared code was enough to form a working community. > An approach I've been trying to use is to have at least one committer > per connector. [...] So, as I've discussed before, the criteria for becoming > a ManifoldCF committer has to be more nuanced and must take domain > knowledge into account, if we are to have anything like a committer base > that covers all the code. Agreed. There's no need for everyone to know every bit of the entire codebase. In fact there's probably no reasonably sized Apache project where any single committer is intimately familiar with all bits of the project. So from my perspective anyone who knows ManifoldCF well enough to implement a new working connector or to make substantial patches to an existing one is well above the entry barrier for committership. Let's get enough of such people actively involved, and we're ready to graduate! > I guess what I'm arguing for is a somewhat different set of graduation > criteria that is more suited to ManifoldCF's unique situation. As mentioned above, I don't see this situation as too unique within Apache. Growing beyond just a single active committer can be pretty time-consuming and frustrating, but the benefits are worth it. I'm sorry that the Incubator collectively and I personally haven't so far been too helpful in making this process easier. Hopefully we'll be able to help make the ride better from now on. BR, Jukka Zitting
Re: 1.0 release, and graduation
Hi, On Mon, Sep 19, 2011 at 9:06 PM, Karl Wright wrote: > (a) what we are still missing as far as incubator graduation is concerned There's still quite a bit to be done for community diversity. The drive to get new committers in is definitely a step in the right direction, but we'll need to follow up on that to make keep at least some of the new people as active members of the community. This is an area where mentors should be able to help (I'll try to increase my involvement here). To put things in perspective, since the beginning of this year Karl has made over 96% of all ManifoldCF commits. This makes the bus factor [1] of the project pretty high, and suggests that a more diverse development community is needed. The solution is not to have Karl commit less, but to get other people to more actively join the fun. The situation here is roughly similar to what we experienced during the incubation of Apache Tika. In the last year before graduation (2008) I was responsible for about 87% of all commits, which raised similar concerns about diversity [2]. The solution then was to graduate into a Lucene subproject instead of a full TLP, so that the larger project could still provide oversight and continuity in case things went wrong. Since then Lucene has shed out most subprojects to avoid being too large to manage, and by the time Tika in 2010 became a TLP by itself my share of all commits had shrunk to a still high but much more reasonable 62%. Today I'm still the most active committer, but my share of all the activity is down to 44%. I'd like to see ManifoldCF follow a similar trajectory. Graduating into a Lucene subproject is probably out of the question given the structural changes in Lucene, so for now my recommendation would be to remain in the Incubator until the community balance gets better. Some of the key things I did in Tika to help reduce my central role there were to lower the barriers of entry by working on things like the Getting Started page [3] and adding tools like the runnable tika-app jar and the simple GUI interface that make it trivially easy for someone to get started using Tika. The Build and Deploy guide in ManifoldCF [4] and the start.jar mechanism are good steps in this direction, but I think we could streamline quite a few of those steps. As Tommaso and others already mentioned, things like a simpler build process and a nicer UI can be quite useful. These are things that don't usually mean much to people already familiar to the system, but for potential new users and contributors with a short attention span they matter a lot. Thus I think these are areas that we should try to focus on in near future. [1] http://en.wikipedia.org/wiki/Bus_factor [2] http://markmail.org/message/bvqs2zv762fmlyv5 [3] http://tika.apache.org/0.9/gettingstarted.html [4] http://incubator.apache.org/connectors/how-to-build-and-deploy.html BR, Jukka Zitting
[jira] Commented: (CONNECTORS-116) Possibly remove memex connector depending upon legal resolution
[ https://issues.apache.org/jira/browse/CONNECTORS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920488#action_12920488 ] Jukka Zitting commented on CONNECTORS-116: -- >From a somewhat related legal-discuss@ thread: "We're not in the business of >incorporating code from non-voluntary contributions." -- Justin Erenkranz (see >http://markmail.org/message/x5nlmpumncg66zz6) > Possibly remove memex connector depending upon legal resolution > --- > > Key: CONNECTORS-116 > URL: https://issues.apache.org/jira/browse/CONNECTORS-116 > Project: ManifoldCF > Issue Type: Task > Components: Memex connector >Reporter: Robert Muir >Assignee: Robert Muir > > Apparently there is an IP problem with the memex connector code. > Depending upon what apache legal says, we will take any action under this > issue publicly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
LCF report missing
Hi, I guess nobody took up the task of writing an LCF report for this months board meeting [1]. I was quite busy last week so I unfortunately didn't notice this in time. Sorry about that. The missing report is not too big a deal, but we'll need to submit an extra report next month. [1] http://wiki.apache.org/incubator/June2010 BR, Jukka Zitting
Re: Proposed status
Hi, On Tue, Mar 9, 2010 at 3:22 PM, Grant Ingersoll wrote: > This looks good to me. +1 from me too. One note though, mostly something to keep in mind for the next report: On Mar 8, 2010, at 9:13 AM, Karl Wright wrote: > === A list of the three most important issues to address in the move towards > graduation === > 1. Need to include README, LICENSE, NOTICE, etc. at the project level > 1. End-user documentation needs to be converted into a usable form > 1. Apache2 plugin source needs a build mechanism The Incubator graduation criteria don't refer to technical quality or status, so strictly speaking the points about documentation and build system are not required here. The size and diversity of the development community is a more important consideration for graduation. BR, Jukka Zitting
Re: activation.jar, mailapi.jar
Hi, On Wed, Feb 17, 2010 at 12:58 PM, Karl Wright wrote: > The Meridio connector needs both of these jars to function, but they seem to > be licensed by Sun as non-redistributable. For now, I've set them up as a > build requirement of the connector - if they aren't there, the connector > build will be skipped. But does anyone know an official Apache way to deal > with these? The Geronimo project has produced ALv2 versions of these jars: http://repo2.maven.org/maven2/org/apache/geronimo/specs/geronimo-javamail_1.4_spec/ http://repo2.maven.org/maven2/org/apache/geronimo/specs/geronimo-activation_1.1_spec/ BR, Jukka Zitting
Re: Draft February Report
Hi, On Tue, Feb 9, 2010 at 3:10 PM, Grant Ingersoll wrote: > Please review and provide feedback by tomorrow and then I'll submit. Looks good to me. > 1. Process initial code grant and incorporate into SVN > 2. Create general build system > 3. Do a release I'd drop 2 as it's kind of already required by 3. Instead I'd add a point for "Grow a diverse development community". We'll want to see patches coming in also from beyond the original development team. BR, Jukka Zitting
[jira] Commented: (CONNECTORS-1) Create a Website
[ https://issues.apache.org/jira/browse/CONNECTORS-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803658#action_12803658 ] Jukka Zitting commented on CONNECTORS-1: > It is checked into svn root though. Are you planning to move it to trunk? The site is typically a bit separate from the latest developments in trunk. For example we may well want to keep copies of the documentation (javadocs, etc.) of all past releases in the site, whereas having such things in trunk is just extra baggage. > Create a Website > > > Key: CONNECTORS-1 > URL: https://issues.apache.org/jira/browse/CONNECTORS-1 > Project: Lucene Connector Framework > Issue Type: Task > Components: Site >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > > see title -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Lucene Connector Framework Update
Hi, I also configured the issue tracker to send notifications to connectors-dev@ whenever there is any activity on the issues. BR, Jukka Zitting
Re: Lucene Connector Framework Update
Hi, On Wed, Jan 20, 2010 at 6:51 PM, Grant Ingersoll wrote: > SVN is setup at https://svn.apache.org/repos/asf/incubator/lcf/. I've set up commit notifications to connectors-comm...@. I'll make a test commit soon to verify. > Wiki is at http://cwiki.apache.org/confluence/display/CONNECTORS/Index. I've set up change notifications to connectors-comm...@. I made a few changes that should be hitting the moderation queue soon. BR, Jukka Zitting
