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