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)
- 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) - 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.)