In preparation, please avoid talking here.
Created attachment 365020 [details] kde-4.11.4-stable-list v1 First draft, please only add NEEDED packages to the list.
I just want to remember that _I_ will cc kde-stable when I guess is the time. Thanks
(In reply to Agostino Sarubbo from comment #2) > I just want to remember that _I_ will cc kde-stable when I guess is the > time. Thanks Yes, and you please dont change keywords until all arches stable. We the kde herd will do it in one commit.
(In reply to Johannes Huber from comment #3) > Yes, and you please dont change keywords until all arches stable. We the kde > herd will do it in one commit. the test is not done at the same time for all arches. So there will be some delay between the amd64 stabilization and the ppc64 stabilization.
Maybe we should target 4.11.5 to reduce workload on arch teams?
Where does discussion take place regarding stabilization process? I ask b/c it seems from the outside that something is being done differently than in the past, and I wonder if it results in an inefficient release process. For example, why should amd64 have to wait for ppc64? I've been using Gentoo and KDE since 3.1 or so, and I've really felt like stabilization of KDE 4.10 and 4.11 has been way too slow. Thanks - again, I understand this is not the place for this discussion, though I would be interested to know where such a discussion would be appropriate. -Rick
(In reply to rick vernam from comment #6) > Where does discussion take place regarding stabilization process? > I ask b/c it seems from the outside that something is being done differently > than in the past, and I wonder if it results in an inefficient release > process. > For example, why should amd64 have to wait for ppc64? > I've been using Gentoo and KDE since 3.1 or so, and I've really felt like > stabilization of KDE 4.10 and 4.11 has been way too slow. > > Thanks - again, I understand this is not the place for this discussion, > though I would be interested to know where such a discussion would be > appropriate. > -Rick Hi, If stabilisations have seemed a bit delayed, it is probably due to the very high workload of the arch teams. In this case, there are still unresolved bugs marked as blocking this bug. Regarding amd64 waiting for ppc64, it is a lengthy process making changes to the entire SC. In the past, sometimes we have changed the keywords stable all at once after all arch teams were finished in order to avoid that repeated effort.
(In reply to Michael Palimaka (kensington) from comment #5) > Maybe we should target 4.11.5 to reduce workload on arch teams? Yes, is fine.
If we don't have regressions since the stabilization of 4.11 resolved in 4.11.5 I'd say to skip any other 4.11 stabilization and go ahead for the 4.12.
Please do not skip 4.11.5 stabilization, several regressions were fixed: https://bugs.kde.org/show_bug.cgi?id=328182 https://bugs.kde.org/show_bug.cgi?id=328262 https://bugs.kde.org/show_bug.cgi?id=328296 https://bugs.kde.org/show_bug.cgi?id=328221 Full list of bugs fixed in 4.11.5: https://bugs.kde.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2013-06-01&chfieldto=Now&chfield=cf_versionfixedin&chfieldvalue=4.11.5&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=
creffett said he wants to target 4.11.5
OK, I can understand the usual no talking there! That's true project management. OK, I acknowledge I'am some kind of overpaid old crow! However : Reading about the workload on the arch teams is becomming some recurrent argument. To this regard : Do you *really* mean that picmi was/should have stand as a blocker for kde stabilization ???? When I read the package stabilization list, I just cannot trust it. What does packages such as amor, kiten, kteatime and kyriads of the kind are doing in such a list ? kde-base you said ? really ? I you actually want to speed up stabilization processes and reduce the load on the arch teams, please bring back some basic project management in there which, I make no doubt about this, would immediately start slimming down this list.
(In reply to Eric F. GARIOUD from comment #12) > Do you *really* mean that picmi was/should have stand as a blocker for kde > stabilization ???? > > When I read the package stabilization list, I just cannot trust it. > What does packages such as amor, kiten, kteatime and kyriads of the kind are > doing in such a list ? kde-base you said ? really ? > > I you actually want to speed up stabilization processes and reduce the load > on the arch teams, please bring back some basic project management in there > which, I make no doubt about this, would immediately start slimming down > this list. Yes kde-base is the normal category that we stabilize, as it is the set of packages which belongs to a KDE SC release. There is no alternative and please stop talking here.
Created attachment 369584 [details] kde-4.11.5-stable-list v1 Updated stable list for 4.11.5. No blockers remain. Eric, if you would like more information regarding our stabilisation process or would like to discuss the issue further, please feel free to join us in #gentoo-kde or or post to the gentoo-desktop mailing list.
KDE stable testers, do your magic!
amd64 stable
amd64 looks stable here also.
Installed/tested kde on both amd64 and x86. Works fine for me.
Upgrade (amd64) from kde 4.11.2-r2 was smooth. Daily use since Friday and no issues.
(In reply to jim.sublette@gmail.com from comment #17) > amd64 looks stable here also. (In reply to Sam I am from comment #19) > Upgrade (amd64) from kde 4.11.2-r2 was smooth. Daily use since Friday and no > issues. Gentlemen, PLEASE. amd64 has already been marked stable. (Hasn't ago told you anything about stable testing? :o) You are just adding noise.
x86 stable, thanks guys