Hi - I agree. I'm willing to proceed with John and I as Mentors.
Regards, Dave Sent from my iPhone > On Aug 8, 2017, at 7:10 PM, John D. Ament <johndam...@apache.org> wrote: > > Steve, > > At this point, I'd recommend we wrap the discussion and call for a vote. > While ideally we want 3 mentors, we can get started with 2 and see how things > progress. > > John > >> On Wed, Aug 2, 2017 at 3:55 PM Steve Lawrence <stephen.d.lawre...@gmail.com> >> wrote: >> Thanks John! >> >> On 08/02/2017 03:23 PM, John D. Ament wrote: >> > You can also count me in as a mentor. >> > >> > John >> > >> > On Wed, Aug 2, 2017 at 3:14 PM Steve Lawrence >> > <stephen.d.lawre...@gmail.com> >> > wrote: >> > >> >> Understood. Thanks for the interest! >> >> >> >> - Steve >> >> >> >> On 08/02/2017 02:57 PM, Dave Fisher wrote: >> >>> Hi Steve, >> >>> >> >>> It was not so much the lack of committers as it was the current >> >> diversity. That is not a blocker for entry to Incubation. >> >>> >> >>> I am willing to be one of the Mentors. Once there are at least two more >> >> we can push forward. >> >>> >> >>> Regards, >> >>> Dave >> >>> >> >>>> On Aug 1, 2017, at 5:09 AM, Steve Lawrence < >> >> stephen.d.lawre...@gmail.com> wrote: >> >>>> >> >>>> Discussions have died down, and I think the consensus from the responses >> >>>> is that the issues are 1) the lack of committers and 2) the lack of a >> >>>> champion and mentors. We hope to address #1 and grow the community as >> >>>> part of incubation. Is anyone interested in being a champion or mentor >> >>>> and help us with #2? >> >>>> >> >>>> Thanks, >> >>>> - Steve >> >>>> >> >>>> On 07/26/2017 04:06 PM, Chris Mattmann wrote: >> >>>>> This sounds like a very interesting project. >> >>>>> >> >>>>> I don’t have the time to mentor at the moment but I will keep a close >> >> eye on it. >> >>>>> >> >>>>> Cheers, >> >>>>> Chris Mattmann >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 7/25/17, 11:53 AM, "McHenry, Kenton Guadron" <mche...@illinois.edu> >> >> wrote: >> >>>>> >> >>>>> Hi Dave, >> >>>>> >> >>>>> The developers that were at NCSA have moved on to other >> >> organizations. While we still leverage Daffodil and are very much >> >> interested in seeing it move forward, development is currently done by the >> >> Tresys team. Agreed on the synergy with Tika. >> >>>>> >> >>>>> Kenton McHenry, Ph.D. >> >>>>> Principal Research Scientist, Adjunct Assistant Professor of >> >> Computer Science >> >>>>> Deputy Director of the Scientific Software & Applications Division >> >>>>> National Center for Supercomputing Applications, University of >> >> Illinois at Urbana-Champaign >> >>>>> >> >>>>> On Jul 24, 2017, at 1:55 PM, Dave Fisher <dave2w...@comcast.net >> >> <mailto:dave2w...@comcast.net>> wrote: >> >>>>> >> >>>>> Hi Kenton, >> >>>>> >> >>>>> Is there any reason that you and others from the NCSA are not >> >> Initial Committers? That would make this proposal stronger. >> >>>>> >> >>>>> Regarding Apache Tika - it relies on other projects including >> >> Apache POI and Apache PDFBox. They are pragmatic about what is used. If >> >> Daffodil works to expand then I think that there would be good synergy >> >> between the projects. I know as a POI PMC member that the POI community >> >> has >> >> significantly benefited from the Tika community some of whom are from >> >> Mitre. >> >>>>> >> >>>>> To date Tika has not emphasized structured data, although they do >> >> extract content from Excel and OpenOffice. >> >>>>> >> >>>>> I am intrigued. >> >>>>> >> >>>>> Regards, >> >>>>> Dave >> >>>>> >> >>>>> On Jul 24, 2017, at 10:55 AM, McHenry, Kenton Guadron < >> >> mche...@illinois.edu<mailto:mche...@illinois.edu>> wrote: >> >>>>> >> >>>>> Yes, DFDL and its open source implementation Daffodil are more >> >> about file formats and getting access to the entirety of a file's contents >> >> in a consistent way through machine readable specifications. The work has >> >> implications in the area of digital preservation allowing one to preserve >> >> these machine readable specifications rather than all the tools needed to >> >> open/save a file in order to work with it. Imagine someone developing >> >> graphics software to work with 3D models and not having to worry about the >> >> hundreds of formats out there for 3D meshes (whether there are tools for >> >> opening the files and whether they can get access to those tools, whether >> >> the spec is available and worrying about how complex that spec is to >> >> implement, etc.), and simply building their code around the contents (e.g. >> >> vertices, faces, etc.). One could come up with similar scenarios for >> >> other >> >> data types (documents, images, videos, audio, depth data, numeric data). >> >> Ideally tools built supporting DFDL, could someday, support any format for >> >> that type without the developer having to worry about the details of how >> >> that data is represented within a file. >> >>>>> >> >>>>> Kenton McHenry, Ph.D. >> >>>>> Principal Research Scientist, Adjunct Assistant Professor of >> >> Computer Science >> >>>>> Deputy Director of the Scientific Software & Applications Division >> >>>>> National Center for Supercomputing Applications, University of >> >> Illinois at Urbana-Champaign >> >>>>> >> >>>>> On Jul 24, 2017, at 10:30 AM, Steve Lawrence < >> >> stephen.d.lawre...@gmail.com<mailto:stephen.d.lawre...@gmail.com><mailto: >> >> stephen.d.lawre...@gmail.com>> wrote: >> >>>>> >> >>>>> I'll preface this saying that I don't have a ton of experience with >> >>>>> Apache Tika. But based on my understanding, Tika and Daffodil do >> >> have >> >>>>> somewhat similar goals, but reach them in different ways. For >> >> example, >> >>>>> Tika requires that one writes /code/ to perform data extraction, >> >> usually >> >>>>> relying on existing Java libraries to extract the desired metadata. >> >> The >> >>>>> downside to this is that code can be buggy, and libraries might not >> >> even >> >>>>> exist for formats of interest (especially common with legacy and >> >>>>> military data). >> >>>>> >> >>>>> Daffodil, on the other hand, does not require one to write any code. >> >>>>> Instead, one writes a DFDL Schema (similar to XML Schema, with DFDL >> >>>>> annotations) that fully describes the data, which Daffodil then >> >> uses to >> >>>>> convert the data to XML/JSON for extraction. So adding support for >> >> a new >> >>>>> format means writing a new schema rather than new code. And less >> >> code >> >>>>> generally means less bugs. Also, for secure systems that require >> >>>>> certification, generally speaking, it is easier to certify a schema >> >> as >> >>>>> compared to code. >> >>>>> >> >>>>> We certainly don't believe that Daffodil could replace Tika, but it >> >> does >> >>>>> have the potential to add new functionality to Tika for formats >> >> that do >> >>>>> not have existing libraries. One of our goals is to look into >> >>>>> integrating Daffodil support into tools like Tika. We'd love to hear >> >>>>> from Tika devs if this is something they'd be interested in. >> >>>>> >> >>>>> I'll also add that whereas Tika tends to focus primarily on >> >> metadata, >> >>>>> DFDL schemas usually describe an entire file format down to the >> >> byte, so >> >>>>> one can extract more than just meta data, including text and binary >> >>>>> data. Further differentiating, Daffodil has support for serializing >> >> data >> >>>>> (called unparse) from the XML/JSON representation, allowing one to >> >>>>> transform or filter data as well. We don't believe this feature is >> >> all >> >>>>> that applicable to Tika, but may be useful to other technologies >> >> such as >> >>>>> filtering or data fuzzing technologies. >> >>>>> >> >>>>> - Steve >> >>>>> >> >>>>> >> >>>>> On 07/24/2017 10:59 AM, Mike Drob wrote: >> >>>>> What is the relationship between Daffodil and something like Apache >> >> Tika's >> >>>>> extraction engine? >> >>>>> >> >>>>> On Mon, Jul 24, 2017 at 9:53 AM, Steve Lawrence < >> >>>>> stephen.d.lawre...@gmail.com<mailto:stephen.d.lawre...@gmail.com >> >>> <mailto:stephen.d.lawre...@gmail.com>> wrote: >> >>>>> >> >>>>> Dear Apache Incubator Community, >> >>>>> >> >>>>> We would like to start a discussion around a proposal to bring >> >> Daffodil >> >>>>> into the Apache Incubator. Daffodil is a implementation of the DFDL >> >>>>> specification used to convert between fixed format data and >> >> XML/JSON. >> >>>>> >> >>>>> The draft proposal can be found in the wiki at the following URL: >> >>>>> >> >>>>> https://wiki.apache.org/incubator/DaffodilProposal >> >>>>> >> >>>>> We do not yet have a champion or mentors, but it was recommended >> >> that we >> >>>>> create a proposal and send it to this list to potentially find those >> >>>>> that might be interested. The text for the draft proposal is found >> >>>>> below. We look forward to your input. >> >>>>> >> >>>>> Thanks, >> >>>>> -Steve >> >>>>> >> >>>>> >> >>>>> = Daffodil Proposal = >> >>>>> >> >>>>> == Abstract == >> >>>>> >> >>>>> Daffodil is an implementation of the Data Format Description >> >> Language >> >>>>> (DFDL) used to convert between fixed format data and XML/JSON. >> >>>>> >> >>>>> == Proposal == >> >>>>> >> >>>>> The Data Format Description Language (DFDL) is a specification, >> >>>>> developed by the Open Grid Forum, capable of describing many data >> >>>>> formats, including both textual and binary, scientific and numeric, >> >>>>> legacy and modern, commercial record-oriented, and many industry and >> >>>>> military standards. It defines a language that is a subset of W3C >> >> XML >> >>>>> schema to describe the logical format of the data, and annotations >> >>>>> within the schema to describe the physical representation. >> >>>>> >> >>>>> Daffodil is an open source implementation of the DFDL specification >> >> that >> >>>>> uses these DFDL schemas to parse fixed format data into an infoset, >> >>>>> which is most commonly represented as either XML or JSON. This >> >> allows >> >>>>> the use of well-established XML or JSON technologies and libraries >> >> to >> >>>>> consume, inspect, and manipulate fixed format data in existing >> >>>>> solutions. Daffodil is also capable of the reverse by serializing or >> >>>>> "unparsing" an XML or JSON infoset back to the original data format. >> >>>>> >> >>>>> == Background == >> >>>>> >> >>>>> Many different software solutions need to consume and manage data, >> >>>>> including data directed routing, databases, data analysis, data >> >>>>> cleansing, data visualizing, and more. A key aspect of such >> >> solutions is >> >>>>> the need to transform the data into an easily consumable format. >> >>>>> Usually, this means that for each unique data format, one develops a >> >>>>> tool that can read and extract the necessary information, often >> >> leading >> >>>>> to ad-hoc and data-format-specific description systems. Such >> >> systems are >> >>>>> often proprietary, not well tested, and incompatible, leading to >> >> vendor >> >>>>> lock-in, flawed software, and increased training costs. DFDL is a >> >> new >> >>>>> standard, with version 1.0 completed in October of 2016, that solves >> >>>>> these problems by defining an open standard to describe many >> >> different >> >>>>> data formats and how to parse and unparse between the data and >> >> XML/JSON. >> >>>>> >> >>>>> Two closed source implementations of DFDL currently exist. The >> >> first was >> >>>>> created by IBM and is now part of their IBM® Integration Bus >> >> product. >> >>>>> The second was created by the European Space Agency, called DFDL4S >> >> or >> >>>>> "DFDL for Space" targeted at the challenges of their satellite data >> >>>>> processing. >> >>>>> >> >>>>> Around 2005, Pacific Northwest National Lab created Defuddle, built >> >> as >> >>>>> an open source implementation and proof of concept of the draft DFDL >> >>>>> specification and a test bed to feed new concepts into specification >> >>>>> development. Primary development of Defuddle was eventually taken >> >> over >> >>>>> by the National Center for Supercomputing Applications (NCSA). >> >> However, >> >>>>> due to evolution of the DFDL specification and architectural and >> >>>>> performance issues with Defuddle, around 2009, NCSA restarted the >> >>>>> project with the new name of Daffodil, with a goal of implementing >> >> the >> >>>>> complete DFDL specification. Daffodil development continued at NCSA >> >>>>> until around 2012, at which point development slowed due to budget >> >>>>> limitations. Shortly thereafter, primary development was picked up >> >> by >> >>>>> Tresys Technology where it continues today, with contributions from >> >>>>> other entities such as the Navy Research Lab, the Air Force Research >> >>>>> Lab, MITRE, and Booz Allen Hamilton. In February of 2015, Daffodil >> >>>>> version 1.0.0 was released, including support for the DFDL features >> >>>>> needed to parse many common file formats. Daffodil version 2.0.0 is >> >>>>> expected to be released in August of 2017, which will include >> >> unparse >> >>>>> support with one-to-one parsing feature parity. >> >>>>> >> >>>>> Entities including IBM, MITRE, NATO NCI Agency, Northrop-Grumman, >> >> Quark >> >>>>> Security, Raytheon, and Tresys Technology have developed DFDL >> >> schemas >> >>>>> for many data formats from varying technology domains, including >> >> PNG, >> >>>>> GIF, BMP, PCAP, HL7, EDIFACT, NACHA, vCard, iCalendar, and >> >> MIL-STD-2045, >> >>>>> many of which are publicly available on the DFDL Schemas github. >> >> There >> >>>>> are also a number of military-application data formats, the >> >>>>> specifications of which are not public, which have historically been >> >>>>> very difficult and expensive to process, and for which DFDL schemas >> >> have >> >>>>> been created or are actively in development; these include >> >>>>> MIL-STD-6040/USMTF ATO, MIL-STD-6017/VMF, MIL-STD-6016/NATO STANAG >> >> 5516 >> >>>>> (aka "Link16"). >> >>>>> >> >>>>> == Rationale == >> >>>>> >> >>>>> Numerous software solutions exist that consume, inspect, analyze, >> >> and >> >>>>> transform data, many of which can be found in the Apache Software >> >>>>> Foundation (ASF). In order for tools like these to consume new >> >> types of >> >>>>> data, custom extensions are usually required, often with high >> >>>>> development and testing costs. Daffodil fills a clear gap in many of >> >>>>> these solutions, providing a simple and low cost way to transform >> >> data >> >>>>> to XML or JSON, which many of these tools natively support already. >> >> With >> >>>>> the upcoming 2.0.0 release, the Daffodil project will have achieved >> >> a >> >>>>> level of functionality in both parse and unparse that, when >> >> integrated >> >>>>> into existing solutions, could provide for a new method to quickly >> >>>>> enable support for new data formats. >> >>>>> >> >>>>> == Initial Goals == >> >>>>> >> >>>>> * Relicense the existing code from the University of Illinois/NCSA >> >> Open >> >>>>> Source License to the Apache License version 2.0, working with >> >> Apache >> >>>>> Legal to ensure correctness, and with Daffodil contributors to get >> >>>>> their permission. >> >>>>> * Move the existing codebase, documentation, bugs, and mailing >> >> lists to >> >>>>> the Apache hosted infrastructure >> >>>>> * Establish a formal release process and schedule, allowing for >> >>>>> dependable release cycles in a manner consistent with the Apache >> >>>>> development process. >> >>>>> * Build relationships with ASF projects to add Daffodil support >> >> where >> >>>>> appropriate >> >>>>> * Grow the community to establish a diversity of background and >> >> expertise. >> >>>>> >> >>>>> == Current Status == >> >>>>> >> >>>>> === Meritocracy === >> >>>>> >> >>>>> All initial committers are familiar with the principles of >> >> meritocracy. >> >>>>> The Daffodil project has followed the model of meritocracy in the >> >> past, >> >>>>> providing multiple outside entities commit access based on the >> >> quality >> >>>>> of their contributions. In order to grow the Daffodil user base and >> >>>>> development community, we are dedicated to continuing to operate >> >>>>> Daffodil as a meritocracy. >> >>>>> >> >>>>> A key ingredient in a meritocracy of developers is open group code >> >>>>> review. The Daffodil project has operated in this mode throughout >> >> its >> >>>>> existence and this provides a forum to improve the code, verify code >> >>>>> quality, and educate new developers on the code base. >> >>>>> >> >>>>> === Community === >> >>>>> >> >>>>> Daffodil has a small community of users and developers. Although >> >> primary >> >>>>> Daffodil development is done by Tresys Technology, a handful of >> >> other >> >>>>> contributions have come from other entities including the Navy >> >> Research >> >>>>> Lab, the Air Force Research Lab, MITRE, and Booz Allen Hamilton. In >> >>>>> addition to developers, multiple users of Daffodil have created DFDL >> >>>>> schemas, including entities such as MITRE, IBM, Raytheon, Quark >> >>>>> Security, and Tresys Technology. The DFDL Schemas github community >> >> has >> >>>>> been created as a place for DFDL schemas to be published. The >> >> Daffodil >> >>>>> project also makes use of mailing lists, !HipChat, and Confluence >> >>>>> Questions to build a community of users and system for support. >> >>>>> >> >>>>> === Core Developers === >> >>>>> >> >>>>> The core developers of Daffodil are employed by Tresys Technology. >> >> We >> >>>>> will work to grow the community among a more diverse set of >> >> developers >> >>>>> and industries. >> >>>>> >> >>>>> === Alignment === >> >>>>> >> >>>>> Daffodil was created as an open source project with a philosophy >> >>>>> consistent with The Apache Way. A strong belief in meritocracy, >> >>>>> community involvement in decisions, openness, and ensuring a high >> >> level >> >>>>> of quality in code, documentation, and testing are some of our >> >> shared >> >>>>> core beliefs. >> >>>>> >> >>>>> Further, as mentioned in the Rationale section, Daffodil fills a gap >> >>>>> that exists in many ASF projects, including !NiFi, Spark, Storm, >> >> Hadoop, >> >>>>> Tika, and others. In order for tools like these to consume new >> >> types of >> >>>>> data, custom extensions are usually required. Rather than create >> >> such >> >>>>> extensions, Daffodil provides an easy and standards-compliant way to >> >>>>> transform data to XML or JSON, which many of these tools already >> >>>>> natively support. >> >>>>> >> >>>>> == Known Risks == >> >>>>> >> >>>>> === Orphaned Products === >> >>>>> >> >>>>> The current core developers are the leading contributors in the >> >> space of >> >>>>> DFDL and wish to see it flourish. Though there is some risk that the >> >>>>> initial committers all come from the same company, a goal of >> >> entering >> >>>>> into incubation is to grow the development community to minimize the >> >>>>> risk of reliance on a single company. >> >>>>> >> >>>>> === Inexperience with Open Source === >> >>>>> >> >>>>> The Daffodil project began as an open source project and has >> >> continued >> >>>>> that model throughout development. This includes public bug >> >> tracking, >> >>>>> git revision control, automated builds and tests, and a public wiki >> >> for >> >>>>> documentation. >> >>>>> >> >>>>> Additionally, the current core developers and initial committers all >> >>>>> work for a company that relies on, believes in, promotes, and has >> >> led or >> >>>>> contributed to many open source software projects, including SELinux >> >>>>> Userspace, OpenSCAP, CLIP, refpolicy, setools, RPM, and others. As >> >> such, >> >>>>> there is low risk related to inexperience with open source software >> >> and >> >>>>> processes. >> >>>>> >> >>>>> === Homogeneous Developers === >> >>>>> >> >>>>> The proposed initial committers come from a single entity, though >> >> we are >> >>>>> committed to growing the Daffodil development community to include a >> >>>>> broad group of additional committers from a wide array of >> >> industries. >> >>>>> >> >>>>> === Reliance on Salaried Developers === >> >>>>> >> >>>>> The proposed initial committers are paid by their employer to >> >> contribute >> >>>>> to the Daffodil project. We expect that Daffodil development will >> >>>>> continue with salaried developers, and are committed to growing the >> >>>>> community to include non-salaried developers as well. >> >>>>> >> >>>>> === Relationship with other Apache Projects === >> >>>>> >> >>>>> As mentioned in the Alignment section, Daffodil fills a clear gap in >> >>>>> numerous other ASF projects that consume and manage large amounts >> >> of data. >> >>>>> >> >>>>> As a specific example, Daffodil developers have created a Daffodil >> >>>>> Apache !NiFi Processor, currently in use in data transfer solutions, >> >>>>> which allows one to ingest non-native data into an Apache !NiFi >> >> pipeline >> >>>>> as XML or JSON. This processor was well received by the Apache !NiFi >> >>>>> developers, with positive comments about the concise API and how it >> >>>>> could handle non-native data. Daffodil developers have also >> >> successfully >> >>>>> prototyped integration with Apache Spark. We believe Daffodil could >> >>>>> provide a strong benefit to many other ASF projects that handle >> >> fixed >> >>>>> format data. We anticipate working closely with such ASF projects to >> >>>>> include Daffodil where applicable to increase their ability to >> >> support >> >>>>> new data formats with minimal effort. >> >>>>> >> >>>>> Daffodil also depends on existing ASF projects, including Apache >> >> Commons >> >>>>> and Apache Xerces. >> >>>>> >> >>>>> === An Excessive Fascination with the Apache Brand === >> >>>>> >> >>>>> Although the Apache brand may certainly help to attract more >> >>>>> contributors, publicity is not the reason for this proposal. We >> >> believe >> >>>>> Daffodil could provide a great benefit to the ASF and the numerous >> >> data >> >>>>> focused projects that comprise it, as described in the Rationale and >> >>>>> Alignment sections. We hope to build a strong and vibrant community >> >>>>> built around The Apache Way, and not dependent on a single company. >> >>>>> >> >>>>> === Documentation === >> >>>>> >> >>>>> Daffodil documentation can be found at: >> >>>>> >> >>>>> * >> >>>>> https://opensource.ncsa.illinois.edu/confluence/ >> >>>>> display/DFDL/Daffodil%3A+Open+Source+DFDL >> >>>>> >> >>>>> Information about DFDL can be found at: >> >>>>> >> >>>>> * https://www.ogf.org/ogf/doku.php/standards/dfdl/dfdl >> >>>>> * >> >>>>> https://www.ibm.com/support/knowledgecenter/en/SSMKHH_9.0. >> >>>>> 0/com.ibm.etools.mft.doc/df20060_.htm >> >>>>> >> >>>>> Public examples of DFDL Schemas can be found at: >> >>>>> >> >>>>> * https://github.com/DFDLSchemas >> >>>>> >> >>>>> == Initial Source == >> >>>>> >> >>>>> The Daffodil git repo goes back to mid-2011 with approximately 20 >> >>>>> different contributors and feedback from many users and developers. >> >> The >> >>>>> core codebase is written in Scala and includes both a Scala and Java >> >>>>> API, along with Javadocs and Scaladocs for API usage. The initial >> >> code >> >>>>> will come from the git repository currently hosted by NCSA at the >> >>>>> University of Illinois : >> >>>>> >> >>>>> https://opensource.ncsa.illinois.edu/bitbucket/ >> >>>>> projects/DFDL/repos/daffodil/ >> >>>>> >> >>>>> == Source and Intellectual Property Submission == >> >>>>> >> >>>>> The complete Daffodil code is licensed under the University of >> >>>>> Illinois/NCSA Open Source License. Much of the current codebase has >> >> been >> >>>>> developed by Tresys Technology, who is open to relicensing the code >> >> to >> >>>>> the Apache License version 2.0 and donate the source to the ASF. >> >>>>> Contacts at NCSA are also open to relicensing their contributions to >> >>>>> Apache v2. We plan to contact the other contributors and ask for >> >>>>> permission to relicense and donate their contributed code. For those >> >>>>> that decline or we cannot contact, their code will be removed or >> >>>>> replaced. We will work closely with Apache Legal to ensure all >> >> issues >> >>>>> related to relicensing are acceptable. >> >>>>> >> >>>>> == External Dependencies == >> >>>>> >> >>>>> We believe all current dependencies are compatible with the ASF >> >>>>> guidelines. Our dependency licenses come from the following license >> >>>>> styles: Apache v2, BSD, MIT, and ICU. The list of current Daffodil >> >>>>> dependencies and their licenses are documented here: >> >>>>> >> >>>>> https://opensource.ncsa.illinois.edu/confluence/ >> >>>>> display/DFDL/Dependencies+and+Licenses >> >>>>> >> >>>>> == Cryptography == >> >>>>> >> >>>>> None >> >>>>> >> >>>>> == Required Resources == >> >>>>> >> >>>>> === Mailing Lists === >> >>>>> >> >>>>> * comm...@daffodil.incubator.apache.org >> >>>>> * d...@daffodil.incubator.apache.org >> >>>>> * priv...@daffodil.incubator.apache.org >> >>>>> * u...@daffodil.incubator.apache.org >> >>>>> >> >>>>> === Source Control === >> >>>>> >> >>>>> git://git.apache.org/incubator-daffodil.git >> >>>>> >> >>>>> === Issue Tracking === >> >>>>> >> >>>>> JIRA Daffodil (DFDL) >> >>>>> >> >>>>> === Initial Committers === >> >>>>> >> >>>>> * Beth Finnegan <efinnegan at tresys dot com> >> >>>>> * Dave Thompson <dthompson at tresys dot com> >> >>>>> * Josh Adams <jadams at tresys dot com> >> >>>>> * Mike Beckerle <mbeckerle at tresys dot com> >> >>>>> * Steve Lawrence <slawrence at tresys dot com> >> >>>>> * Taylor Wise <twise at tresys dot com> >> >>>>> >> >>>>> === Affiliations === >> >>>>> >> >>>>> * Beth Finnegan (Tresys Technology) >> >>>>> * Dave Thompson (Tresys Technology) >> >>>>> * Josh Adams (Tresys Technology) >> >>>>> * Mike Beckerle (Tresys Technology) >> >>>>> * Steve Lawrence (Tresys Technology) >> >>>>> * Taylor Wise (Tresys Technology) >> >>>>> >> >>>>> == Sponsors == >> >>>>> >> >>>>> === Champion === >> >>>>> >> >>>>> * TBD >> >>>>> >> >>>>> === Nominated Mentors === >> >>>>> >> >>>>> * TBD >> >>>>> >> >>>>> === Sponsoring Entity === >> >>>>> >> >>>>> We request the Apache Incubator to sponsor this project. >> >>>>> >> >>>>> >> >> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >> <mailto:general-unsubscr...@incubator.apache.org> >> >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >> >> <mailto:general-h...@incubator.apache.org> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >>>> For additional commands, e-mail: general-h...@incubator.apache.org >> >>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >>
