Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

*: Collapse to a single note entry #566

Merged
merged 1 commit into from
Jan 11, 2018
Merged

Conversation

wking
Copy link
Contributor

@wking wking commented Dec 27, 2017

The XSD schema is currently buggy on this point, but the plural element name (<notes> vs. <note>) and maxOccurs in the XSD entry:

<element name="notes" type="tns:formattedFixedTextType" minOccurs="0" maxOccurs="1"/>

suggest that we expect only a single note entry (see also discussion here). This PR brings us back to a single <notes> entry for our licenses, preparing us for #452, which fixes the XSD schema.

The wxWindows change, I created paragraphs for the previously separate <notes> content.

For the GPL-family changes, I dropped the release-date/version <notes>, because:

  • Licenses with a release date in their <notes> entry had that same release date in the license title. I don't see a need to include that release date as unstrucutured information in two places, and the license title is clearly the more important location.

  • Whether the license is only or or-later is covered explicitly in the long name and implicitly in the new deprecation notice (e.g. as added in Add remaining deprecated licenses.  #552). Once we get explicit obsoleted-by markup (Add <obsoletedBy> to licenses and exceptions #392), those deprecation notices will become machine readable. So I don't think we need to call out the versioning again in the notes.

@wking wking force-pushed the single-notes-element branch from e1b407b to e690d0b Compare December 27, 2017 20:26
@wking
Copy link
Contributor Author

wking commented Dec 27, 2017

This also addresses (by removing the line entirely) all of the broken "or later) notes as pointed out by @goneall here.

@goneall
Copy link
Member

goneall commented Dec 27, 2017

3.1 release? A lot of changes to take in the day of the release and the tools currently merges the notes.

@wking
Copy link
Contributor Author

wking commented Dec 27, 2017

A lot of changes to take in the day of the release…

True, but a lot of these are fixing the "or later) typos. I can file a PR to just fix those, but this one is about as big and I think it's more helpful than the narrower change. I'd rather get the "or later) typos fixed somehow before we cut the next release.

And regardless of this PR, there's already a crazy amount of change going on right before a release that will apparently be a major version bump. Can we get an RC or something to give things a day or two to cool off?

@goneall
Copy link
Member

goneall commented Dec 27, 2017

@jlovejoy If you're OK with the notes updates, I'm OK including in the release.

I did read through the changes and it looks pretty straightforward.

@jlovejoy
Copy link
Member

I'm not okay with removing this info full stop. would need individual review.

@wking
Copy link
Contributor Author

wking commented Dec 28, 2017 via email

The XSD suggests (buggily) that we only want a single <notes> element
(more details on this in the previous commit).  And the information
contained in the <notes> sections I'm removing is redundant, because:

* Licenses with a release date in their <notes> entry had that same
  release date in the license title.  I don't see a need to include
  that release date as unstrucutured information in two places, and
  the license title is clearly the more important location.

* Whether the license is only or or-later is covered explicitly in the
  long name and implicitly in the new deprecation notice (e.g. as
  added in 55b6fc4, Update comments to reflect the new GPL license
  ID's, 2017-12-23, spdx#552).  Once we get explicit obsoleted-by markup
  [1], those deprecation notices will become machine readable.  So I
  don't think we need to call out the versioning again in the notes.

[1]: spdx#392
@wking
Copy link
Contributor Author

wking commented Jan 11, 2018

I've rebased this onto master now that #577 has landed the wxWindows change. I've also spun off the AGPL-3.0 change into a single-license PR with #597, in case folks want to continue with per-license review. I'll keep this branch up to date in case you want to merge all of these very similar changes in one go.

@jlovejoy
Copy link
Member

ok, so let me confirm I'm getting this in it's current form: the PR now updates all the deprecated licenses that ended up with two tags - one that has the deprecated info and one that has the old/original "notes" - the PR simply removes the latter for all, so that all that will remain is the notes related to deprecation. right?
and I agree - we should only have one notes tag with all notes contained therein.

@wking
Copy link
Contributor Author

wking commented Jan 11, 2018 via email

@jlovejoy
Copy link
Member

yeah, I'm really not in favor of removing notes that have been there all along (literally, in these cases since v1.0!!) and only was okay with it here as we ended up with two sets of notes and this leaves the more important one (about deprecation).
but I also may be biased to leaving stuff that has been there all along, b/c I was the one who put those notes there to begin with :-p
In any case, unless the notes are wrong or confusing, it's really not important to change them.

@jlovejoy jlovejoy merged commit 0e6a10d into spdx:master Jan 11, 2018
@wking wking deleted the single-notes-element branch January 11, 2018 22:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants