Dne 21. 04. 22 v 23:47 Jilayne Lovejoy
napsal(a):
Okay, so that is a bit more info than I probably needed...
Let me try to get back to the core of Miroslav's original question, which I'm simplifying to:
- when can package maintainer start using SPDX license ids in the license field of package spec files.
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- a policy change in the packaging guidelines (for which I began to prepare this PR___ ) but, practically speaking we also need:
- the new license data base that maps SPDX ids to Fedora ids to be up and running (David Cantrell is leading this work and making great progress)
I wish there was more transparency into this progress ...
- Fedora licensing documentation to be updated as well, preferably including a "human readable" table (like what's on the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently)
Now that I think of it - I'm not sure this needs to be tied to a release, necessarily? While that is tidy from a messaging standpoint, practically speaking, once the above tasks are completed, then package maintainers are free to start using SPDX ids in the license field of package spec files. Of course, this is easiest to start doing for new packages.
The other part of this is the question of how do we update all the existing packages (efficiently)
I think the short answer is "we won't". Generally, we never retrospectively update packages after
some guideline change. These changes are slowly adopted and
enforced just for new packages. Of course unless somebody
volunteer to update all the packages, which would be heroic
effort.
Vít
- some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
Does that sound about right?
thanks,
Jilayne
On 4/11/22 9:51 AM, Matthew Miller wrote:
On Mon, Apr 11, 2022 at 12:43:37PM +0200, Miroslav Suchý wrote:Generaly speaking, next version is +6 month to the date of the previous release.And, we're committed to keeping that from sliding around the calendar, so this means the deadlines for big changes are generally end of June and end of December every year. In this specific case, I think the relevant schedule points are actually the branches. Quick summary of the flow of Fedora Linux development for anyone for whom this isn't familiar... (skip to below if this is old hat!): Fedora development is split into "branches". You'll run into this in most projects which track different releases using version control, but there are different ways to do it. There is a branch called "rawhide", which is a reference to the theme song of the 1960s TV western — "rollin', rollin', rollin". And, indeed, Rawhide is a "rolling" branch, which means it is always open for changes, gets updates continuously, and goes forward from release # to relese # without any specific transition. If you follow Rawhide, you're always rolling forward. The configuration for Rawhide builds causes packages to be tagged with a release number, like `f36` or `f37` or whatever. You'll see this string appended to the end of the "release" field in every package. (Sidenote: shoving it in there rather than having a dedicated field is a gross hack, but one we've done for 20 years, so it feels like it's Supposed To Be Like That.) Right now, that string is `.f37` — any changes going in to Rawhide now are going to get to end users when Fedora Linux 37 is released. Every six months (in February and August), there is a branch event. (Not by magic, but done by the release engineering team.) At this point, a numbered branch is created. This August, that'll be `f37`. This branch starts as identical to Rawhide — and remember, the packages currently in Rawhide are tagged with `.f37`. At the same time, the version for Rawhide increments, so after the branch, Fedora Linux 38 development is officially started. Then, the F37 branch goes through the process of stabilization, beta release, final release. So we'll have four active branches for Fedora Linux. This August, they will be: Rawhide, F37, F36, and F35. One month (28 days, actually) after Fedora Linux 37 is officially made released, Fedora Linux 35 will be retired and the F35 branch closed. (Back to three active branches, until February, when the F39 branch happens.) So for this, with that branch coming up August 9th, I think we might consider an F38 change. As soon as that's approvided, and after that date, people can start making the changes in Rawhide. We can decide separately if we care about them also being in F37 or older. (It's probably nice to also allow that, but there's something to be said for a clean break, too.)
_______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
