migrate to upstream release/coreNN branch

Bug #2046871 reported by You-Sheng Yang
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
backport-iwlwifi-dkms (Ubuntu)
In Progress
High
You-Sheng Yang

Bug Description

In the past we're tracking the upstream master branch and create new builds upon the lastest HEAD available at the moment. This, however, creates ambiguity for tracking backport-iwlwifi development & releases, because the upstream puts more emphasis on the coreNN releases instead of the development branch master when investigating support of new hardware models.

Currently backport-iwlwifi-dkms/noble, versioned 11510-0ubuntu1, is built from upstream revision 11520, which maps to upstream git commit 41e354fb5f32 that is a few commits behind the release/core84 HEAD commit 6d8764841123 (revision 11517). To migrate to release/core84 branches, it follows we will have to rebase our work to release/core84 HEAD and to fix debian version with an additional epoch. The proposed new version nubmer is 1:84.<rev>-git<hash>-0ubuntu1.

You-Sheng Yang (vicamo)
summary: - new upstream release core84
+ migrate to upstream release/coreNN branch
You-Sheng Yang (vicamo)
description: updated
Revision history for this message
You-Sheng Yang (vicamo) wrote :

Proposed debdiff, versioned as 1:84.11517-git6d876484-0ubuntu1. New version orig tarball in https://launchpad.net/~vicamo/+archive/ubuntu/ppa-2046871 .

Need sponsor.

Changed in backport-iwlwifi-dkms (Ubuntu):
status: New → In Progress
importance: Undecided → High
assignee: nobody → You-Sheng Yang (vicamo)
Revision history for this message
Lucas Kanashiro (lucaskanashiro) wrote :

Thanks for the patch @vicamo!

The proposed changes look good, but the epoch addition is always subject of some discussion. I brought this bug to the #ubuntu-devel IRC channel and got some comments from people there that I'd like to share with you here.

First, we need to understand the upstream versioning schema, do you think it might change again in the future? It seems to me that it is not quite stable, and once we add a epoch it might become a bigger problem in the future if that happens.

Considering that we need and want to add a epoch, maybe it is a better idea if we use 1:0~84 instead of 1:84. So if for some reason upstream starts to use a lower version we do not need to bump the epoch.

There is no process in Ubuntu to add epoch to a version string in a package, but I believe it is a good idea to brought this to a bigger audience before uploading. If you feel comfortable I'd recommend to email ubuntu-devel to ask for advice and get a consensus from more developers.

Revision history for this message
Julian Andres Klode (juliank) wrote :

I concur that 1:0~84 would be a lot nicer but I also don't really see an upstream project versioning from the description, just random branches and commits in them. Could also use 0~~ or something to make it even smaller until upstream has a release number actually.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Unsubscribing sponsors until comments #2 and #3 are replied to by the submitter.

Revision history for this message
You-Sheng Yang (vicamo) wrote :

> First, we need to understand the upstream versioning schema, do you think it might change again in the future?

Not as far as I know.

We should have use this coreNN release scheme in the very beginning, but at the time we were not sure whether we'll need backport-iwlwifi-dkms at any serious production level. This coreNN scheme has been used by Intel for years, and during these years coreNN is how they used to communicate with related parties, and has been recommending Ubuntu to adopt this change to fit their release model more. Therefore I think we have good reason to believe it will continue to be coreNN in the foreseeable future.

> maybe it is a better idea if we use 1:0~84 instead of 1:84

That's doable and also easy to understand. I'll redo the debdiff.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.