Hi Russ, That's probably a good place to start. The code contributor workflow [1] should have all the steps necessary to get the code, build, test, and make contributions. If you get stuck anywhere, let us know, it probably means the instruction are bad.
Until we get bugs tagged as good tasks for new contributors, perhaps a good introductory bug is DAFFODIL-1928 and maybe related bug DAFFODIL-1420. The fix for these should just be a matter of updating a libraryDependency and moving existing test cases out of src/test/scala-debug and into src/test/scala. Should be a fairly small and hopefully painless first contribution just to get you familiar with the build/test/pull-request process of Daffodil. Thanks! - Steve [1] https://cwiki.apache.org/confluence/display/DAFFODIL/Code+Contributor+Workflow On 05/23/2018 01:21 PM, Russ Williams wrote: > Hi Mike! > > I guess I should grab a copy of the source, get it building locally, and then > take a look through the JIRAs to find some small tasks that I can figure out > how to do with ~zero knowledge of the codebase. That’ll probably be a good > shortlist for newbies? > > Cheers, > — > Russ > >> On 23 May 2018, at 17:51, Mike Beckerle <mbecke...@tresys.com> wrote: >> >> Hi Russ, >> >> >> Glad you contacted us. Would be great to have another contributor. >> >> >> Your insights are correct - DFDL evolved driven by standardization of >> existing data integration tool capabilities, which were focused on files >> that you would probably call "data set files", as opposed to image, >> document, archive, etc. file formats. We didn't have examples of data >> integration systems/tools that did things like file-offsets, so things like >> the index structure in zip you described, were beyond the state of the art >> for declarative description. >> >> >> But now we have Daffodil open-source, which is the perfect vehicle for >> prototyping and creating features enabling these sorts of data descriptions, >> and subsequently then, based on that experience, we can feed ideas back to >> the DFDL standard for incorporation into a future version of the standard. >> >> >> As for specifics of how you can start to contribute, longer discussion. >> >> >> We have ambition to label the JIRA tickets for Daffodil to identify good >> first projects for new contributors, .... The whole pool of JIRA tickets, >> which are our project-wide TODO list, is at >> >> https://issues.apache.org/jira/projects/DAFFODIL >> >> >> There are 450+ tickets open, so there is lots to work on. >> >> >> I'll leave it at that for this message. >> >> >> ...mike beckerle >> >> >> >> >> >> >> ________________________________ >> From: Russ Williams <r...@reciprocity.com> >> Sent: Wednesday, May 23, 2018 5:54:14 AM >> To: dev@daffodil.apache.org >> Subject: Can I help? >> >> Hi! >> >> I stumbled across DFDL / Apache Daffodil yesterday while looking for a way >> to specify file formats in a machine-readable form. I was surprised that >> there hasn’t been a lot more effort in this space, given the importance for >> archival, and I’m very keen to see the project succeed. I’ve not done much >> Open Source work before, but I’m a commercial software engineer/architect >> with over two decades’ experience, so hopefully I could be of some use. >> >> I’m particularly interested in the handling of large binary files, which I >> see from the wiki and JIRA (e.g. DAFFODIL-1735) is a key area of concern for >> you guys as well, but I’m a little concerned that the DFDL 1.0 spec seems to >> have been written with some XML-like assumptions of how parsing should work, >> rather than how various binary formats are actually parsed (e.g. ZIP, with a >> signature at the start, then an index at the end, doesn’t seem to fit the >> document model). >> >> Are you looking for people to get involved with Daffodil? Is there anything >> I can help with to get started? >> >> Warm regards, >> — >> Russ >
