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(a)lists.fedoraproject.org
To unsubscribe send an email tolegal-leave(a)lists.fedoraproject.org
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@lists.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure