Add KDE herd meeting log 2014/03/29

1 files changed, 456 insertions, 0 deletions

diff --git a/meeting-logs/kde-project-meeting-log-20140329.txt b/meeting-logs/kde-project-meeting-log-20140329.txt
new file mode 100644
index 0000000..d8a842a
--- /dev/null
+++ b/meeting-logs/kde-project-meeting-log-20140329.txt
@@ -0,0 +1,456 @@
+<johu> 1. Roll call (5 minutes)
+<johu> !herd kde
+-*- creffett|irssi here
+<willikins> (kde) ago, alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00
+-*- scarabeus beeps
+<kensington> hi
+<mrueg> pong.
+-*- johu here
+<johu> 2. EAPI 4 kde4.eclasses deprecation (10 minutes)
+<johu> - KDE overlay is fully migrated to EAPI 5 and all older EAPI's are banned
+<johu> - No issues known with EAPI 5
+<johu> - Discuss and vote
+<creffett|irssi> question: I know we've handled this in-overlay, but what's the state of packages in-tree?
+-*- jcallen is here
+<johu> i bumped alot to EAPI 5
+<mrueg> let me check.
+<creffett|irssi> (would be nice if pkgcore worked enough to give us the EAPI-by-eclass breakdown)
+<johu> so its only a question of stable requests and some packages not maintained by us
+<kensington> pkgcore-9999 works good enough now
+<kensington> and it fixed on qa-reports I think
+<johu> yes qa-reports is fixed
+<creffett|irssi> really.
+<johu> thats why i started to do the tree EAPI 5 work
+<creffett|irssi> news to me
+<kensington> we should ban it in the overlay and in the tree once that's cleaned up
+<mrueg> kde-base: 21, kde-misc: 20 eapi 4 packages (eapi per cat)
+<creffett|irssi> so...bump the requirement in-overlay, news item on -dev or -dev-announce, file bugs?
+<kensington> http://qa-reports.gentoo.org/output/eapi-per-eclass/kde4-base.eclass/4.txt
+<johu> ^^ most of them have already EAPI 5 rev bumps
+<kensington> cool
+<scarabeus> then stablereq and request cleanup
+<creffett|irssi> yup
+<johu> around 20th april we can start mass stabilization and see whats left
+<mrueg> so eapi4 ban would mean drop kdepim 4.4.x, right?
+<kensington> mrueg: I wish
+<johu> nope
+<creffett|irssi> are those not EAPI 5?
+<johu> we just bump them to EAPI 5
+<creffett|irssi> yeah
+<johu> i poked dilfridge about it already and he wants to do it
+<creffett|irssi> probably no need for a revbump, tbh
+<mrueg> creffett|irssi: just checked for knotes still eapi=4
+<creffett|irssi> kk
+<kensington> creffett|irssi: it's stable packages
+<creffett|irssi> kensington: blarg
+<johu> anyone who wants to keep EAPI 4?
+<kensington> punt it
+<johu> ok vote:
+<mrueg> no need to keep, but what is the need to punt it?
+<creffett|irssi> I know it's stable, but I doubt the bump will actually change installed files, and those aren't using any eaapi features, afaik
+<mrueg> just progress?
+<creffett|irssi> +1 burnintae
+<creffett|irssi> *burninate
+<johu> +1
+<kensington> mrueg: for 4 -> 5 not much, but eg. it might let us assume subslot support for something in the future
+<scarabeus> should be fine for 4->5 so +1
+<johu> creffett|irssi: we have already subslots implement for kde-base in the eclass
+<creffett|irssi> johu: oh, right, forgot about those
+<creffett|irssi> revbump it is.
+<mrueg> kensington: i just wonder if ebuilds in overlays will fail because eclass disallows <eapi-5
+<kensington> in the past, dropping <3 let us clean up a lot of junk from the eclasses
+<mrueg> *non-kde
+<mrueg> overlays
+<creffett|irssi> mrueg: not our problem
+<kensington> they will, that's their problem, we will announce as per usual
+<creffett|irssi> we announce it
+<creffett|irssi> they fix their own
+<mrueg> okay sounds good. :)
+<mrueg> +1
+<kensington> I did a couple of the 'major' ones for the las ttime
+<johu> we make a tracker for the packages not maintained by us
+<creffett|irssi> yup; I can do that if you'd like
+<johu> creffett|irssi: lets do it after the mass stabilization
+<mrueg> it would be nice to get a repoman error if eapi is deprecated for used eclass
+<creffett|irssi> okay
+<creffett|irssi> mrueg: that would require eclasses have a DEPRECATED_EAPIS sort of variable
+<creffett|irssi> which would be nice, admittedly
+<johu> creffett|irssi: raise that topic in qa please
+<mrueg> yep 
+<johu> :)
+<creffett|irssi> johu: in portage, actually :P
+<creffett|irssi> mrueg: file a bug :)
+<mrueg> probably talk to TomWij
+<mrueg> or file a bug ;)
+<mrueg> will do.
+<johu> next topic
+<creffett|irssi> I would look into it if I had time in the next...two months.
+<johu> 3. KDE overlay contribution model (10 minutes)
+<creffett|irssi> mmkay
+<johu> - We have a github mirror, which offers pull requests, reviews and comments
+<johu> - Allows us to get more QA for user contributions
+<johu> - Proposal: Drop all user ssh keys from overlay and promote the github contribution model (for example with a overlay news item)
+<johu> - Discuss and vote
+-*- creffett|irssi is in favor of switching to github/pullreq model and dropping users' keys
+<kensington> I am against dropping all user ssh keys
+-*- mrueg wants to wait until infra deploys gitolite-3 on gogo
+<johu> mrueg: what offers gitolite-3?
+<mrueg> johu: easier mirroring
+<kensington> we should encourage pullreqs for more user contributions, but I think some users is fine to commit directly
+<creffett|irssi> kensington: hmm, that's valid
+<johu> kensington: but where you draw the border
+<creffett|irssi> that said, there have been a couple problematic commits as of late
+<johu> one user drop one not
+<kensington> I don't think we even have a list of who has access
+<johu> thats easy question for infra...
+-*- creffett|irssi asks
+<mrueg> right now mirroring means someone with access to both repositories does this on git push and pull, right?
+<kensington> dastergon can probably help with that
+<kensington> mrueg: yes, no server automation is currently supported
+<creffett|irssi> so we come back to the question of who we want to have access
+<kensington> infra won't do a hook, and github need to contact their support to have them mirror
+<johu> kensington: please propose the criteria which user can proceed to commit and who not
+<johu> imho it should be consistent
+<creffett|irssi> the thing is that most commits I've seen have been devs; of non-devs, there have only been a couple committing regularly, and at least one of those has been subpar
+<creffett|irssi> iow, we don't have a high non-dev commit rate to start with I think
+<mrueg> we could allow only pushes to a non-master branch for users and merge it regularly
+<kensington> it's impossible to have a list of checkboxes
+<kensington> in general, makes enough patches that are good seems like a good rule, it worked in the past
+<scarabeus> nah just do it simple, they start with pull requests and if they are good they get the commit access directly, if they screw up they loose it
+<kensington> scarabeus++
+<creffett|irssi> good enough for me
+<kensington> that's what we used to do anyway, except with patch on bugzie instead of pull request
+<creffett|irssi> but do we keep everyone's access?
+<scarabeus> also *lose... :D
+<creffett|irssi> for those interested:
+<creffett|irssi> 13:28 <@a3li> hi creffett|irssi, I'd have this list of additional keys besides all developers for you: caleb christian civil creffett cryos dastergon dessa devurandom dmaggot eliasp genstef helgc
+<creffett|irssi>               idella4 johu kensington krytzz letharion lxnay mattepiu mrueg mschiff mva okias ronis_br skiarxon spatz sput terietor tgurr travlr wizzleby wohnout yngwin
+<creffett|irssi> I...uh..have no idea who half of those people are.
+<creffett|irssi> :P
+<kensington> and the other half is people that went on to be devs :p
+<creffett|irssi> yup
+<creffett|irssi> so do we want to keep all of those?
+<johu> i raised this topic to make the contribution easier for non-devs and as github is generally accepted i think this is the consistent way
+<johu> for example clean up wiki page with contribution info
+<johu> remove hackers file etc etc
+<creffett|irssi> yeah
+-*- johu thinking in long term to a git migrated tree :D
+<mrueg> johu: heh. 
+-*- creffett|irssi drinks
+<mrueg> can anyone add a instruction how to mirror both repositories? 
+<mrueg> last time i tried to merge a pull request on my own overlay, it went all mad.
+<creffett|irssi> so for the moment, any objections to leaving current contributors with access and switching to encouraging everyone else to use github pullreqs?
+<mrueg> ++
+<johu> fine by me
+<kensington> mrueg: I personally use github "merge on command line" instruction, then rebase and push
+<kensington> otherwise you can merge in github ui, pull, then push to gogo
+<johu> mrueg: you have to add another remote to you local git clone
+<creffett|irssi> kensington, scarabeus: any objections?
+<creffett|irssi> jcallen: and you
+<kensington> creffett|irssi: no, since this is the current process anyway :p
+<mrueg> kensington, johu: an example gitconfig would be nice. ;)
+<creffett|irssi> well, that's a majority
+<creffett|irssi> johu: your turn
+<kensington> mrueg: http://bpaste.net/show/195334/
+<johu> http://dpaste.com/1763251/
+<mrueg> thanks
+<mrueg> looks like i did something wrong here. http://bpaste.net/show/pqp20cn2F7hNvn7aQjWI/ ;)
+<johu> so please vote on the general plan
+<kensington> I have no problem with cleaning up at least some of the access list, I agree there have been some 'interesting' commits lately
+<johu> with the exception of not dropping keys at once
+<creffett|irssi> +1
+<johu> +1
+<kensington> +1
+<johu> ok i will prepare a news item and send it to kde
+<johu> @
+<johu> we can optimize it then
+<creffett|irssi> sounds good
+<johu> next topic
+<johu> 4. KDE Frameworks 5 (15 minutes)
+<kensington> yay!
+<johu> Overview: KDE Frameworks
+<johu> New kde-frameworks eclass needs internal review/feedback. It's not yet ready for -dev ml due to potential major changes for workspaces and applications.
+<johu> It appears (final strategy not confirmed yet) that rather than one SC as seen in KDE 4 there will be 3 groups released separately: frameworks, workspaces, and applications. We should consider how this should be categorised. kde-frameworks is currently approximately 60 packages, with the potential for future 30+ additional packages. Potential scheme which is consistent with existing categories (see gnustep for -libs precedent):
+<johu> frameworks -> kde-frameworks/kde-libs
+<johu> workspaces -> kde-base
+<johu> applications -> kde-apps
+<johu> See Naming scheme, Dicuss and vote
+<creffett|irssi> wheeeee
+<mrueg> what about kde-misc?
+<creffett|irssi> people are going to complain about us having three categories.
+<kensington> there's precedent, see gnustep
+<creffett|irssi> didn't say no precedent, said there will be complaining ;)
+<johu> i would follow naming scheme from upstream-> frameworks -> kde-frameworks
+<kensington> a lot of frameworks stuff is designed to be not so kde-specific, so I think they deserve their own category
+<creffett|irssi> that said, the suggested split sounds good to me
+<johu> -workspaces -> kde-workspaces
+<johu> -applications -> kde-apps
+<creffett|irssi> we also may want to consider doing something with kde-misc, but that's a different question for a different day
+<kensington> kde-misc stuff doesn't fit into any of those other categories
+<johu> kensington++
+<creffett|irssi> I mean more like there's a lot of cruft in there
+<creffett|irssi> that I doubt anyone uses
+<creffett|irssi> like I said, different question for a different day
+<kensington> yeah, it could use some testing, I last-rited a youtube package in there that is probably broken for years
+<mrueg> johu: that means for the mean time 5 categories, right?
+<mrueg> kde-apps, kde-base, kde-frameworks, kde-misc, kde-workspaces
+<kensington> I agree with johu, but I think we will get a lot of pushback on -dev
+<creffett|irssi> yup.
+<mrueg> i think it is a good idea to seperate the release groups 
+<johu> just move the two proposals to -dev
+<johu> and see how it turns outr
+<creffett|irssi> question: when is kde 4 set to stop getting releases
+<johu> creffett|irssi: when there is a stable kf5 based release
+<johu> kde-{workspaces,apps}
+<mrueg> creffett|irssi: maybe there's also a trinitiy project for that
+<mrueg> do we want to support kde sc 4 and kf 5 installed in parallel?
+<kensington> frameworks is about to hit beta, and workspaces is about to hit alpha
+<johu> kf5 is almost co-installable with kdelibs
+<kensington> kde-runtime will be co-installable, kde-workspace will not
+<creffett|irssi> well, at least we have time before the tree move to get flamed
+<johu> who raises the cat discusion to -dev
+<johu> ?
+<mrueg> just think about a package depending on kwin for example
+<kensington> I would like to have some team agreement, because the runtime/workspaces split is about to happen and I want to package asap
+<creffett|irssi> +1 from me
+<kensington> mrueg: kwin will not be co-installable, but not much depends on it anyway
+<johu> i have no objections, please dont re-introduce a kde-prefix again
+<creffett|irssi> also, I volunteer kensington for emailing the ML :P
+<mrueg> kensington: just thinking if we want to deal with slots or categories 
+<creffett|irssi> ooh!
+<creffett|irssi> kde-prefix!
+<mrueg> so kde-base/kwin:4 or kde-base/kwin because kwin:5 will be in kde-frameworks or somewhere else.
+<kensington> all kde5 stuff is already in slot 5
+<kensington> vote on: kde-frameworks, kde-workspaces, kde-apps
+<mrueg> +1 
+<johu> +1
+<johu> if -dev is against it we should go with kde-apps, kde-libs, kde-base
+<mrueg> kde-base for kde4, kde-misc for everything else
+<mrueg> probably eclass can use the category to decide which release group the package is
+<mrueg> so we don't need anything like TIER=1 inside of the ebuild
+<kensington> mrueg: it's all in split repos
+<kensington> TIER=foo was only for frameworks stuff when it was still in kdelibs
+<johu> ack
+<mrueg> kensington: ah okay
+<mrueg> didn't know that :)
+<johu> anything left to discuss for now on kf5?
+<mrueg> yup
+<mrueg> lately there was a discussion to merge qt-overlay and kde-overlay?
+<kensington> if anyone has a free moment, check the eclass, there are a few design decisions that could use a review
+<johu> what about the ebuild naming scheme?
+<johu> mrueg: i dont see the purpose, the split was decided with the herd split and thats totally fine
+<mrueg> johu: i don't know, can't both sides profit from a shared repository?
+<kensington> there's not much crossover
+<creffett|irssi> the only commonality, really, is qt5
+<johu> mrueg: there was a time where no qt herd exists and the qt stuff was maintained by kde
+<creffett|irssi> I actually did not know that
+<johu> and then the split was decided because of the reason that there is no much crossover
+<creffett|irssi> though that explains the large number of qt people in our repo's access list :P
+<mrueg> but what would be the drawbacks of a joint repository?
+<johu> because kde is just one consumer
+<kensington> the effort to merge it and people migrating to it I guess
+<johu> we have high kde commit rate because of the monthly releases and someone who dont want to have extra kde stuff but newest qt stuff is pushed to get all those changes...
+<mrueg> johu: probably we can work on seperate branches and with a joint master branch
+<kensington> naming scheme is important if we end up using kde-base for kde5 stuff
+-*- johu is against a re-joined qt-kde repo
+<creffett|irssi> mrueg: eww
+<kensington> and if not it would be nice to not have to manually pin ebuilds to a branch they don't match
+<mrueg> okay :)
+<mrueg> i see we better stay at status-quo :)
+<johu> kensington++
+<kensington> so, we can either just update the sets (eg. kde-live pulls in kcalc-9999 and kwin-4.12.49.9999) or make fake versions like 4.9999
+<johu> sets sounds more reasonable
+<kensington> ++
+<creffett|irssi> ++
+<johu> but this decision is a little bit influenced by the cat discusion on -dev
+<kensington> yeah
+<creffett|irssi> yup
+<kensington> also, I think kde-workspaces will end up to be not many packages
+<johu> maybe kde-base fits here okayish
+<kensington> it's being split into 12 repos, probably only that many packages
+<johu> kensington: i would suggest to write the -dev mail as soon as possible and then do the reasonable move!
+<kensington> johu: I will wait 1 or 2 days until the split is done, to get an accurate number of packages
+<kensington> if 12 repos = 12 packages, a new category for that will be definitely be rejected
+<johu> we could discuss this per mail if it is realy urgent and needs a fast decision
+<mrueg> johu++
+<kensington> I will mail a draft to the alias depending on what happens upstream
+<creffett|irssi> ++
+<johu> ++
+<johu> anything left on kf5?
+<kensington> otherwise I guess it will just be kde-frameworks/libs + kde-base
+<johu> btw kensington thank you for your great work
+<creffett|irssi> mhm
+<kensington> btw, mimetypes is fixed upstream in case you didn't see :-)
+<creffett|irssi> kensington++
+<johu> 5. Bugs (15 minutes)
+<johu> bug 445392
+<willikins> johu: https://bugs.gentoo.org/445392 "kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling"; Gentoo Linux, Applications; UNCO; toralf.foerster:kde
+<creffett|irssi> RESO NOTOURBUG
+<kensington> ++
+<johu> c7
+<johu> ++
+<mrueg> ++
+<ago> hello
+<johu> i dont want to do upstream work
+<kensington> hi ago 
+<mrueg> hey ago
+<ago> sorry for the delay, I had a prob.
+<creffett|irssi> good enough, will mark it 
+<johu> bug 456360
+<willikins> johu: https://bugs.gentoo.org/456360 "kde-base/print-manager looking for org.fedoraproject.Config.Printing"; Gentoo Linux, KDE; CONF; kirelagin:reavertm
+<toralf> erm : bug 445392 vanished away / was solved in the mean while (at least with 4.12.3+4.11.7)
+<willikins> https://bugs.gentoo.org/445392 "kde-base/konsole-4.9.3, x11-terms/xterm: backgroundcolor is not reset when scrolling"; Gentoo Linux, Applications; UNCO; toralf.foerster:kde
+<kensington> toralf: that's good news
+<mrueg> johu: that bug confuses me.
+<johu> printer stuff needs gnome bla to get full working, so there was a proposal to split stuff up
+<johu> but i got lost by all those user comments
+<kensington> is reavertm around lately?
+<creffett|irssi> haven't seen reavertm, no
+<johu> in the last years not realy
+<kensington> I guess the real solution is to improve the splitting, we can see how other downstreams do it
+<mrueg> add a minimal useflag to system-config-printer-gnome and activate that in kde profile by default?
+<mrueg> minimal useflag triggers the patch
+<johu> mrueg++
+<johu> it would be cleaner to do the split
+<johu> but this would be more effort
+<johu> mrueg: volunteer?
+<mrueg> johu: maybe upstream accepts the patch
+<mrueg> if eta is 1 month + x, i can take a look at it
+<mrueg> otherwise, i'm short on time
+<kensington> it's all one package upstream I think?
+<johu> i guess yes
+<johu> bug 482652
+<willikins> johu: https://bugs.gentoo.org/482652 "[kde overlay] dev-db/virtuoso-server-7.0.0 fails to integrate with akonadi/nepomuk"; Gentoo Linux, KDE; CONF; johannes.hirte:reavertm
+<johu> do we realy need virtuoso-7?
+<kensington> nope
+<kensington> nepomuk is going away
+<mrueg> \o/
+<creffett|irssi> BOOM
+<johu> lets keep the bug open and then last rite virtuoso when nepomuk is gone...
+<creffett|irssi> +1 as virtuoso comaintainer :P
+<mrueg> does it work on x86 anyway?
+<kensington> nope
+<creffett|irssi> nope!
+<creffett|irssi> virtuoso upstream stoped caring about...pretty much anything
+<creffett|irssi> so I'm fine with burninating
+<kensington> we can close that bug, there's no new development of nepomuk obviously
+<creffett|irssi> 14:22 < johu> mrueg: volunteer?
+<creffett|irssi> oops, sorry
+<creffett|irssi> stupid putty paste buffer
+<johu> kensington: yeah but you will always get version bump requests even when it makes no sense
+<kensington> lets move on then
+<johu> but i am fine with it to drop the stuff
+<kensington> there's still the other bug about it open
+<johu> bug 490600
+<willikins> johu: https://bugs.gentoo.org/490600 "kde 4.11.3 missing oxygen theme after update"; Gentoo Linux, KDE; CONF; nikhatzi:kde
+<johu> this is re-occuring with kstyles/qt updates
+<creffett|irssi> what is there that we can do?
+<johu> how about to just add a einfo/ewarn?
+<mrueg> johu++
+<kensington> yeah
+<johu> we would need a eclass/portage mechanism to get this proper fixed
+<kensington> I'm still not sure exactly which package is triggering the breakage though
+<johu> i guess qtgui
+<johu> bug 497314
+<willikins> johu: https://bugs.gentoo.org/497314 "No standard directories created after login to KDE"; Gentoo Linux, KDE; UNCO; oldium.pro:kde
+<johu> kensington: whats to discuss there?
+<kensington> what (if anything) to do
+<mrueg> do we want to add a useflag for that?
+<kensington> if we do /etc/skel we have to coordinate with other desktops
+<johu> kensington: please do
+<johu> its the proper way
+<kensington> or we can copy the env thing from hnome
+<johu> copy & paste is dirty
+<johu> please do the skel way
+<kensington> what package do we put it in?
+<johu> kde-env
+<johu> ?
+<mrueg> sgtm
+<creffett|irssi> sure
+<kensington> we might as well just copy the gnome env file then, it's less copy-and-paste then manually creating a bunch of directories
+<kensington> /usr/portage/gnome-base/gnome-session/files/10-user-dirs-update-gnome-r1
+<johu> ok if you say its easier faster and not that dirty, "Just do it"
+<creffett|irssi> make it so!
+<johu> 6. Elect new lead (10 minutes)
+<mrueg> i'll have to leave now
+<johu> !herd kde
+<willikins> (kde) ago, alexxy, creffett, dastergon, dilfridge, jcallen, jmbsvicetto, jmorgan, johu, kensington, mrueg, mschiff, patrick, reavertm, scarabeus, thev00d00
+<johu> nominees
+<creffett|irssi> I will go again if nobody desperately wants the role
+<mrueg> creffett|irssi++
+<kensington> i nominate johu  too
+<johu> thanks accepted
+<ssuominen> Xfce has the same code as /usr/portage/gnome-base/gnome-session/files/10-user-dirs-update-gnome-r1 in startxfce4
+<ssuominen> at upstream level (where it really belongs)
+<dol-sen> creffett|irssi, but, but, I was hoping you'd be portage lead...;)
+<creffett|irssi> dol-sen: NOPE.
+<kensington> ssuominen: what is your opinion on what we should do, as the resident freedesktop expert :D
+-*- dol-sen goes back into hiding in the corner
+<creffett|irssi> do we have any more nominees?
+<johu> i would nomintate dilfridge but i guess he has enough work with council
+<johu> and he is not here to dis-/agree
+<kensington> yeah
+<creffett|irssi> all right
+<johu> ok do we want to do this via mail?
+<creffett|irssi> then let's vote
+<creffett|irssi> I have no preference
+<johu> i have the feeling that to less people are here...
+<johu> mrueg just left the building
+<creffett|irssi> okay, then I'm good with email voting
+<kensington> ++, I have to go too
+<ssuominen> kensington: got nothing unexpected to say :)  I'd add the file like gnome has, but at the same time, also write a patch that does the same and file upstream ticket
+<johu> creffett|irssi: check please the kde mail alias with herd members...there are some not following the mails
+<creffett|irssi> johu: uh, I can't right now, but off the top of my head reavertm isn't on the list
+<creffett|irssi> and possibly dastergon?
+<johu> creffett|irssi: scarabeus too i guess
+<kensington> scarabeus isn't I think
+<johu> and mschiff maybe too
+<creffett|irssi> yeah
+<johu> so better check
+<kensington> ssuominen: ok, I'll go ahead with that, thanks
+-*- creffett|irssi can't do that until tomorrow night
+<johu> creffett|irssi: yeah lets say let us do the vote within 10 days
+<creffett|irssi> kk
+<johu> 7. Open floor
+<creffett|irssi> nothing here
+<johu> kde 4.12.x target
+<ssuominen> kensington: the problem is that desktops have started relying upon these directories in very early start, so xdg-user-dirs upstream refused the xdg .desktop autostart file for it, with notes that it would then execute too late in the process
+<ssuominen> kensington: so thats why we are stuck at calling the executable like this... otherwise i would have added the .desktop file long time ago
+<kensington> johu: .3 then .5 later?
+<creffett|irssi> good enough for me
+<johu> just 5? :D
+<kensington> + whatever kde-workspaces it is
+<kensington> well, probably arch teams will struggle to do .4 as well
+<johu> do we have any serious blocker left for .3?
+<kensington> not afaik
+<kensington> keywording for minor archs :p
+<johu> as maintainer we can always decide to drop stable keywords
+<johu> the problem is we have no stastics who realy uses kde on ppc,ppc64
+<creffett|irssi> every time we try to drop we get a couple people complaining
+<johu> i dont think it is useless to have them stable, as the kde-stable team has no test plan just a OK and ago only makes build tests on it
+<kensington> I suggest we go ahead with kde-stable asap then CC archs in a week or so
+<johu> kensington: but the good question is which arches? :)
+<kensington> the current ones, we can discuss dropping them if they are still lagging when we want to remove 4.11
+<johu> i dont want to add kde-stable anymore
+<johu> there is no real benefit from the sub-project
+<kensington> I saw some conflict no previous stable bugs
+<kensington> in either case I think we should be good to CC archs ones the 30 days is up
+<kensington> it is working well here, and there have been no bug reprots
+<johu> will create a list
+-*- johu when nobody cries at home
+<creffett|irssi> heh.
+<johu> anything left for open floor?
+-*- creffett|irssi needs to get going, later folks
+<johu> thanks all
+<creffett|irssi> johu: thank you for running the meeting :)
+<kensington> don't forget to review kde-frameworks.eclass, or otherwise be stuck with my awful design until kde 6 :-)
+<johu> kensington: i always review commits
+<johu> kensington: kde-misc/akonadi-git-resource for kde overlay
+<kensington> johu: where does it display it?
+<johu> kensington: extra folder in the left tree view
+<kensington> interesting, I will check it out
+<kensington> oh, kmail...
+<johu> kensington: http://ctrlv.in/311477
+<kensington> I will try kmail again with baloo some time
+<johu> 9999 :)
+<johu> in my opinion we should rename 9999 to 666 :)
\ No newline at end of file