KDE/Meetings/2007 11 28-transcript
From openSUSE
[23:10:46] <Bille> Ok, welcome everybody
[23:11:01] <Bille> everybody from Canada say yeah!
[23:11:40] <Bille> everybody from the USA... say something?
[23:11:41] <Beineri> can we shorten that with "from Americas"? :-)
[23:11:48] <apokryphos> *shocking silence*
[23:12:17] <Bille> duncanmv: you're a south american, say something.
[23:12:54] <Bille> right, let's move on.
[23:13:02] <Bille> Agenda
[23:13:04] <duncanmv> heh
[23:13:07] <Bille> * Old action items
[23:13:13] <Bille> * New action items
[23:13:18] <Bille> ** Challenges
[23:13:22] <duncanmv> I am from the part of america with intelligent life!
[23:13:32] <Bille> "USNAVY" :P
[23:13:36] <duncanmv> LOL
[23:13:47] <dirk> there is intelligent life on earth?
[23:13:52] <benJIman> Falkland Islands?
[23:14:00] <Bille> no, but the chileans think there is.
[23:14:22] <Bille> * Misc
[23:14:35] <duncanmv> anyway, why are you welcoming people
[23:14:40] <duncanmv> I am in the middle of a meeting?
[23:14:41] <Bille> so, I declare the opensuse-kde meeting, "redeye edition" started
[23:15:23] <rabauke> :)
[23:15:25] <Bille> ok.
[23:15:36] <Bille> Old action items
[23:15:47] <Bille> duncanmv: any movement with qtjambi?
[23:17:11] <Bille> if you are stuck we can lend a hand
[23:19:38] <Bille> ok, in parallel: KDE 4 dev pattern
[23:19:53] <Bille> i built KDE4 for joe to demo to customers using it
[23:20:17] <Bille> it was fine, but installed kdelibs4-devel packages
[23:21:11] <Bille> which caused problems for me since I wanted to compile kdelibs itself, and having libs devel stuff in /usr/lib meant cmake complained about ambiguous linking dangers.
[23:21:30] <Beineri> Bille: that bug should be fixed since... Tuesday
[23:21:52] <Bille> Beineri: ok, i was going to ask "maybe we need a KDE4-DEVEL and KDE4-CORE-DEVEL that does not pull any devel above kdesupport?"
[23:22:08] <Beineri> Bille: pardon?
[23:22:14] <Beineri> pattern? package?
[23:22:55] <dirk> is that an old action item?
[23:23:26] <dirk> Bille: I suggest to add it to http://en.opensuse.org/KDE/Meetings/Buildservice_Projects
[23:23:51] <Bille> Beineri: pattern
[23:24:16] <Bille> Beineri: but you say it was a bug that the pattern included devel? it was on tuesday that I encountered it.
[23:24:35] <Beineri> Bille: the current KDE4-DEVEL pattern does not install any devel above kdesupport imo
[23:25:03] <Bille> Beineri: yeah, that's what i read in the .ymp
[23:25:34] <Beineri> Bille: kdelibs4 had a dependency on kdelibs4-devel, I thought you tried installed a non-devel system? why are you talking about the devel pattern?
[23:25:59] <Beineri> and why are we talking about it now when we want to talk about old action items?
[23:26:34] <Bille> Beineri: oh, my old action items are off by one
[23:26:47] <dirk> Bille: bug 344084
[23:26:50] <bugbot> openSUSE bug 344084 in openSUSE 10.3 (KDE) "[KDE 4 RC1 3.96.1-2.2] Many new devel dependancies" [Major,Resolved: fixed] https://bugzilla.novell.com/show_bug.cgi?id=344084
[23:26:52] <Bille> dirk: so repo structure is being developed
[23:27:01] <Bille> ?
[23:28:03] <dirk> Bille: yes, see old action items
[23:28:05] <Bille> dirk: KDE:KDE4:PLATFORM-DEVEL would be the name in plan C
[23:28:47] <Bille> ok,
[23:28:50] <Beineri> dirk: did you post about new structure to mailing list?
[23:28:51] <Bille> old action item:
[23:29:00] <Beineri> structure proposals actually
[23:29:30] <dirk> Beineri: not yet. I fell asleep while trying to write some text into the mail body ;)
[23:29:54] <dirk> lets write a shorter note.. minute
[23:30:57] <Bille> let's assume dirk can do that
[23:30:57] <Beineri> Bille: anything following the colon?
[23:31:07] <Bille> promotion
[23:31:27] <Bille> anyone thinking of any promotional activities for opensuse as a kde platform?
[23:31:47] <Bille> i am thinking about responding to franz keferbock's call for papers for that thing in Bern.
[23:32:10] <mrdocs> one of these days a live DTP disk for Scribus...
[23:33:27] <Beineri> mrdocs: based on 10.3, done with kiwi?
[23:33:48] <mrdocs> Beineri: that's the idea
[23:33:54] <dirk> mrdocs: good idea. do you test the scribus package we have in opensuse?
[23:34:05] <Bille> Beineri: (stop messing with the meeting order, i'm running the show tonight)
[23:34:14] <Bille> mrdocs: great!
[23:34:22] <Beineri> Bille: I don't think that there is an order ;-)
[23:34:33] <mrdocs> dirk: i am afraid not the ones which are shipped, but i did steal a patch from the one in backports :)
[23:35:15] <Bille> mrdocs: it's nice to have informed people like yourself test our packages a bit, in case we broke something.
[23:35:25] <mrdocs> however for a long time we have had good two way feedback from sbrabec, so scribus is in good shape im sure
[23:35:46] <Bille> ok
[23:35:53] <Bille> any other promo activities planned?
[23:36:06] <Bille> Beineri: you'll be going to the kde4 launch party in berlin?
[23:36:24] <Beineri> There is one? I only read about Hamburg
[23:36:25] <dirk> mrdocs: ah, too bad. just FYI, the suse internal maintainership of scribus moved from sbrabec to me
[23:36:29] <mrdocs> will there be a kde 4 party in .fr or .be ?
[23:36:36] <Bille> it's moving to Berlin afaik
[23:36:47] <Bille> mrdocs: i think the toulouse gang will do something
[23:36:51] <mrdocs> dirk: i can easily give it a QA session tho
[23:37:02] <Beineri> Bille: maybe :-)
[23:37:25] <dirk> mrdocs: that would be great, or if you have any feedback/comment/patch to add to the package, just drop me a note
[23:37:33] <mrdocs> NP
[23:37:40] <dirk> mrdocs: I don't know of a bugreport against scribus atm though
[23:37:54] <mrdocs> there aren't - i checked :)
[23:38:21] <dirk> mrdocs: you should file one to add scribus to one of the installation patterns ;)
[23:38:55] <mrdocs> let me get the DTP image and then it will make sense to have a "publishers" pattern
[23:39:12] <mrdocs> or something like that
[23:39:30] <dirk> mrdocs: yes.. just need to find a good name for the pattern
[23:39:44] <mrdocs> OT is m fabian on irc often ?
[23:39:49] <dirk> mrdocs: by design there are supposed to be many patterns
[23:40:14] <dirk> mrdocs: not regularly, I can ask him to join though if you want to
[23:40:22] <dirk> mrdocs: he's on vacation atm though
[23:40:52] <mrdocs> no i can mail him.. nothing urgent... just i have some fonts which should go in 11
[23:41:02] <mrdocs> OFL licensed good quality
[23:41:09] <dirk> oh, he's going to love that ;)
[23:41:15] <dirk> drop him an email then
[23:41:58] <mrdocs> kde4 question: is there or will there be an option to have old style menu ?
[23:42:14] <dirk> Bille: I would suggest to add this action item to the KDE/Challenges page and continue
[23:42:39] <dirk> mrdocs: not yet, the code isn't there. if there is demand, perhaps.
[23:42:48] <Bille> dirk: nod
[23:42:50] <mrdocs> fair enough
[23:43:09] <mrdocs> JFYI okular rocks
[23:43:09] <Bille> dirk: status of relicensing?
[23:43:30] <Bille> mrdocs: and if you want to hold a party, just do it (tm)
[23:43:41] <dirk> http://techbase.kde.org/Projects/KDE_Relicensing
[23:44:05] <dirk> about 10% down in the last week
[23:44:08] <Beineri> what about "Do more talks/workshops at Linux events"? FOSDEM 2008?
[23:44:30] <dirk> although last night we got some new files that fail the test. kopete stuff as usual
[23:44:31] <Bille> Beineri: we have moved on!
[23:44:54] <Beineri> Bille: no comment
[23:44:54] <dirk> Beineri: drop a mail to opensuse-kde, invite possible speakers directly.
[23:45:40] <Bille> dirk: new files in svn or new files showing up on the license check script?
[23:45:49] <dirk> Beineri: you want to volunteer for the action item?
[23:45:58] <Beineri> dirk: we have moved on!
[23:46:30] <dirk> Bille: I'm not sure, there is some flakyness in krazy2, which the check is based on
[23:46:48] <Bille> afaics no new files were added yesterday...
[23:46:58] <dirk> I'm still debugging the reporting, but its perl, and its not written by me
[23:47:30] <dirk> 
[23:47:37] <dirk> I think its clear that we make more progress than ever before
[23:50:08] <Bille> ok, next topic?
[23:50:25] <Bille> Beineri: ready to go?
[23:51:31] <Bille> Beineri: i have done some integration work
[23:51:47] <Bille> linked the cookbook from the specfile guide
[23:52:14] <dirk> Bille: what is the next topic?
[23:53:35] <Bille> dirk: my progress on kde 4 development topics
[23:54:17] <Bille> top of the spec files
[23:54:22] <Beineri> ah
[23:56:27] <Bille> so, next thing:
[23:56:55] <Bille> KDE on 11.0 planning
[23:57:00] <Bille> any motion
[23:57:38] <Bille> ?
[23:57:39] <Beineri> we have to talk to desktop proj manager and product management
[23:57:51] <cb400f> someone please tell coolo to forget about April release :-)
[23:58:04] <Beineri> cb400f: of KDE 4.0? :-)
[23:58:10] <cb400f> of 11.0
[23:58:25] <Beineri> cb400f: I haven't heard about a April release of 11.0 :-)
[23:58:43] <dirk> cb400f: latest rumours are around June 2008
[23:58:51] <dirk> cb400f: april is feature freeze, do you mean that?
[23:59:05] <cb400f> "And the target defined by the project is 6-9 months after the last release, so that makes april to july 2008."
[23:59:07] <rabauke> when will kde 4.1 be released?
[23:59:26] <Beineri> rabauke: can you first tell when will 4.0 be released? :-)
[23:59:30] <cb400f> from factory..
[00:00:10] <dirk> Beineri, Bille: there is a fate tracking KDE 4.0 integration status, I guess its time to reopen it for 11.0 ;)
[00:00:12] <rabauke> Beineri: ok, let's put it differnetly. will kde 4.1 be part of 11.0?
[00:00:37] <Beineri> rabauke: when the schedules of both projects allow that, yes :-)
[00:00:59] <Beineri> rabauke: but it's difficult to tell when neither is fixed yet :-)
[00:01:07] <dirk> cb400f: ok, that matches it mostly. there is really not more planning about a date going on yet. also, feedback from the community is currently being requested
[00:01:09] <rabauke> true
[00:01:29] <dirk> rabauke: lets put it differently: what do you expect from 4.1 or 11.0 ?
[00:01:43] <dirk> I think thats the topic we should discuss, rather than juggling with dates where we have no influence on
[00:02:07] <dirk> our main goal for KDE 4 as default KDE desktop is: no feature regressions
[00:02:18] <dirk> now, given that this is hard to achieve, we have to know which features are more important than others
[00:02:19] <rabauke> 11.0 to bring some major change in KDE for example and KDE 4.1 to be closer to 3.5's features and stability/speed.
[00:02:25] <dirk> thats where we need input on
[00:02:37] <dirk> what is a feature of KDE 3.x that has to be preserved for 11.0 ?
[00:02:46] <cb400f> yakuake :-)
[00:02:56] <rabauke> dirk: flags for removable devices
[00:03:16] <dirk> rabauke: --verbose? which flags? mount flags?
[00:03:18] <Beineri> cb400f: dunno if porting of that even started: http://techbase.kde.org/Schedules/KDE4/Application_Porting_Status
[00:03:50] <rabauke> dirk: the tab in the device's properties. upstream does not seem to have that.
[00:05:48] <Beineri> dirk: all of the default kde3 desktop functionality and apps as of 10.3 should be available/preserved imo :-)
[00:06:06] <dirk> rabauke: indeed, its a suse feature
[00:06:10] <Beineri> which means that very much is missing :-(
[00:06:13] <dirk> Beineri: you're too unspecific
[00:06:26] <dirk> a simple topic is: KDE 3.x patch review?
[00:06:39] <dirk> how are we going to review the list of patches and which have to be ported/thrown/away etc?
[00:06:57] <dirk> did anyone play with the osc plugins for patch annotation?
[00:06:58] <rabauke> dirk: where is such a list?
[00:07:28] <dirk> rabauke: ls -lR | grep '(patch|diff)' in the right directory :)
[00:07:52] <dirk> I can paste it into a wiki page if wanted.. but I'm not sure if its the best way to move forward
[00:08:06] <dirk> we can also go the slow way and only port patches where we get bugreports again
[00:08:07] <rabauke> if you want feedback on what is needed you have to tell what of their KDE is not in upstream
[00:08:49] <duncanmv> Bille: i have a new spec from helio to try out, but I havent done that yet, I am busy with yast-qt4
[00:08:57] <Bille> ok
[00:09:19] <duncanmv> http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/qtjambi/current/
[00:11:53] <rabauke> nothing else to talk about?
[00:12:05] <rabauke> or are us eurpeans getting too tired
[00:12:23] <Bille> KDE/GNOME packaging day.
[00:12:27] <Bille> (yawn)
[00:13:06] <dirk> * wiki page: http://en.opensuse.org/Packaging/Packaging_Day
[00:13:17] <dirk> * news entry: news.os.org
[00:13:22] <apokryphos> woo
[00:13:27] <dirk> * t-shirts organized
[00:13:40] <dirk> * beineri started a package list I think
[00:13:47] <Beineri> ?
[00:13:59] <dirk> outstanding todo's:
[00:14:18] <dirk> * ask more people to join. especially people doing non-openSUSE ports of build service packages
[00:14:39] <dirk> * define rating categories for the t-shirt candidates
[00:15:08] <dirk> any feedback on how to invite non-opensuse packagers or non-packagers to the event?
[00:15:38] <dirk> any feedback on the current list of categories (see http://en.opensuse.org/Packaging/Packaging_Day#Win_an_openSUSE_T-Shirt)
[00:16:26] <Beineri> "most spectacular failure"? :-)
[00:16:44] <Beineri> that was the best hack week category
[00:17:54] <rabauke> is there anything regarding me? I woud have to leave, if there is nothing important.
[00:18:16] <dirk> Beineri: okay, noted
[00:19:01] <toma> - if not done already - rsibreak(3) and mailody(3) would be good candidates to package maybe
[00:19:05] <Beineri> rabauke: but we can add that once you're away :-)
[00:19:05] <dirk> rabauke: no feedback regarding the meeting time ? ;)
[00:19:23] <Bille> toma: k
[00:19:30] <rabauke> dirk: no one from americas around, so change it back to european time
[00:19:32] <Beineri> toma: mailody is iirc in KDE:Playground and kde4-rsibreak and rsibreak exist too
[00:19:35] <dirk> toma: rsibreak is there, mailody also (but not building)
[00:19:56] <dirk> toma: would you help improving the packaging of the mailody in KDE:KDE4?
[00:20:00] <rabauke> Beineri: I expected expressions of annoyance about me rerporting bugs, but nor jokes :p
[00:20:27] <Beineri> dirk: what mailody version are you talking about? all green: https://build.opensuse.org/project/monitor?project=KDE%3APlayground
[00:20:53] <toma> dirk: i lack time and an image to really help, kde4 mailody sshould be ignored for now
[00:21:38] <Bille> any more topics?
[00:21:53] <toma> dirk: i've two patches for kde3 mailody though, although we/you are getting OT now
[00:22:16] <Beineri> toma: shall I add you to the mailody package in KDE:Playground? :-)
[00:22:44] <toma> i've no idea what that means
[00:23:07] <Beineri> toma: you can add patches/update version with your build service account yourself
[00:23:24] <haw> gute Nacht ihr Lieben
[00:23:25] <Beineri> can move that also to KDE:Community
[00:23:56] <dirk> toma: ah, kde3 version. okay.
[00:23:57] <toma> Beineri: i've never done anything with build service, but i like to try it out sometime
[00:24:07] <dirk> toma: then this weekend is your chance ;)
[00:24:10] <Beineri> toma: how about on Friday or saturday :-)
[00:24:13] <dirk> rabauke: good night, see ya!
[00:25:03] <Beineri> or anytime (well, day-time mostly) else here
[00:25:15] <dirk> Bille: are we done with the old action items?
[00:25:21] <Bille> yep
[00:26:00] <dirk> * Pulling more home:* community packagers in to KDE:Community (all)
[00:26:17] <Beineri> -> Packaging days :-)
[00:27:09] <dirk> http://en.opensuse.org/KDE/Challenges
[00:27:31] <Beineri> did anyone except me look at/chat that? :-)
[00:27:32] <dirk> duncanmv: is there anything to say about the yast qt4 frontend now that you're busy about it?
[00:27:40] <Beineri> s/chat/changed/
[00:27:44] <dirk> Beineri: I looked at it, its a very good brain dump
[00:27:52] <dirk> Beineri: didn't find anything to modify though
[00:28:09] <dirk> Beineri: though Ithink we should highlight a few items and put them up as discussion items one after the other in the irc meetings
[00:28:15] <mrdocs> i'll try to package Qtpfsqui from the KDE wishlist it builds cleanly here
[00:29:16] <mrdocs> vowels ?
[00:29:35] <Beineri> mrdocs: yeah
[00:30:01] <mrdocs> try speaking Welsh or some words in Breton.. almost as bad ;-)
[00:30:14] <benJIman> Welsh has even more vowels.
[00:30:18] <benJIman> y is a vowel in welsh.
[00:30:36] <benJIman> And they have pro-letters like "ll"
[00:30:47] <mrdocs> iirc it is in Breton and Cornish
[00:30:59] <dirk> mrdocs: great. do you have access to KDE:Community?
[00:31:03] <dirk> (is it Qt or KDE?)
[00:31:17] <mrdocs> Qt4
[00:31:43] <Beineri> if anyone is bored by this meeting ;-), there is an untested 0.7.1-test.iso of kde four live with 3.96.2 packages in the usual directory... will likely change later today though
[00:31:50] <dirk> so that means we shouldn't split buildservice repos in qt only and kde apps
[00:32:09] <dirk> although splitting them in those that need an updated qt and those that doesn't might make sense
[00:32:35] <mrdocs> dirk exactly
[00:32:51] <metavoid> i second this
[00:32:56] <mrdocs> i have one in my repo which is qt4.3 only
[00:33:03] <metavoid> but why doesn't it make sense?
[00:33:26] <dirk> mrdocs: hmm, which part of my thoughts are you referring to exactly?
[00:33:29] <dirk> metavoid: and you.. ? :)
[00:33:51] <mrdocs> dirk: although splitting them in those that need an updated qt and those that doesn't might make sense
[00:34:16] <mrdocs> some qt4 apps will only work with qt4.3.. not all but some
[00:34:25] <metavoid> dirk: i think we need two repos for Qt apps - for those that need the latest version of the library, and for those that don't
[00:34:33] <mrdocs> exactly
[00:34:45] <dirk> okay.. somebody should add that to the wiki
[00:34:51] <dirk> I agree, though I have one problem with it
[00:35:02] <mrdocs> dirk: im on backports not community
[00:35:13] <dirk> should KDE try to build against the repo that has an updated Qt, or against the distribution repo ?
[00:35:20] <dirk> or should we provide both? ;)
[00:35:26] <mrdocs> KDE4 ?
[00:35:33] <dirk> yes
[00:35:40] <dirk> there aren't any Qt 3.x updates
[00:35:55] <metavoid> i'm not sure about this, never packaged a single KDE4 app
[00:35:59] <mrdocs> same
[00:36:18] <mrdocs> i just test the OBS stuff when time allows
[00:36:35] <dirk> okay.. great :)
[00:36:36] <mrdocs> like tonight :)
[00:36:59] <dirk> another random question: would you prefer to keep the stuff you package in your home directory, or add it to one common repository?
[00:37:07] <dirk> one of the bigger quesetions is
[00:37:41] <dirk> a) a small group of people link packages from home: projects into "common" projecs that are advertised according to criteria (like: addon, stable, playground)
[00:38:00] <metavoid> dirk: sure, home projects are not a suitable place for stable application, one can't trust them
[00:38:01] <dirk> b) or there are many projects where everyone interested have acces to it and can do what they want
[00:38:23] <dirk> metavoid: there's a problem with that
[00:38:33] <metavoid> I thought the policy is to move packages form home repos ASAP, am I wrong?
[00:38:38] <dirk> the buildservice designes trust relationship as part of the project
[00:38:53] <dirk> so if you have in home:foo one unstable and one stable package, what is the trustlevel of home:foo ?
[00:39:21] <dirk> metavoid: yes.. overal problem remains the same
[00:39:25] <metavoid> home projects have zero trust level
[00:39:46] <dirk> there might be packages in kde:playground that deserve higher trust level
[00:39:58] <dirk> and some in kde:backports that deserve lower (though we try to reduce that atm)
[00:40:33] <dirk> it also puts us in the position of having to judge if random contributor foo is allowed to access kde:playground or also kde:coolstuff
[00:41:01] <dirk> I would rather like to externalize that, e.g. via the rating system that is slowly appearing in the buildservice
[00:41:04] <mrdocs> dirk: is there any QA on KDE:Comminuty ?
[00:41:32] <dirk> mrdocs: only the packager self-done QA, nothing more
[00:41:39] <dirk> or possible user feedback
[00:42:00] <mrdocs> that might be a nice tasklet ....
[00:42:07] <dirk> --verbose?
[00:42:44] <mrdocs> just some simple sanity checks on the spec file... we *all* make mistakes, so a peer review there would be a good thing
[00:42:57] <mrdocs> some folks are better than others at it i know
[00:43:03] <dirk> oh, you'ree saying about build checks?
[00:43:24] <dirk> bug 297050
[00:43:27] <mrdocs> 1. review the spec file for sanity eg
[00:43:28] <bugbot> openSUSE bug 297050 in openSUSE.org (BuildService) "rpmlint integration" [Enhancement,New] https://bugzilla.novell.com/show_bug.cgi?id=297050
[00:43:33] <metavoid> what do you think about making KDE:Community repository restricted?
[00:43:55] <mrdocs> 2. confirm md5sum/sha1sum on the source
[00:44:31] <dirk> metavoid: restricted in which way? who would be allowed to edit it and what?
[00:44:35] <mrdocs> 3. basic check for install e.g. no broken scriplets, desktop file is ok..
[00:44:57] <dirk> mrdocs: wow, very good points
[00:45:00] <dirk> about 1)
[00:45:02] <mrdocs> eg
[00:45:11] <metavoid> dirk: I mean restricted access for packagers
[00:45:11] <dirk> how do you think we should do spec file reviews?
[00:45:12] <mrdocs> rpm -ivvh foo
[00:45:16] <mrdocs> then
[00:45:23] <metavoid> dirk: to increase the quality
[00:45:30] <mrdocs> rpm -evv to make sure its a clean removal
[00:45:33] <dirk> when somebody asks for it? when something is changed in a spec file?
[00:45:49] <dirk> voluntarily? or forced review?
[00:46:02] <mrdocs> dirk i can make a simple list and add it somewhere on the wiki
[00:46:12] <dirk> mrdocs: that would be awesome
[00:46:14] <mrdocs> "How to QA an rpm
[00:46:49] <mrdocs> ok consider it done in the next few days
[00:46:49] <dirk> mrdocs: some background information.. suse packagers have forced review
[00:46:59] <dirk> mrdocs: where do you put it? I want to watch the page
[00:46:59] <mrdocs> i hope :)
[00:47:10] <Bille> dirk: some kind of auto generated list of spec files needing review
[00:47:24] <Bille> that can be marked as "reviewed 20071129 by dirk"
[00:47:27] <dirk> mrdocs: and we have many automated checks, e.g. the rpm -i/-e check
[00:47:45] <Bille> and with some indicator "n months, m changes since last review"
[00:48:26] <dirk> mrdocs: hmm, perhaps you can paste it into the bugreport I quoted above?
[00:49:23] <dirk> mrdocs: however, I think forced review is a bad approach for the build service
[00:49:38] <dirk> mrdocs: I would rather go the other way around.. voluntary review or testing increases package rating
[00:50:27] <metavoid> which leads to the above mentioned trunsting system in BS
[00:51:14] <dirk> metavoid: okay. your suggestion is that only few people / packages can be in kde:community, and the rest has to be in kde:playground
[00:51:17] <dirk> or something like that?
[00:51:31] <mrdocs> http://en.opensuse.org/Doing_A_Self_Check/QA_for_RPMS
[00:51:32] <dirk> one question: how do packages move from playground to community?
[00:51:40] <metavoid> dirk: something like this
[00:51:51] <metavoid> or even in home projects
[00:52:21] <Bille> one could come up with some formula like (positive reviews)/(months since last review) to create a value to add into the trust rating.
[00:52:29] <dirk> mrdocs: hmm. can you move it under /Packaging/ perhaps?
[00:52:41] <dirk> mrdocs: I sort of own /Packaging (because noone else cares ;) )
[00:52:56] <metavoid> dirk: more experiened packagers do some spec/(code?) review and move a package to :Community
[00:54:16] <dirk> metavoid: okay.. consider thats possible
[00:54:29] <dirk> metavoid: what would be the criteria for being eligible to KDE:Comunity?
[00:54:40] <dirk> * builds on maintained openSUSE_*
[00:54:50] <dirk> * spec file doesn't do obviously bad stuff
[00:54:56] <dirk> * source isn't hacked
[00:55:12] <dirk> * it doesn't crash when starting up
[00:55:48] <mrdocs> dirk: one
[00:55:50] <mrdocs> done even
[00:55:55] <mrdocs> http://en.opensuse.org/Packaging
[00:56:03] <mrdocs> http://en.opensuse.org/Packaging#Doing_A_Self_Check.2FQA_for_RPMS
[00:56:11] <dirk> the first two are easy to test, point 3/4 is difficult
[00:56:24] <mrdocs> I'll start fleshing this out in the next few days
[00:56:57] <dirk> mrdocs: excellnt, thanks
[00:57:08] <dirk> mrdocs: ping me if you want comments, rants or encouragement ;)
[00:57:12] <metavoid> well, the third one is extremely difficult
[00:57:15] <mrdocs> i will
[00:57:39] <mrdocs> #3?
[00:57:46] <metavoid> maybe this will depned on package rating
[00:58:09] <metavoid> if a package is well-rated then it can be moved to Community
[00:59:40] <dirk> possibly this should be integrated into the package installer
[00:59:42] <mrdocs> one thing i wish rpm had was a place to put md5sum/sha1sums in the spec file besides a comment
[00:59:53] <yaloki> dirk: what a terrible idea ;)
[01:00:00] <metavoid> huh, tha'll be way too annoying
[01:00:53] <dirk> mrdocs: doesn't solve it, you need openid or pgp based web of trust
[01:01:03] <dirk> just another sha1 comment doesn't fix anything ;(
[01:01:13] <mrdocs> i know :S
[01:01:36] <mrdocs> dirk: seen this ? http://dev-loki.blogspot.com/2007/11/opensearch-for-opensuse-package-search.html
[01:01:49] <yaloki> hey
[01:01:54] <mrdocs> might be a nice tweak for 11
[01:01:58] <yaloki> :D
[01:02:10] <dirk> yaloki: hey.. I said its a crazy idea.. I still like it though.. doesn't have to be annoying
[01:02:21] <yaloki> hmhmhm
[01:02:26] <mrdocs> yah bastid... .be does not allow patents :P
[01:02:40] <yaloki> I don't see how one could avoid being annoying with a thing like that ;)
[01:02:56] <yaloki> the repo refresh progress popups are already annoying as hell though, a bit more or a bit less ;D
[01:03:00] <mrdocs> better is a feedback link next to the .ymp
[01:03:35] <cb400f> can people rate it before they've tried it?
[01:03:57] <yaloki> cb400f: hmh.. really difficult to track
[01:04:16] <yaloki> cb400f: oh btw, planning to come to brussels end of february 2008 ? ;)
[01:04:16] <Bille> cb400f: have another yast module that allows feedback on installed packages.
[01:04:20] <cb400f> would be nice to have a link in the "About" dialog, or something.. but that would prolly be too difficult and much work
[01:04:47] <Bille> and nobody would find it
[01:05:00] <Bille> but a feedback yast module would be nice and obvious
[01:05:13] <cb400f> maybe integrated in sw_single..
[01:05:13] <mrdocs> if people are pissed they usually can find someone to complain to
[01:05:39] <yaloki> mrdocs: hmmm... yes. but when they're happy, they (almost) never tell
[01:05:42] <dirk> yep, but the reverse isn't true
[01:05:49] <yaloki> precisely
[01:06:01] <mrdocs> yaloki: if im not in the US i will be at FOSDEM
[01:06:04] <yaloki> a very simple way to give positive feedback would be very interesting
[01:06:10] <yaloki> mrdocs: cool :)
[01:06:12] <Bille> ok, so you accept ratings from people who package
[01:06:19] <dirk> so we make it positive by adding the "pet the packager" button
[01:06:25] <Bille> that way you get 'useful' ratings
[01:06:28] <benJIman> yaloki: It can be quite unobtrusive, star thing in the listview.
[01:06:32] <yaloki> "donate a beer" button
[01:06:38] <yaloki> benJIman: true
[01:06:42] <Bille> and in turn, people's personal rating is enhanced by their rating other packages.
[01:06:58] <yaloki> Bille: not sure a packager's rating is that important though
[01:07:26] <Bille> yaloki: you mean, the rating a packager gives or the rating a packager has?
[01:07:44] <yaloki> Bille: I mean.. you can look at the spec and see some oddly done things but that doesn't often have direct consequences on the quality of the package; it's rather about the maintainability
[01:07:50] <yaloki> Bille: gives
[01:08:05] <yaloki> feedback from users >>> rating by other packagers
[01:08:49] <yaloki> (IMHO)
[01:08:49] <dirk> feedback from qualified users >>> feedback from any user
[01:08:57] <yaloki> myeah
[01:08:59] <yaloki> depends
[01:09:18] <yaloki> with GUI apps the feedback from unexperienced users can already help
[01:09:26] <yaloki> at least to see whether it actually works or not
[01:09:37] <yaloki> that's still more valuable than spec reviews
[01:09:38] <Bille> go to geizhals.at, there are a lot of crap ratings on hardware just because people bought something.
[01:10:17] <yaloki> the problem is differentiating between bad packaging/bad integration and upstream bugs
[01:10:38] <yaloki> but still, even with upstream bugs, it gives a possibly valuable information to other users
[01:10:39] <Bille> which takes a packager's eye
[01:10:48] <yaloki> yep
[01:11:02] <dirk> yaloki: well, if there are highly visibly upstream bugs, then those are also packager bugs
[01:11:17] <dirk> so its not that extremely important to distinguish both
[01:11:26] <yaloki> myeah
[01:11:56] <dirk> so, we're heading to something like debian testing
[01:12:07] <dirk> e.g. new packages from unstable enter testing after X days
[01:12:14] <dirk> * with no new changes
[01:12:23] <dirk> * with no major bugs filed against the new package
[01:12:31] <dirk> * no unresolved or conflicting dependency
[01:12:47] <yaloki> I don't think the debian testing method is bad per se
[01:12:54] <yaloki> it's quite good actually, at least on paper
[01:13:02] <dirk> yaloki: oh, I didn't say that. quite the contrary
[01:13:11] <yaloki> the question is really how to implement that and still have recent packages
[01:13:30] <yaloki> a more pragmatic approach is probably already sufficient to achieve that
[01:14:08] <Bille> positive reviews accelerate progression?
[01:14:11] <yaloki> dirk: your email about OBS repo reorganization.. just for KDE or all of them ?
[01:14:22] <yaloki> Bille: yeah, I guess..
[01:14:36] <Bille> I'm going to bed.
[01:14:40] <yaloki> n8 Bille
[01:14:52] <mrdocs> soon for me too
[01:14:53] <dirk> yaloki: I don't mind producing a global picture, but my target is KDE
[01:15:03] <yaloki> hm, ok...
[01:15:14] <yaloki> I wrote a few emails on that topic a month ago or something
[01:15:14] <dirk> so who's the MC then?
[01:15:56] <Bille> dirk: if you have anything else to discuss: you
[01:16:05] <Bille> otherwise i will put this suckah to bed
[01:16:12] <Beineri> dirk is likely the most one awake standing ;-)
[01:16:33] <yaloki> dirk: http://lists.opensuse.org/opensuse-buildservice/2007-10/msg00133.html
[01:16:48] <yaloki> dirk: might want to skim through it for a few ideas
[01:16:54] <mrdocs> this is like a #scribus dev meeting.... most of the chat never begins until ~ 0000 :)
[01:17:12] <yaloki> mrdocs: productivity starts at 0000 ;P
[01:17:35] <dirk> Bille: well, given that I read that you organized the meeting, you should at least announce the next meeting date and time and close the topic
[01:17:45] <dirk> yaloki: looking
[01:18:24] <Bille> "The meeting is over."
