Heh, and I just commented on DAFFODIL-1900. I tend to be on the opposite side of the boat, leaning towards not needing headers. At the end of the day, I don't care. Whatever route you guys want to go is fine.
Agreed on all other points. John On Mon, Feb 12, 2018 at 5:24 PM Steve Lawrence <slawre...@apache.org> wrote: > Thanks for the review! > > 1a) I've created LEGAL-369 to get guidance on the OGF document. > > 1b) I've created DAFFODIL-1899 to fix the LICENSE/NOTICE issues. > > 2a) The current version of rat 0.12 when run from the command line says > the excluded files are "Files with unapproved licenses". It does not > seem to detect them as non-Apache but permissible. Perhaps the licenses > aren't included in a way RAT can detect. Will investigate this issue. > > 2b) I've created DAFFODIL-1900 for this, but have assigned it to our > next release to investigate best how to handle this. > > Thanks, > - Steve > > > On 02/12/2018 03:46 PM, Dave Fisher wrote: > > Hi - > > > > A few quick comments from a partial review of the Source and Binary > release. > > > > (1) LICENSE & NOTICE. > > > > (a) The copyright portions that are in the LICENSE on the various > licenses > > should be moved to the NOTICE. The LICENSE should still include which > files are > > under the other licenses. > > > > (b) The Open Grid Forum DFDL v1.0 license needs to be confirmed as > permissible > > by the Legal Affairs committee. This should include guidance about > NOTICE vs. > > LICENSE. Legal JIRA issues can be created in the issue tracker. > > https://issues.apache.org/jira/projects/LEGAL > > > > (2) .rat-excludes > > > > (a) The following should not be excluded. RAT should pick up the > licenses as > > category A if they are present. > > # passera is 3-clause BSD > > passera > > > > # copyright Scala BSD license > > Utility.scala > > UniquenessCache.scala > > > > # copyright w3c with permissive license > > XMLSchema.dtd > > XMLSchema.xsd > > XMLSchema_for_DFDL.xsd > > datatypes.dtd > > xml.xsd > > > > (b) Test files. > > > > For the future, but not now. There have been debates in other projects. > Guidance > > from some on legal-discuss@ has been to include license headers in test > files > > and then have the test tooling eliminate the license so that tests do > not have > > to take it into account or be rewritten. > > > > Regards, > > Dave > > > >> On Feb 12, 2018, at 11:24 AM, Steve Lawrence <slawre...@apache.org > >> <mailto:slawre...@apache.org>> wrote: > >> > >> I believe we have now resolved all issues raised so far in 2.1.0-rc1. > >> The name changes in dist/dev/daffodil will go into effect for the rc2 > >> release files. > >> > >> John or Dave, have either of you had a chance to review the release any > >> further? We'd definitely like to incorporate any of your feedback before > >> we create an rc2 release. > >> > >> Thanks, > >> - Steve > >> > >> On 02/08/2018 01:24 PM, John D. Ament wrote: > >>> Well, before starting a new let's review the existing. I would like a > bit > >>> of time to review the whole release archive. > >>> > >>> What you mentioned is correct, effectively anything on the /dist/dev > should > >>> comply with the package naming scheme. You should consider whether or > not > >>> you want to put everything on /dist/dev (we tend to recommend only the > >>> source release goes there, to avoid confusion). When projects do stage > >>> other artifacts there, they should all be named the same way. > >>> > >>> I have a long standing disagreement with many IPMC members. I tend to > >>> follow the release requirements very closely and push back on an over > >>> assumption of the requirements. Most projects implement the > -incubating > >>> suffix as a part of the version #, but that's not required. So my > >>> interpretation is that maven distributions do not need to include > >>> -incubating. We have set this precedent before with Apache Groovy > where > >>> only the source release was staged and voted upon, the actual maven > central > >>> distribution omitted the -incubating and I'm in full support of that > >>> approach. > >>> > >>> John > >>> > >>> On Thu, Feb 8, 2018 at 12:58 PM Steve Lawrence <slawre...@apache.org > >>> <mailto:slawre...@apache.org>> wrote: > >>> > >>>> Multiple issues have been found with this release, so I am officially > >>>> canceling this vote. We would still ask for continued review of the > >>>> 2.1.0-rc1 release so that any issues found can be fixed in the > 2.1.0-rc2 > >>>> release. > >>>> > >>>> Thanks, > >>>> - Steve > >>>> > >>>> On 02/08/2018 11:30 AM, Steve Lawrence wrote: > >>>>> Hi all, > >>>>> > >>>>> I'd like to call a vote to release Apache Daffodil (Incubating) > >>>> 2.1.0-rc1. > >>>>> > >>>>> All distribution packages, including signatures, digests, etc. can be > >>>>> found at: > >>>>> > >>>>> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc1/ > >>>>> > >>>>> Staging artifacts can be found at: > >>>>> > >>>>> > >>>> > https://repository.apache.org/content/repositories/orgapachedaffodil-1000/ > >>>>> > >>>>> This release has been signed with PGP key 033AE661, corresponding to > >>>>> slawre...@apache.org, which is included in the repository's KEYS > file. > >>>>> This key can be found on keyservers, such as: > >>>>> > >>>>> http://pgp.mit.edu/pks/lookup?op=get&search=0x033AE661 > >>>>> > >>>>> It is also listed here: > >>>>> > >>>>> https://people.apache.org/keys/committer/slawrence.asc > >>>>> > >>>>> The release candidate has been tagged in git with v2.1.0-rc1. > >>>>> > >>>>> For reference, here is a list of all closed JIRAs tagged with 2.1.0: > >>>>> > >>>>> > >>>> > https://issues.apache.org/jira/browse/DAFFODIL-1864?jql=project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC > >>>>> > >>>>> For a summary of the changes in this release, see: > >>>>> > >>>>> https://daffodil.apache.org/releases/2.1.0/ > >>>>> > >>>>> Please review and vote. The vote will be open for at least 72 hours > >>>>> (ends on Sunday, 11 February 2018, 12 Noon EST). > >>>>> > >>>>> [ ] +1 approve > >>>>> [ ] +0 no opinion > >>>>> [ ] -1 disapprove (and reason why) > >>>>> > >>>>> My vote: +1 > >>>>> > >>>>> Thanks, > >>>>> - Steve > >>>>> > >>>> > >>>> > >>> > >> > > > >
