Yet another failed KDE release?

Duncan 1i5t5.duncan at
Thu Mar 28 09:29:14 GMT 2013

dE . posted on Thu, 28 Mar 2013 10:05:22 +0530 as excerpted:

> On Sat, Mar 23, 2013 at 5:10 PM, Duncan <1i5t5.duncan at> wrote:
>> (As another gentooer...) Not really.  No need for the live-9999 unless
>> you really want it, and that's not what Myriam was referring to.
>> What Myriam was suggesting (I know because I saw the same testing-team
>> invitation in the 4.10-pre-release announcements as well, with similar
>> but a bit more detailed wording) was to run the kde pre-release betas
>> and release-candidates and if desired, participate in the more
>> organized pre-release testing program kde's doing now with them.

> Thanks for that info about the pre release ebuilds, but here, in the KDE
> overlay I've --
> But I was expecting 4.11.
> Regardless, I'll upgrade to it next time. is current branch head.  9999 is live head. 
won't be shipped until kde upstream branches it, which as I explained 
(tho with a caveat that while I run the betas I haven't been running live-
branch so follow it a little less closely and may be slightly off on the 
specific timing) doesn't normally occur until about the time the rcs ship.

Back with the 4.9 pre-releases anyway, which was when I last noted the 
specific branch timing (from the gentoo/kde overlay git whatchanged 
logs), I was actually a bit surprised that the branch didn't split until 
as late as it did -- they kept 4.9 as trunk head longer than I expected 
them too, considering I was already running the 4.9 betas (4.8.80 or 
whatever).  I noted it at that point specifically due to a comment in one 
of the commits that the branch was about to split off 
upstream, but kde hadn't done it yet.  That (gentoo/kde overlay git) 
comment was in the context of some temporary change to the 9999-live 
builds since the 4.9 branch hadn't split yet, that was going to need 
reverted once the split had occurred.

As you can probably infer from the above, I track the gentoo/kde overlay 
git what-changed commit log religiously, every time I update.  So I see 
anything that gets a commit or comment there.  If the comment looks 
interesting and its on a core package, I'll git show that specific commit 
as well, to see what actually changed in the ebuild, what patches it now 
applies or no longer applies, etc.

I do the same thing with the other two overlays I follow, mozilla and 
x11.  And in the tree, I look specifically for -rX bumps, indicating a 
gentoo bump without a corresponding upstream version bump, and for many 
packages I'll run the changelog for that too, to see exactly why the 
gentoo package maintainers decided the -rX bump was necessary.

Of course for critical packages like portage, (where zac keeps a much 
better changelog than the simple ebuild changelog most packages get, 
because portage is a gentoo project so it's basically an upstream 
changelog as well), I'll check the changelog every time, loading the 
mentioned bug numbers and sometimes the specific code changes linked from 
them to see what's actually changing, and why.

And for openrc (and for pan, the news client I'm involved with upstream 
on), I wasn't happy with the level of detail in the normal gentoo 
changelogs, so I switched to the live-git-9999 version, and have a script 
that runs git whatchanged on the local copy of upstream's git repo, as 
well.  (I do something similar with the kernel too, but I have my own 
scripts handle it and don't use gentoo's kernel ebuilds at all.  Also, 
the kernel's rate of change is high enough that especially pre-rc1 I 
don't routinely follow every git commit as I do with openrc and pan, but 
I often will for later in the cycle, especially if I've reported and am 
following a bug in that cycle as I did for the current linux-3.9 cycle.)

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list