Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#17513 - [kernel26] continue kernel26 updates even if a new kernel hits [testing]
Attached to Project:
Arch Linux
Opened by Emmanuel (bkk_drs) - Tuesday, 15 December 2009, 11:47 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 31 October 2010, 06:31 GMT
Opened by Emmanuel (bkk_drs) - Tuesday, 15 December 2009, 11:47 GMT
Last edited by Tobias Powalowski (tpowa) - Sunday, 31 October 2010, 06:31 GMT
|
DetailsDescription: Current version of the kernel is very unlikely to be updated once a new kernel version has hit [testing]. Therefore, we could be several minor versions behind the latest stable kernel for weeks before the [testing] kernel goes [current].
To be clear, I am in no way complaining about packages being behind (this happens, for many different reasons and it is definitely not my point) but rather questionning [1] the process of totally stopping the [current] kernel development, which seems to be the standard. This is where this FR applies. I just think it would benefit all users to get all those precious bugfixes even if some shiny new kernel is already on the way... [1] it's the only word I could find, English is not my native language so I hope it doesn't sound too aggressive. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Sunday, 31 October 2010, 06:31 GMT
Reason for closing: Implemented
Sunday, 31 October 2010, 06:31 GMT
Reason for closing: Implemented
Testing is used for this, in the meantime please use abs for building updated outdated kernels.
It seems to me the right model for testing to be on its own branch, but this is a major structural change to the developer workflow.
I'm adding Allan, as he's the guy who has done the last few releases of devtools.
Who else should think about this issue?
The real question is, if there was a way around the issues, do any of the devs who package the kernel want to do the extra packaging? If not, then this is a non-issue.
For example, it would be nice to have a several-month run up to firefox, thunderbird, postgres, eclipse-- you name it-- which do significant major releases which tend to break some stuff.
I'm not suggesting that's reason enough to implement a whole system for it (or that anyone should), I'm just pointing out that I think one of the reasons devs don't do a smoother testing run up to major package upgrades is because the system doesn't provide an efficient way to do it.
That approach is called Debian/Ubuntu/Fedora... Bleeding edge is suppose to cause bleeding occasionally.
Such as system would actually make us *more* bleeding edge, as it we'd be able to test beta packages leading up to a major release in advance.
The KDE guys already manage this by setting up a temporary repo for their testing and not using trunk for their commits. Alternatively, openoffice provides a beta package. So there is already ways to do this.
Talking about "easier" approaches to handle this is a waste of time unless packagers are actually going to use it. We used to have an [unstable] repo for packaging beta release but it was unused so was removed. As far as I can tell, none of the kernel packagers have expressed interest in doing this extra packaging so...
Unless someone objects, I'll close this as "won't implement" on April 2010 bug day.