diff options
-rw-r--r-- | meeting-logs/kde-project-meeting-log-20110602.txt | 553 | ||||
-rw-r--r-- | meeting-logs/kde-project-meeting-summary-20110602.txt | 44 |
2 files changed, 597 insertions, 0 deletions
diff --git a/meeting-logs/kde-project-meeting-log-20110602.txt b/meeting-logs/kde-project-meeting-log-20110602.txt new file mode 100644 index 0000000..19ab44d --- /dev/null +++ b/meeting-logs/kde-project-meeting-log-20110602.txt @@ -0,0 +1,553 @@ +<tampakrap> ok let's start +<tampakrap> !herd kde +<willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, patrick, reavertm, +spatz, tampakrap +<tampakrap> roll call +<dilfridge> 1 +<alexxy> 2 +-*- dilfridge hears bonsaikitten munching in the distance +<ABCD> 3 +<tampakrap> +http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=Documentation/maintainers/meetings/meeting-2011-05 +<tampakrap> agenda ^^ +<tampakrap> jmbsvicetto: here? +<tampakrap> until he shows up, anyone familiar with the status of 4.7 so far? +<dilfridge> nope +<jmbsvicetto> here +<jmbsvicetto> so, 4.6.80 +<tampakrap> can you give us a brief summary of the betas please? +-*- alexxy here +<jmbsvicetto> I think I got most of kdebase, kde-utils, kde-graphics, +kde-games and kde-network working +<jmbsvicetto> alexxy then bumped the rest +<jmbsvicetto> about the status of the upstream tree / tarballs: +<alexxy> most problematic is kdebindings +<jmbsvicetto> I think no package is working +<jmbsvicetto> status of upstream tree / tarballs: +<dilfridge> about kdebindings... I vaguely remember an e-mail longtime ago +when kde-4.7 was started, where the new split was explained +<tampakrap> i recall that too +<jmbsvicetto> kdebase was split on 3 tarballs - kdebase, kde-runtime and +kde-workspace +<tampakrap> do you think we should rename our metas? +<jmbsvicetto> the info is available in the readme.modularization of the +tarball +<dilfridge> http://old.nabble.com/kdebindings-split-td30617636.html +<jmbsvicetto> http://paste.pocoo.org/show/399690/ +<jmbsvicetto> The question is will they stick to the names or not +<jmbsvicetto> at this point I think they haven't made up their minds yet +<tampakrap> but they have the repos ready +<tampakrap> don't they follow their repo naming schema? +<jmbsvicetto> alexxy: ^^ +<jmbsvicetto> I'm not sure they're doing it consistently +<dilfridge> >:| +<jmbsvicetto> for example, smoke (which I think is a single repo) was split +into 3 tarballs +--> Skiarxon (~quassel@ppp091138207078.dsl.hol.gr) has joined #gentoo-meetings +<jmbsvicetto> smokegen, smokeqt, smokekde +<tampakrap> sec +<dilfridge> like in the deptree +<tampakrap> can i have a list of the bindings tarballs? +<jmbsvicetto> I'm not sure as I didn't had the time to go after the repos. I +based my work in the existing tarballs and on the live ebuilds - which were in +very good shape!!! +<tampakrap> i'd like to compare with the repos right now +<jmbsvicetto> I can give you the tarballs names for them. I still think +there's a missing krosspython, but after 3 emails I've yet to get a proper +reply +<tampakrap> i follow the list, yes +<jmbsvicetto> so as I said: smokegen, smokeqt and smokekde +<ABCD> jmbsvicetto: I'd hope the live ebuilds were in good shape -- I use them +myself :) +<tampakrap> here are the repos for referrence: +https://projects.kde.org/projects/kde/kdebindings +<tampakrap> smoke is consistent so far +-*- alexxy also use live =) but now gonna switch to betas +<jmbsvicetto> perlqt, perlkde, qtruby, qyoto, korundum, kimono and pykde4 +<jmbsvicetto> tampakrap: ok, then the live ebuilds need to be updated as well +<dilfridge> perl is consistent +<jmbsvicetto> should we pkgmove smoke to smokegen, or just add a block on +smokegen to smoke? +<tampakrap> everything is checked +<ABCD> block, because we're not changing :4.4 and :4.6, I'd think :) +<jmbsvicetto> the tarballs are consistent to the names in the +README.MODULARIZATION file +<dilfridge> ruby is consistent +<tampakrap> ABCD: only 4.7 is involved +<tampakrap> dilfridge: everything is +<tampakrap> :) +<ABCD> tampakrap: pkgmove moves *every* version unconditionally +<jmbsvicetto> so, to get kdebinding we need to start by spliting smoke. I +wasn't sure if the live ebuild was ok or not, so I didn't start that +<ABCD> (you *cannot* use a versioned atom in that spot) +<tampakrap> so, we follow upstream's repos for kdebindings since the tarballs +and repos, do we all agree? +<dilfridge> yes +<tampakrap> ABCD: correct, i got you wrong +<ABCD> yes +<jmbsvicetto> seems a good idea +<dilfridge> and I'm for blocker, not move +<alexxy> also seems we need something to do with kross* modules +<jmbsvicetto> If no one beats me to it, I'll work on it this weekend +<tampakrap> blocker is one way +<tampakrap> alexxy: what about them? where are the tarballs? :) +<jmbsvicetto> tampakrap: no tarball for krosspython +<dilfridge> mia +<alexxy> tampakrap: dunno =) +<tampakrap> if you want, prepare the live ebuilds then +<jmbsvicetto> tampakrap: the README mentions the pykde4 tarball, but it no +longer includes any code +<tampakrap> i believe they'll follow the repo names as the rest of the module +<dilfridge> this is about the only really crucial piece of binding because of +plasma... +<tampakrap> jmbsvicetto: sorry? +<tampakrap> where is the pykde4 code then? +<jmbsvicetto> sorry, I'm mixing tarballs +<tampakrap> ok, we're done with bindings +<tampakrap> jmbsvicetto: give us the modules that are monolithic please +<tampakrap> kdepim is one of them, what else? +<jmbsvicetto> kdegames +<alexxy> kdeutils +<alexxy> kdenetwork +<tampakrap> those haven't migrated yet correct? +<jmbsvicetto> kdenetwork +<alexxy> kdemultimedia +-*- tampakrap checks +<alexxy> kdetoys +<ABCD> kate (kinda), kde-baseapps, kde-runtime, kde-workspace, +kdeaccessibility, kdeadmin, kdeartwork, kdegames, [kdelibs], kdemultimedia, +kdenetwork, kdepim, kdeplasma-addons, kdesdk, kdetoys, kdeutils, kdewebdev +<alexxy> kdesdk +<tampakrap> kdegames, kdeutils, kdenetwork, knemultimedia, kdesdk are still in +svn +<jmbsvicetto> oh yeah, kate was also fun +<tampakrap> also kdetoys, kdeaccessibility, kdeadmin, kdeartwork +<jmbsvicetto> kate is now the name of the module, so I had to update the +eclass as we hadn't "predicted" that case and the src_unpack was failing +<tampakrap> so, i'd say let's keep them as they are +<jmbsvicetto> kdelibs is something we need to watch out. There's some doubt +whether it'll be split kdelibs and kdelibs-experimental +<tampakrap> one by one please +<tampakrap> don't mix them +<tampakrap> kdelibs-experimental is not going to be a tarball +<tampakrap> it is an experimental repo +<jmbsvicetto> yes, but kdelibs-4.6.80 had a dep on libs from it. Dirk ended up +"smashing" it all together in kdelibs-4.6.80 +<ABCD> ...one that's currently *required* by kdelibs proper +<ABCD> yeah +<tampakrap> which was a mistake +--> devurandom (~devu@unaffiliated/devurandom) has joined #gentoo-meetings +<jmbsvicetto> there was a discussion in the ml whether that dep was a mistake +or not. I don't recall the conclusion +<tampakrap> so, about the ones that haven't migrated yet +<tampakrap> anyone knows if this will be done during 4.7? +<ABCD> it's likely +<tampakrap> causing more mess? +<ABCD> of course :) +<tampakrap> we're fsck'd then +<tampakrap> oh well +<dilfridge> probably with kde-5.0 they'll move to mercurial... +<tampakrap> anyway +<tampakrap> lol +<tampakrap> what about the kde-* ones? should we change our metas? +<tampakrap> kde-baseapps kde-runtime kde-workspace +<jmbsvicetto> What's the name of the repos? +<ABCD> the same +<tampakrap> personally i'd prefer sticking to the repos name +<tampakrap> and tarballs name of course +<jmbsvicetto> in that case it would make sense - unless they decide to rename +it again +<tampakrap> no they won't +<jmbsvicetto> we could perhaps wait for next beta release, just to be sure ;) +<tampakrap> sure +<ABCD> of course, that means we'll have to check for `has_version +kde-base/kdebase-runtime-meta || has_version kde-base/kde-runtime-meta` +everywhere +<tampakrap> i think we covered all the monolithic/not converted yet tarballs +so far +<tampakrap> yes +<tampakrap> it is a major change +<jmbsvicetto> at this point I don't think krosspython will be fixed on this +release (Dirk already said a kdepim issue would have to wait for next release) +<tampakrap> ok +<tampakrap> so, what about kate? +<jmbsvicetto> it should be working now +--> ni1s (~ni1s@1-1-4-36a.dre.sth.bostream.se) has joined #gentoo-meetings +<tampakrap> do you also fix the 4.7 lives? +<-- ni1s (~ni1s@1-1-4-36a.dre.sth.bostream.se) has left #gentoo-meetings +<jmbsvicetto> I actually forgot to test it on my test box :\ +<jmbsvicetto> I started by touching 4.6.80. I think ABCD and alexxy applied +the changes to 9999 now +<jmbsvicetto> I don't know anything about 4.7.9999 +<ABCD> there is no 4.7.9999 yet +<ABCD> because upstream hasn't branched +<tampakrap> lol? +<tampakrap> they tagged from master? +<ABCD> yeah -- just like they usually do for the betas :) +<tampakrap> ok that sucks +<tampakrap> so, how's 9999 then? +<dilfridge> alexxy probably knows best +<ABCD> 9999 is fine -- I forward ported most of the -4.6.80 changes so that we +can bump 4.6.85 (or whatever) from 9999 -- note that okular-4.6.85 will be +coming from its own tarball, not the "monolithic" kdegraphics-4.6.*.tarball +<ABCD> (or it should be -- they just finished that split) +<tampakrap> great, thanks +<dilfridge> speaking of kdegraphics +<tampakrap> so, anything else on monolithiks/no migrated yet +<alexxy> heh. also i think we can drop eclass foo from all :live tarballs +<tampakrap> before proceeding to the splitted/migrated ones? +<dilfridge> the kdegraphics libs are tagged from the same branch as the ones +distributed with digikam +<alexxy> since we now know how they will be packaged +<jmbsvicetto> alexxy: the if blocks? +<dilfridge> meaning with 4.7 the incompatibilities will go away +<jmbsvicetto> sure, I already did it for 4.6.80 ebuilds +<alexxy> yeah +<alexxy> so we should do it for :live +<jmbsvicetto> ABCD: did you push those changes to 9999? +<ABCD> alexxy: already done -- 4.6.9999 keeps it, though +<ABCD> jmbsvicetto: yeah +<alexxy> also i'm going to make universal ebuild for kde-l10n (that should +support :live and regular tarballs) +<tampakrap> good +<tampakrap> dilfridge: yours +<dilfridge> ? +<tampakrap> you were saying that kdegraphics... +<ABCD> fyi, if/when slotting gets dropped, 4.x.9999 will become something like +4.x.49.9999 to keep versions in order +<dilfridge> the kdegraphics libs are tagged from the same branch as the ones +distributed with digikam +<dilfridge> so our problems with digikam will go away +<tampakrap> cool +<tampakrap> ABCD: what do you mean? +<tampakrap> slotmove everything back to 0? +<ABCD> tampakrap: yeah +<tampakrap> are you crazy?? +<dilfridge> not 4? +<jmbsvicetto> tampakrap: that would seem to be the goal of dropping the +slotting +<tampakrap> i don't see a reason to do that +<dilfridge> i think it makes sense +<ABCD> the main reason we had slots to begin with was +kdeprefix -- kdeprefix +will be gone as of Monday next week +<jmbsvicetto> dilfridge: if we want to drop kdeprefix, we should drop the +slots +<dilfridge> jmbsvicetto: yes that is what I mean +<dilfridge> we should definitely drop the slots +<tampakrap> yeah, but 4.x.49.9999 doesn't +<ABCD> dilfridge: I don't know if we should use :0 or :4 :) +<jmbsvicetto> 0 or 4 is all the same +<tampakrap> and why are slot 4 so bad? +<dilfridge> not when 5 comes along :) +<-- devurandom (~devu@unaffiliated/devurandom) has left #gentoo-meetings +<jmbsvicetto> then you admit to introduce kdeprefix later? :P +<dilfridge> 4.x.49.9999 makes actually a lot of sense +<ABCD> tampakrap: 4.x.11 < 4.x.49.9999 < 4.x.80 (4.{x+1} beta 1) +<ABCD> 4.x.80 (4.{x+1} beta 1) < 4.x.9999, which means that portage would see +it as a downgrade +<tampakrap> what is the big problem with slot 4 anyway? +<jmbsvicetto> yes, 4.x.49.9999 sounds good, even though we could argue that +4.x.49 would be the same +<tampakrap> i don't understand +<dilfridge> jmbsvicetto: given the differences between kde-3 and kde-4, I +would not rule anything out with kde-5 +<jmbsvicetto> tampakrap: I don't have a problem with slot 4. I'm just saying +that have slot=4 or slot=0 is all the same for the PMs +<ABCD> tampakrap: the idea is to get the versions in some sort of order, such +that 4.x.y, where y < 50 is KDE 4.x, and 4.x.y where y > 50 is KDE 4.{x+1} +<jmbsvicetto> ABCD: I agree, but as I said, 4.x.49 would be as good as +4.x.49.9999 +<jmbsvicetto> there should never be any 4.x.49 release - or they'll have to +modify their release numbers ;) +<dilfridge> except at some point maybe someone will introduce a 9999-magic in +portage... +<ABCD> jmbsvicetto: 4.x.49.9999 makes it a bit more obvious that it's live +(and I think at least one PM assumes that it can't be a live ebuild if it +doesn't have "9999" in the version) +<jmbsvicetto> and the 9999 use is a "design" option, not a requirement +<dilfridge> repoman does that similarly +<jmbsvicetto> PMS doesn't acknowledge 9999 as special, afaik +<jmbsvicetto> repoman is based on eclass inheritance, iirc +<ABCD> I think paludis does (I remember hearing something about that) +<ABCD> I know portage uses inherit() to determine what "live" is +<jmbsvicetto> in any case I don't have anything against 4.x.49.9999 +<tampakrap> ok +<tampakrap> i must admit i still don't understand +<jmbsvicetto> I just fell 4.x.49 is smaller and if it works as well (which I +think it should) we may want to use that +<tampakrap> but since the rest of the team does, i step aside +<ABCD> tampakrap: what part don't you understand? +<jmbsvicetto> tampakrap: what don't you understand? The ordering? +<tampakrap> 1) why slotmove a million ebuilds to 0 again 2) what is 49? +<ABCD> tampakrap: why slotmove? it makes upgrading *much* easier (no more +nasty blockers) +<alexxy> well i think we still should have slots =) +<dilfridge> please no slots anymore +<alexxy> ok +<dilfridge> it makes life so much simpler and without kdeprefix there is no +real reason for it +<alexxy> there will be kde5 next year +<tampakrap> not sure +<alexxy> so we should have at least one slot +<jmbsvicetto> tampakrap: as we're dropping kdeprefix, there won't be any more +reason to have different slots for each version +<dilfridge> yes, that's ok +<dilfridge> I'd go for "move everything to 4" +<tampakrap> +1 +<ABCD> 2) what is 49? It's less than 50, which is the arbitrary cutoff used to +determine if 4.x.y is part of KDE SC 4.x or KDE SC 4.{x+1} +<jmbsvicetto> tampakrap: and if we put all packages in the same slot, we can +simplify the eclasses +<tampakrap> ok +<jmbsvicetto> about slot=0 or slot=4, that is something that only has meaning +to humans, not to the PM +<tampakrap> put everything to 4 then? +<tampakrap> quick vote +<tampakrap> 0 or 4 +<jmbsvicetto> whatever slot you want to use +<alexxy> +1 for :4 slot +<dilfridge> 4 +<tampakrap> 4 +-*- ABCD doesn't care +<jmbsvicetto> I can live with both. 0 would be more "accurate" if we don't +want to have kdeprefix anymore, 4 otherwise +<tampakrap> i don't intend to slotmove all the kde-misc ebuilds again +<jmbsvicetto> by dropping slots, we need to update all deps to use versions +and not slots +<ABCD> and we won't have kdeprefix (the actual flag might live for a short +while longer, but if it does, it will just be to do pkg_setup() { use +kdeprefix && die ....; ....; }) +<ABCD> jmbsvicetto: they already do -- except when USE=kdeprefix +<tampakrap> ABCD: about 49, since 4.x.80 are 4.x+1, why not just use this? +<tampakrap> and deal with an extra number? +-*- ABCD isn't sure what you're trying to say, tampakrap +<jmbsvicetto> tampakrap: the idea is that the first release KDE will ever do +of a new version is 4.x.50 +<jmbsvicetto> that's what they've written in their release "rules" +<tampakrap> yes, but the tarballs are shown after 4.x.80 +<tampakrap> before that there is only live ebuilds +<jmbsvicetto> sure, but since 4.x.50 is a new version, 4.x.49 should be used +as the last version of a version +<ABCD> tampakrap: they've released tarballs for alphas before, with lower +numbers +<tampakrap> they won't anymore though +<jmbsvicetto> bah, terrible language :\ +<tampakrap> they said that interested parties can get the tarballs from +redmine or gitweb +<jmbsvicetto> tampakrap: why take the chance? +<tampakrap> i don't think there is a chance here but anyway +<tampakrap> 49 it is +<jmbsvicetto> tampakrap: 4.x.50 should never be used for version 4.x - +recently the most they've been getting is 4.x.7 anyway, right? +<tampakrap> true +<tampakrap> anyway, i think we all agree here +<ABCD> and 49 is just an arbitrary number that is definitely between the last +4.x release but before the first 4.{x+1} release (and I've hardcoded the +4.x.50 assumption in other places) +<tampakrap> ok +<tampakrap> next +<dilfridge> the "50 limit" is already in the eclass +<tampakrap> jmbsvicetto / alexxy status of migrated/ split modules? +<ABCD> yeah +<tampakrap> do we follow upstream there? should we? +<jmbsvicetto> besides the missing krosspython, everything else should be +working +<jmbsvicetto> I think we should +<jmbsvicetto> (follow upstream) +<alexxy> actualy most of migrated and splited modules has same spliting as we +do +<jmbsvicetto> on 4.6.80 we're already doing it +<tampakrap> one by one +<tampakrap> kde edu, check? +<tampakrap> https://projects.kde.org/projects/kde +<ABCD> kdeedu we are 100% following upstream +<tampakrap> kde graphics, check? +<jmbsvicetto> the split on our end is complete +<jmbsvicetto> for both +<tampakrap> kde base +<ABCD> kdegraphics, they didn't finish splitting in time for 4.6.80, but +should be done for 4.6.85 +<ABCD> (we might want to package the new mobipocket repo, though -- I'll look +into that) +<tampakrap> kdebase is consisted of three monolithic and two split repos as i +see +<tampakrap> so we're fine here +- {Day changed to Fri Jun 3 00:00:00 2011} +<ABCD> plus one more (kinda) monolithic repo: kate :D +<ABCD> kwrite moved from kde-baseapps to kate +<tampakrap> kdepim/kdepim-runtime is monolithic, check +<tampakrap> yeah +<tampakrap> how are we on that area? +<alexxy> tampakrap: they may split it +<tampakrap> kate/kwrite i mean +<tampakrap> kdepim is NOT going to get split +<tampakrap> and nothing that migrated is going to change +<tampakrap> kdepimlibs/kdelibs are monolithic on both sides +<tampakrap> last question: +<tampakrap> is the bump ready from our side? +<tampakrap> should i announce it? update docs? +<dilfridge> bump of what? +<tampakrap> 4.6.80 +<tampakrap> in general +<jmbsvicetto> tampakrap: we should run more tests and still need to fix some +stuff +<alexxy> tampakrap: its NOT ready +<tampakrap> what's missing please? +<ABCD> tampakrap: upstream to release a kross-interpreters tarball :D +<tampakrap> if you speak now you may get more help :P +<tampakrap> yeah, apart from that :) +<alexxy> kdebindings +<alexxy> =) +<jmbsvicetto> kdebase + kdegraphics + kdemultimedia + kdenetwork + kdeedu + +kdegames + kdetoys + (most of) kdeutils, should work +<jmbsvicetto> afaik kdebindings is broken. I don't know kdepim status +<ABCD> assuming that you disable anything that needs krosspython (pykde4 +probably should work, I would think) +<tampakrap> ok, so i suppose i should not recommend people to update to it at +all +<jmbsvicetto> pykde4 build on my test system. I haven't tested it though +<alexxy> jmbsvicetto: kdepim should work +<jmbsvicetto> not at this stage +<jmbsvicetto> I'd wait for a krosspython release (probably next beta) +<tampakrap> ok, so what's needed from our side? +<jmbsvicetto> tampakrap: for the above list, I can say my testing system is +running. I'm not using too many kde apps on it though +<jmbsvicetto> I'm using it mostly as a build box, some browsing (FF), kwrite, +kopete and general DE use +<tampakrap> cool +<tampakrap> thank you guys for handling it +<tampakrap> good job +<jmbsvicetto> I haen't tested the games or kdeedu apps yet +<tampakrap> i don't have to say anything else on 4.7, if anyone has to say +something speak now +<jmbsvicetto> sorry for the commit noise, but I'm a "old grumpy" dev ;) +<tampakrap> we'll kick your ass later +<tampakrap> dilfridge: next topics are yours +<dilfridge> ho hum +<tampakrap> use flag defaults for kde subprofile (bug 365251) +<willikins> tampakrap: https://bugs.gentoo.org/365251 "Use flag defaults for +the desktop/kde profile"; Gentoo Linux, KDE; CONF; dilfridge:kde +<dilfridge> ok... all that I listed were (as far as I remember) not in the +desktop profile +<dilfridge> maybe we just go quickly through use-flags and vote whether they +should be enabled in the kde profile (NOT forced of course) +<dilfridge> 1) cups - I think this is a clear usability improvement +<tampakrap> isn't the system-config printer broken? +<tampakrap> and hardmasked? +<dilfridge> eww +<dilfridge> possibly +<jmbsvicetto> as I stated when the kde profile was created, I don't like the +idea too much, but as I don't use it, I don't care +<tampakrap> cups: no +<dilfridge> we'll come back to that topic later ("open floor") +<dilfridge> ok +<dilfridge> 2) dri, xcomposite, xinerama +<tampakrap> +1 +<dilfridge> since kwin heavily relies on all that stuff +<dilfridge> 3) -gnome +<tampakrap> no +<dilfridge> this is to avoid problems like the recent glib-networking desaster +<ABCD> don't need it -- I don't think desktop/ sets +gnome anyway :) +<dilfridge> ok then not +<tampakrap> true +<dilfridge> 4) nsplugin +<dilfridge> since konqueror provides a plugin container +<tampakrap> no opinion +<dilfridge> no strong opinion here either, so maybe lets forget about it +<dilfridge> 5) semantic-desktop :) +<tampakrap> yes! +<dilfridge> as it is needed by kdepim +<dilfridge> 6) xscreensaver +<dilfridge> to provide more eyecandy +<tampakrap> +1 +<alexxy> opengl +<alexxy> gles +<ABCD> -1 on gles, I think +<ABCD> (unless I'm mistaken) +<tampakrap> opengl +1, gles -1 +<ABCD> as I thought that gles was primarily for embedded, or something like +that +<ABCD> but +1 on opengl +<alexxy> kwin will work with it better then with opengl +<dilfridge> opengl is already in desktop +<ABCD> there we go :) +<alexxy> if you use gallium drivers +<tampakrap> that's not a reason to force it in every kde user +<dilfridge> ok that's it for me on this topic, I summarize: +<ABCD> these are defaults, not forced :) +<dilfridge> we add the following flags to the default use flags in the kde +subprofile: +<tampakrap> wait i want more +<dilfridge> ok +<tampakrap> qt, qt4 +<dilfridge> qt4 is in desktop +<tampakrap> qt? +<dilfridge> not +<tampakrap> qt is old apparently +<tampakrap> declarative +<dilfridge> yes +<tampakrap> kipi +<dilfridge> yes +<tampakrap> phonon? +<tampakrap> is that enabled already? +<dilfridge> no +<dilfridge> we should add it +<tampakrap> ok +<tampakrap> and qt3support? +<tampakrap> is this being dropped by upstream? +<dilfridge> in desktop +<tampakrap> i know +<tampakrap> if it's being dropped of 4.7 we should consider dropping it from +desktop +<dilfridge> good question, I know they are working in that direction +<tampakrap> ah and plasma +<tampakrap> is that enabled? +<dilfridge> no, I'll add it to the list. qt3support maybe worth a mail to the +releaseteam +<tampakrap> ok +<tampakrap> that's all +<dilfridge> "declarative dri kipi phonon plasma semantic-desktop xcomposite +xinerama xscreensaver" +<dilfridge> ^ any further comments? +<dilfridge> ok then with your ok I'll add this later to the profile +<tampakrap> no, i want to announce it first +<dilfridge> ah ok +<dilfridge> fine +<tampakrap> anything else? +<dilfridge> next topic would be kdeprefix status +<tampakrap> we already discussed it i suppose +<dilfridge> yes +<dilfridge> ok next... +<dilfridge> kde-4.6.3 +<tampakrap> should be fine, i don't see bugs :) +<dilfridge> I would like to file a stablereq in a week or so (30days etc), +just so stable keeps up +<tampakrap> bug reports that is +<dilfridge> ok... if there are any problems or if you have any objections, +talk to me please :) +<tampakrap> that's all? +<dilfridge> from the agenda, yes +<tampakrap> *) open floor +<dilfridge> open floor- one point from me +<tampakrap> shoot +<dilfridge> i was kind of crazy enough to mail tgurr about cups-1.4 +stabilization +<dilfridge> basically I can go ahead sorting the remaining bugs etc +<dilfridge> this may take some time, but at some point I hope we'll have some +news there +<dilfridge> that's all +<tampakrap> ok +<tampakrap> and one point from me: +<tampakrap> we lost scarabeus, we need new people +<tampakrap> i mean, what comes next? losing jmbsvicetto? +-*- jmbsvicetto slips away +<dilfridge> we should all move on to qa and recruit diego for kde :D +<tampakrap> actually, he was a kde guy long ago +<dilfridge> did not know that +<jmbsvicetto> tampakrap: all I can say about that is that I'm trying to use my +council hat to ensure we fix the issues that affected Tomas motivation +<jmbsvicetto> Diego and Dan Armak started kde on Gentoo, I think +<jmbsvicetto> if not, they maintained kde on gentoo for many years +<tampakrap> we need scarabeus and ssuominen back +<jmbsvicetto> at this point and unless people change, that seems unlikely +<tampakrap> btw, meeting closed, thanks for coming diff --git a/meeting-logs/kde-project-meeting-summary-20110602.txt b/meeting-logs/kde-project-meeting-summary-20110602.txt new file mode 100644 index 0000000..772a257 --- /dev/null +++ b/meeting-logs/kde-project-meeting-summary-20110602.txt @@ -0,0 +1,44 @@ +rollcall +ABCD, alexxy,dilfridge,tampakrap,jmbsvicetto + +1) KDE SC 4.6.80 bump + +jmbsvicetto and alexxy did a great job so far about it, with ABCD +forward-porting the commits to the live ebuilds. It is not ready yet though, +and we'd not recommended to users yet, unless they know what they are doing. +Upstream split some of the tarballs in order to follow the repos for 4.7. We +were very lucky so far, and upstream's split was very similar to ours, apart +from kdebindings, which we'll have to re-package to follow them. + +2) Drop of kdeprefix useflag + +The kdeprefix USE flag is announced to be dropped this Monday. As a result, +we'll have to move all ebuilds to slot 4. We could move them to 0 as well in +order to drop the slotting entirely, but since most of them are already 4 it +will prevent us from doing another massive slotmove. + +3) Useflags in kde profile + +It was decided these useflags to be added to the kde profile: declarative, +dri, kipi, phonon, plasma, semantic-desktop, xcomposite, xinerama, +xscreensaver + +4) KDE SC 4.6.3 stabilization + +First of all, dilfridge deserves congratulations for taking care the +heavy job of doing the 4.6.2 stabilization, along with Qt 4.7 and a large +number of other Qt and KDE applications. Keep in mind that this was a really +hard job to do, since the previous stable version was 4.4.5. Things are now +back in order now, with 4.6.2 fully stabilized and 4.4 completely removed +(finally). 4.6.3 is the next stabilization target, to keep stable tree up to +date. + +*)Open floor + +Andreas said he is interested in doing some cups work, which we hope to affect +KDE and desktop users in general. + +We lost scarabeus, one of our top developers. Thus, +we'd like to remind anyone that we always appreciate the help of new people. +If you are one of the guys that already has access to the overlay, time to +complete your ebuild and end quiz then! |