dE . posted on Thu, 28 Mar 2013 10:05:22 +0530 as excerpted: > On Sat, Mar 23, 2013 at 5:10 PM, Duncan <1i5t5.dun...@cox.net> 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.