Transfer jenkins CI tool tap2junit into Node.js org #413

SGTM

+1

+1

I have transferred the project ownership per request in the thread.

@jbergstroem thanks!

Re-opening because there is a problem with the license for tap13.py in the tap2junit modjule.

policy is: https://github.com/nodejs/admin/blob/master/GITHUB_ORG_MANGEMENT_POLICY.md#repositories

Any repository created under the Node.js GitHub Organization is considered to be a project under the ownership of the Node.js Foundation, and thereby subject to the Intellectual Property and Governance policies of the Foundation.

nodejs/tap2junit#12 (comment) describes the copyright ownership.

Apparently the openjs foundation doesn't allow GPL, don't have a link to that yet.

So, options?

• rewrite in js, any takers? :-)
• move back to jbergstroem's personal account, but leave cclauss and maybe some other tsc or build group member with admin access to the repo, so @jbergstroem still gets help maintaining it, but it doesn't run afoul of the foundation IP policy
• ask the foundation for an exception
• ask redhat to change the license, @danbev how hard would that be? the file in question is just this one: https://github.com/nodejs/tap2junit/blob/master/tap2junit/tap13.py
• or maybe there is another python library somewhere that knows tap? or another tool?

Sorry for the legal complications :-(

if it's just a tap formatter, there's tons of them on npm. does it have to be python?

Nope. Python is not essential. A rewrite in JS is cool as long as it generates identical output.

Should we be using https://www.npmjs.com/package/tap @isaacs or https://wiki.jenkins.io/display/JENKINS/TAP+Plugin

@rvagg Wrote me that:

iirc we did tap2juint because it reduces the amount of plaintext data jenkins caches in memory, juint gets stored properly in its xml structures .. or something like that .. it seemed to help performance and storage problems, but maybe things are different these days and this was all before we offloaded a lot of jenkins work to the jenkins workspace servers (we used to use the jenkins master to run everything, now we spread it out).

This Apparently the openjs foundation doesn't allow GPL is not accurate. What I mentioned is that we might need to ask for the ok if its not one of the ones explicitly allowed by the Foundation policy. (I'm trying to find the Node.js Foundation IP Policy to check).

On npm there are: https://www.npmjs.com/package/tap-junit, https://www.npmjs.com/package/tap-xunit and likely many more. We might not need a rewrite even.

Can't find a link to the Node.js policy and done for today. Will try to find it early next week.

if it's just a tap formatter, there's tons of them on npm. does it have to be python?

It does not have to be Python. I believe Python was chosen because all of our build systems have it as it required to build Node.js.

Reasons for it not to be Node.js:

• Apart from running the linter jobs we avoid having any version of Node.js pre-installed on the build systems to avoid any contamination of the test results.
• It's generally not a good idea to have the framework run with the Node.js binary we build either as you still want test results if the binary you have built is broken somehow.

@nodejs/tsc Consider getting your opinion in early if you already have it:

👍 = relicense
😄 = exception
🎉 = I do not have an opinion on this and do not expect to have one--make a decision without my input
❤️ = I do not have an opinion on this but I expect to have one after discussion
🚀 = some other option not listed above

I had misunderstood when I quickly reviewed the repo thinking that tap13.py was a vendored dependency, not the part of the repo itself.

👍

From a quick review it seems like all folks who have contributed to the repo are Node.js collaborators... so my preference would still be relicensing.

The only GPL code in the repo is tap13.py, and I don't see any sign Josef is a Node.js collaborator, https://github.com/nodejs/tap2junit/blob/master/tap2junit/tap13.py#L17

I emailed him, if he is willing and able to relicense, that's great, I'll ping back if he responds, or perhaps he'll join this conversation (I couldn't find a GH ID).

The foundation has an IP and license policy which explicitly states that we cannot have GPL code without an exception... and honestly if there is any path towards avoiding that exception I think we should do so.

Other path depends on a question I don't know the answer to:

@mhdawson @nodejs/build -- is tap2junit used ONLY to convert the test output of nodejs/node?

This is important, it effects what paths we can take. I'll describe what I think either path would be to save time while above question is unanswered.

If its used only for node's test output, then the path is this:

