#2972 Change: SPDX Licenses Phase 2
Closed: Accepted a year ago by kevin. Opened a year ago by bcotton.

Second phase of transition from using Fedora's short names for licenses to SPDX identifiers in the License: field of Fedora package spec files. This phase addresses how to update the License: field for existing packages, including documenting more specific guidance on how to find licenses in a package.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.

REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.


I asked a question on fedora-devel just now whether to use pull requests or direct pushes to dist-git. But either way, I'm +1.

+1 for sure. Thank you for writing a detailed plan.

I asked a question on fedora-devel just now whether to use pull requests or direct pushes to dist-git. But either way, I'm +1.

We put that in the change proposal:

The conversion will be done in waves to minimize errors in automation (e.g., 100 packages in the first week, 200 packages in another week, ...). A pull request for the package spec file will be created as part of the conversion. If the maintainer does not respond to the pull-request within 14 days, the pull request will be merged by Change owners.

There is a discussion on devel@ mailing list indicating that people will prefer direct push to dist-git over creating pull requests. I would love to hear Fesco position on this.

If you publish an overall diff like this one https://github.com/hrnciar/add-setuptools-buildrequire/compare/c082a1a...a60a447 and give some room for feedback, I would not mind if this was pushed directly.

If you publish an overall diff like this one https://github.com/hrnciar/add-setuptools-buildrequire/compare/c082a1a...a60a447 and give some room for feedback, I would not mind if this was pushed directly.

Yes, I can publish this diff in advance.

Then yeah, a direct push would be much better.

Either with PR’s or via a direct push with a diff published ahead of time:

+1

After a week, the vote is

APPROVED (+6,0,-0)

Metadata Update from @bcotton:
- Issue tagged with: pending announcement

a year ago

Announced (and canceled tomorrows meeting since I don't see anything we need to meet for)

Metadata Update from @kevin:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.

Metadata