In ticket #1359, FESCo looked at the OpenH264 codec situation. In the corresponding meeting logs, FESCo asked for a user-friendly solution that could also fulfill distribution restrictions, while respecting the freely licensed source code. A group of folks have been discussing this:
https://fedorahosted.org/fedora-infrastructure/ticket/4857
The consensus plan at this point appears to meet FESCo requirements and concerns:
The tag in koji will be used just for this one package. when a build is done a releng ticket will have to be filed to have the package signed, tagged and the tag mashed, and whole repo made available to cisco.
If some other package like this comes along we will have to evaluate what to do then as this process will work just for this one package/situation. If Cisco provides some other codec under the same terms we could extend it but if we need to ship to someone else for distribution we would likely need extra tags.
Replying to [comment:2 ausil]:
Could this ticket be filed automatically? Possibly the system Sayan is working on for filing tickets automatically in response to cloud image build or test failures could be extended to cover this use case as well.
Replying to [comment:3 mattdm]:
Replying to [comment:2 ausil]: The tag in koji will be used just for this one package. when a build is done a releng ticket will have to be filed to have the package signed, tagged and the tag mashed, and whole repo made available to cisco. Could this ticket be filed automatically? Possibly the system Sayan is working on for filing tickets automatically in response to cloud image build or test failures could be extended to cover this use case as well.
Possibly, but I would consider that squarely in the "nice-to-have" category. There is no reason to hold anything else up for that functionality.
Replying to [comment:4 jwboyer]:
Agreed. I just don't want it to then ''later'' be held up with every build if the process is cumbersome.
The tag in koji will be used just for this one package. when a build is done a releng ticket will have to be filed to have the package signed, tagged and the tag mashed, and whole repo made available to cisco. If some other package like this comes along we will have to evaluate what to do then as this process will work just for this one package/situation. If Cisco provides some other codec under the same terms we could extend it but if we need to ship to someone else for distribution we would likely need extra tags.
Agreed that any future package would need to be evaluated. This ticket isn't meant to provide any sort of blanket approval. But it might make sense to have something like f22-exclude -> f22-exclude-cisco -> f22-exclude-cisco-openh264 inheritance.
Replying to [comment:5 mattdm]:
Possibly, but I would consider that squarely in the "nice-to-have" category. There is no reason to hold anything else up for that functionality. Agreed. I just don't want it to then later be held up with every build if the process is cumbersome.
We can ask Sayan about that obviously. In the meantime, I think the expectation is rebuilds aren't going to be necessary so often as to be a short-term issue.
No other updates from FESCo here -- does this mean our solution is acceptable?
There was no quorum at least weeks meeting, so it's held over until this week.
Proposal was approved at today's fesco meeting.
openh264 package review request: https://bugzilla.redhat.com/show_bug.cgi?id=1285338
Login to comment on this ticket.