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@xxxxxxx> 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 --
>
> 4.10.49.9999
>
> But I was expecting 4.11.
>
> Regardless, I'll upgrade to it next time.
4.10.49.9999 is current branch head. 9999 is live head. 4.11.49.9999
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 4.9.49.9999 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: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