1. find a js tap2junit tool that works and vendor it into nodejs/node
2. add it to the relevant nodejs/node build targets (test-ci, at least, perhaps others)
3. find all jenkins jobs using tap2junit, and update the jobs to not do that

If its used outside of a nodejs/node build, then it must be installed globally, and can't be a js tool:

1. find a python tool that does what tap2junit does
2. modify the ansible files for every one of our platforms to install the new tool and stop installing tap2junit
3. run ansible on all of our machines
4. find all jenkins jobs using tap2junit, and update the jobs to use the new tool

For comparison, the steps if OpenJS Foundation rejects the licensing but we keep using tap2junit:

1. Move tap2junit out of github.com/nodejs/
2. Setup Travis again against the new location

If the Foundation accepts tap2junit being where it is now, steps are:
0. N/A

EDIT: and if tap2junit/tap13.py is relicensed from GPL, we only have to

1. update the tap2junit repo to state the new license

The source of my "ask the foundation to accept this as GPL" suggestion should be pretty clear, it minimizes effort.

Strategically, I'd rather that the conversion tool was in js, and vendored into nodejs/node, and would be quite happy for someone to step up and volunteer to do the work.

@cclauss found @rajcze --- Josef, see conversation above, are you willing or able to relicense https://github.com/nodejs/tap2junit/blob/master/tap2junit/tap13.py from GPL? I understand licensing is your choice, so absolutely no hard feelings if you do not.

I think it is only used is tap2junit used ONLY to convert the test output of nodejs/node. @jbergstroem could you confirm as I think you'd best know if it was used in some other way.

@sam-github If it was just me, re-licensing would not be an issue, but I'll need to check with Red Hat's legal to check what I can do here, since the copyright/ownership/whatever laws are just plain weird in general, and I'm not an expert on how the Czech/American laws interact here.

Do you have a list of acceptable licenses?

Anyway, as far as I understand (and this is obviously not that much) the main problem here is having the tap13.py file in this source tree, and it could be just installed as dependency using pip during provisioning of the CI system. If the code is not re-license-able, I'll be more than happy to work with you on updating the code with any changes needed, or give some of you commit access to the source repo. Would that be an option?

Anyway, as far as I understand (and this is obviously not that much) the main problem here is having the tap13.py file in this source tree, and it could be just installed as dependency using pip during provisioning of the CI system.

As mentioned previously, the rationale for doing so was because some nodes lack setuptools/pip and it was non-trivial to add it. This may have changed.

@rajcze I really appreciate your openness to trying to sort this out. I suspect anything other than GPL and fringe stuff like WTFPL are probably fine. We mostly have MIT licenses across our code bases, fwiw. I defer to Michael for specifics.

@mhdawson Any idea what licenses are OK?

@jbergstroem pip is available on the nodes I've seen, but I haven't seen them all, so can't speak to the issues. Anyhow, splitting tap13.py out doesn't really help --- then we'd have a GPL tap13 being maintained in an external repo, and nodejs/tap2junit over here, which doesn't strike me as less maintenance than having a single tap2junit maintained in an external repo. But, I am not a python dev, and I defer to the folks who are doing the work how to arrange this.

The basic goal here is to get out of the situation where @jbergstroem or @rajcze or @cclauss are personally responsible for maintaining this tool forever, and to instead make it possible for the nodejs project to maintain it -- make code changes, publish it, add new publishers and maintainers if necessary, merge PRs, etc. For github perms and CI (if needed in the future), etc., its easiest to do this by bringing it into the github.com/nodejs org. For pypi publish, I assume it doesn't matter where the source is.

Another option for the majority (only?) use-case of testing nodejs/node is to have the test runner just output junit xml in the first place and avoid the need for conversion. I've got a WIP PR that attempts to do so: nodejs/node#29840.

@sam-github @MylesBorins turns out, I can easily do Apache Software License 2.0, so the code in the source repo https://bitbucket.org/fedoraqa/pytap13/src/develop/pytap13.py is hereby licensed with ASL2.0

If there's anything I could help with, please let me know. I have some hours to spare that can be put into FOSS projects.

We could sync with Py3 changes in https://github.com/nodejs/tap2junit and then make a new release on https://pypi.org/project/tap2junit under Apache license.

The transfer was done. If there are other things to do, please open a new issue.