Log and summary of today's meeting

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!