Re: 3.3 release update, meeting minutes

Gary O'Neall


From: J Lovejoy <opensource@...>
Sent: Friday, October 12, 2018 10:17 AM
To: Gary O'Neall <gary@...>
Cc: Steve Winslow <swinslow@...>; SPDX-legal <spdx-legal@...>
Subject: Re: 3.3 release update, meeting minutes


Thanks Gary, Steve - in process of updating now and adding text files.


Gary - I followed the workflow instructions you added. Looks good. One question I had was - do we need to do any “special” formatting to the text file? Or just dump the text and maybe make a few line breaks so it’s somewhat readable?  We had some specific spacing guidelines in the past (pre-XML days), but I don’t think those apply any more - right?

[G.O.] We should be able to just dump the text since the tests should ignore any whitespace.


As for the workflow document, where do we ultimately want to store that?  Steve and I had made some updates to the Contributing document and corresponding changes elsewhere - I think the goal at that point was to get rid of the web page on ‘Request a New License” and just use the Contributing doc in the Github repo. Thus, when we are ready, we’d add this info to that page? This will make it kind of long - we could consider having a separate page as well, I guess??

[G.O.] Either addition a separate doc to the repository (e.g. or adding it to the existing contributing would work.  I lean towards a single document just to make it easier to maintain.


We probably want to keep an external web page for non-SPDX legal team contributors that would just cover adding the license using the online app to submit a new request.  This page wouldn’t cover how we actually pull it into the repo – just submitting the request. 



On Oct 11, 2018, at 6:24 PM, Gary O'Neall <gary@...> wrote:


I took a look at the automated build failures under #1 below.

These are caused by the missing license text.


I think it would be good for the tooling to generate the license text, but it currently does not do this (we didn’t think about that need until just now).  I’m struggling with the workflow/user interface for how this can be accomplished.  


For this release, we can manually upload the license text.


I just updated the workflow document to include a suggested approach.  Jilayne – if you could test this out and see if it works.


I also noticed that the branch used for these pull requests are behind the commits in the license-list-XML repo.  I think if you check the “update “ box in the tool, it will update the repository for you.


As far as the stale files - I’m not sure this is the best approach (in fact, I’m pretty sure it is not the best approach)  you can the files you don’t want to change from the license-list-XML repo master branch and they should show up as unchanged in your PR.  Others more github savvy than me can advise on the better approaches.



From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Steve Winslow
Sent: Thursday, October 11, 2018 4:00 PM
To: J Lovejoy <opensource@...>
Cc: SPDX-legal <spdx-legal@...>
Subject: Re: 3.3 release update, meeting minutes


Hi Jilayne, for #1 I'll take a look at the XML files and will add comments in the PRs. 

But, someone else with more Git / Github skills than me may need to weigh in on separating out files per your second bullet point in #1, I'm not sure how to handle that...




On Wed, Oct 10, 2018 at 6:00 PM J Lovejoy <opensource@...> wrote:

Hi all,


We are a bit late on the 3.3 release and need some help getting it over the line. We did a good job of prioritizing what to finish up (preferably this week) for 3.3 and labeling anything we didn’t get to for 3.4 on the last call. Meeting minutes posted here:


Here’s what’s left to be done:


1)  adding OGL-UK licenses (3 versions) - I have created the XML files via the XML editor and created PRs for each. 


Need help with the following:

- someone to review each, both in terms of text and XML tags

- 3.0 combined itself with some old file I had in there, no idea how that happened, can someone help me separate?

- also note, the XML editor upload function does NOT create the .txt file - so we’ll need to do this separately and add to Documentation (I’ll make a note there now) - is this something the tooling should or could do?

- the checks are also failing on these, but maybe that is due to the missing .txt file?


2) - PR for copyleft-next-0.3.1

- can someone else review and sign off, so we have two sets of eyes?

- still showing failed checks, but I think that issue has been resolved since and it will be ok to merge?


I think those are the key items, but for a couple other tasks I have which I’ll deal with otherwise,






Steve Winslow
Director of Strategic Programs
The Linux Foundation


Join { to automatically receive all group messages.