| Summary: | Qt 5.6.1 stabilisation request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michael Palimaka (kensington) <kensington> |
| Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | flyser42, gentoo, lukas, xms-00 |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 584832, 585292, 585386, 588776 | ||
| Bug Blocks: | 586166 | ||
| Attachments: |
qt-5.6.1-stable
stable-list-v2 stable-list-v3 |
||
Created attachment 437902 [details] stable-list-v2 Added qtserialport (obsoletes bug 577074) and qtwebengine (I'm sure it will be needed). Created attachment 438594 [details]
stable-list-v3
Retargeting qtdeclarative to -r1.
amd64/x86 done I don't think we're done yet. The idea was to stabilize 5.6.1 on amd64/x86 only, mainly because it was needed to stabilize a new version of KDE/Plasma. Other arches were meant to target a later 5.6.x patch release, or even skip 5.6 altogether and move directly to 5.7.x Obviously I'm not opposed to stabilizing 5.6.1 on other arches, I just don't want to overload arch teams. Be advised that we'll probably start another Qt5 mass stabilization in about 3 months from now. (In reply to Davide Pesavento from comment #5) > The idea was to stabilize 5.6.1 on amd64/x86 only, mainly because it was > needed to stabilize a new version of KDE/Plasma. Other arches were meant to > target a later 5.6.x patch release, or even skip 5.6 altogether and move > directly to 5.7.x > > Obviously I'm not opposed to stabilizing 5.6.1 on other arches, I just don't > want to overload arch teams. Be advised that we'll probably start another > Qt5 mass stabilization in about 3 months from now. The fundamental ideas at play here are to * never leave architectures behind, and * leave those decisions up to the architecture teams. When you start to allow yourself to think that some architectures are more important than others, you might as well give up. (In reply to Jeroen Roovers from comment #6) > The fundamental ideas at play here are to > > * never leave architectures behind, and why "behind"? There's nothing wrong in staying on 5.5.1, it's not old or "behind" at all... most major distros still ship with 5.5.1 or even older versions... > * leave those decisions up to the architecture teams. Agreed, we should've asked, but we tried that approach in the past and it very rarely worked. > When you start to allow yourself to think that some architectures are more > important than others, you might as well give up. That was definitely not the rationale behind this "decision" (although we never really decided or even discussed about the choice of target arches, we simply moved forward with kensington's initial proposal, maybe he can provide more reasons for it). As I explained in my previous comment, AFAIK this "restricted stabilization" was driven by the needs of the KDE team, which were (and still are) irrelevant to arches other than amd64/x86. (In reply to Davide Pesavento from comment #7) > That was definitely not the rationale behind this "decision" (although we > never really decided or even discussed about the choice of target arches, we > simply moved forward with kensington's initial proposal, maybe he can > provide more reasons for it). > As I explained in my previous comment, AFAIK this "restricted stabilization" > was driven by the needs of the KDE team, which were (and still are) > irrelevant to arches other than amd64/x86. Correct, the primary reason for this stabilisation is because we require it for KDE. KDE is only stable on amd64 and x86 because they are the only architectures for which I stabilise (nobody else seems interested in taking care of it). It therefore did not seem necessary to burden other arch teams with this particular stabilisation. (In reply to Jeroen Roovers from comment #6) > The fundamental ideas at play here are to > > * never leave architectures behind, and > * leave those decisions up to the architecture teams. This only works if arch teams respond in a timely manner, which they currently often do not. For example, see the numerous other stabilisation requests outstanding for multiple months. Please do not take this as an attack on arch teams - their work is much appreciated. However, we do need to be realistic - arch teams (even for popular archs such as amd64) cannot keep up with current demands. Stable for HPPA PPC64. arm stable ppc is in CC but the list is only for amd64 and x86. Can I have a list for ppc? thanks ppc stable. Closing. Stabilization of the following ebuilds is still needed:
dev-qt/pixeltool-5.6.1 hppa ppc64
(dev-qt/pixeltool-5.5.1-r1 is stable for these architectures.)
dev-qt/qtx11extras-5.6.1 ppc
(dev-qt/qtx11extras-5.5.1 is stable for this architecture.)
Stable for HPPA PPC64. ppc stable. Closing. |
Created attachment 437826 [details] qt-5.6.1-stable If no issues come up, it would be really nice to have Qt 5.6.1 stable for use Plasma 5.6.5. I suggest targeting just amd64/x86 for this one.