*jpr has changed the topic to: Meeting in progress | http://en.opensuse.org/GNOME/Meetings/20071011 | http://en.opensuse.org/GNOME *forcev is now known as FunkyPenguin <jpr> Good morning/evening/afternoon everyone! <jpr> welcome to the openSUSE GNOME Team project meeting *Riggwelter arrives just in time :) <jpr> this is our third meeting <jpr> and I'd like to to take this time <jpr> to review how our meetings operate <jpr> and address any concerns <jpr> i think there are a couple of key issues <jpr> 1) length of meeting <jpr> 2) format of meeting <jpr> 3) frequency of meeting <jpr> 4) target audience <jpr> maybe we should discuss the last point first

<jpr> we discuss both hardcore development and "softer" but very important tasks here <jpr> should we alternate that? <jpr> is both together good? <captain_magnus> No <captain_magnus> Both is good *jpr throws the floor open *btimothy thinks is good like it is <FunkyPenguin> a mix is pretty good <captain_magnus> But I think it needs to be structured to reflect that in the agenda *Riggwelter thinks a mix is good <FunkyPenguin> it gives those that arent hardcore the insight as to what is need to be a true opensuse-gnome hacker :) *mauropm thinks the mix gives a bigger picture <captain_magnus> So either have the "hardcore dev" first and then the "soft" or the other way around... *hpj mix <jpr> ok, pretty good consensus <sreeves> I like the mix as long as its preplanned on the agenda, so people can follow the parts they want <mw> mix. <jpr> any one have alternate opinions? <captain_magnus> My feeling is that the hardcore dev is taking the longest so should be last (but after Q&A) <btimothy> and possibly outside the 1hr. meeting <jpr> ok, fair enough <hpj> agree with captain_magnus - hardcore last <gekker> yeah, mix it up <Riggwelter> captain_magnus: +1

<jpr> lets jump to meeting format then <jpr> ie item 2) <jpr> does the meeting format allow enough participation <jpr> and alternate ideas to get floated? *jpr opens floor <Riggwelter> has seemed so so far <jpr> is it friendly enough to new contributors? <captain_magnus> I think that it does thanks to the task review and q&a <mtgordon> The nice thing about IRC (vs. phone, for example) is that it's hard to step on what someone else is saying (though interleaved lines are possible). <hpj> hard to say - we're not seeing a lot of different people talking yet <jpr> one thing thats come up before is having an intro to your section <jpr> hpj: ok, why not then <captain_magnus> Perhaps silly but if we start with q&a, then anyone can participate? <jpr> maybe we should make sure we have a c/p canned intro <hpj> jpr: i suspect it's just because the meetings attendance is still a bit low <jpr> for say bug plan *FunkyPenguin thinks that the group makes it easier for contributers not just the format - one big happy family :) <mw> c/p? <hpj> cut/paste <jpr> cut and paste <mw> oh, right. duh <jpr> captain_magnus: oh, that would be an interesting thing to try <jpr> it sounds like some experimentation with meeting order is in order at least <sreeves> hrmm, I think that would lead to a lot of questions with the answer being "thats planned for later" <jpr> what about theming the meetings sometimes <jpr> ? *fede has quit ("I'm gone") <hpj> theming is a cool idea <jpr> "Today is no question is too silly QA" <captain_magnus> How about "General", "Q&A" first, then "Development", "Q&A"? <jpr> (and hey, use that to boot strap a FAQ) <gekker> i like the idea of theming the meeting <btimothy> I'd like it if Q&A were mostly started in the meeting agenda ahead of time <btimothy> so we'd be able to know abt. how long q&a might take <jpr> how about we take a couple of action items <sreeves> the theme idea could help keep the time of the meeting right - as we could push non theme items to the next meeting <btimothy> at least for general q&a <jpr> AI: experiment with ordering <captain_magnus> I mean, go through the soft topics first, have a q&a on them... Then the devs can talk about their stuff and have another q&a... <jpr> AI: experiment with themes <jpr> does someone want to own that? <captain_magnus> But then again, what's "soft"? :-) <jpr> well, further along i would say it does *not* include things like divvying up pulse integration work <jpr> or discussing packaging policy details <captain_magnus> jpr: Our tasks page could be the fundation for the theme? <jpr> captain_magnus: yes, could be <jpr> sounds like you want to own the meeting format AI's :-) <captain_magnus> *gone* <captain_magnus> :-) <jpr> it would be great if you would take them <captain_magnus> jpr: Sure, I'll give it a try <jpr> so i think consensus is we should group the dev/non-dev <jpr> and experiment with ordering a bit <jpr> to make it easier for new people to get into the meeting <jpr> any differing opinions? <jpr> ok

<jpr> length and frequency of the meeting <jpr> i like weekly meetings <jpr> but i would like it more if they were 1 hour or less <jpr> :-) <btimothy> I like weekly meetings too <btimothy> past 1 hour gets too long <Riggwelter> I'd say either weekly but shorter (1hr max) or less frequent but longer than an hour <jpr> (also in here we should discuss altering the times a bit) <hpj> i think we should shoot for 45 minutes <jpr> (or rather alternating meeting times) <jpr> hpj: plus Q&A? <hpj> jpr: yeah <jpr> what happens if we go over? <jpr> do we push agenda items to the following week? <btimothy> target 45 ... max out at 1hr? <hpj> we adjourn the meeting and people can keep talking to each other if they want <jpr> or do we approximate times on the agenda and wrap individual things up on time? <jpr> ie Meeting Format discussion (10 minutes) <Riggwelter> jpr: that could work <captain_magnus> I like weekly meeting but I don't like the time constraint... I think that for the next few weeks/month, we need to let it take the time it takes to get through... Eventually, it will settle and we can say that a meeting should take 45 mins, 1 hour, 1 1/2 or whatever <jpr> the nice thing about that is it forces action items and a wrap up <hpj> i like that <jpr> give some closure no matter what <hpj> individual wrap up times <jpr> captain_magnus: yes, i also have a theory that we spend a lot of time now because we have like 8 big things to do to bootstrap the project <jpr> and we won't a month or two from now <btimothy> yeah, if an item needs more discussion, it can either be pushed to next mtg. or just wait 'til after the meeting and involved people can still chat/discuss as needed. <captain_magnus> jpr: I feel that the project meetings are very stressed because people wants to go home so lots of things are left unanswered... <captain_magnus> Not everyone can type as fast as the moderator etc <jpr> could be true <captain_magnus> So I would stronlgy suggest that we let it take more than one hour if needed to start with <jpr> captain_magnus: maybe we can allow for extensions if people really want to air the issue <captain_magnus> And once we settle, then we can decide <jpr> so I'm hearing two options <mtgordon> It's not like someone else has the meeting room booked after us. <jpr> set times for individual items (with possible extensions) <captain_magnus> jpr: Sure... We can have sort of time lines on the agenda... But if need be, we should extend <jpr> or review the meeting lengths in say <jpr> 3 more meetings <jpr> other comments? <jpr> should we experiment with individual times one meeting? <Riggwelter> I think so <jpr> to form a more informed opinion <hpj> let's do it <Riggwelter> else we're shooting in the dark <btimothy> each agenda item could write down their guess at how long they'll need beforehand? <jpr> AI: experiment with individual times *Iznogood (n=Iznogood@85.19.141.204) has joined #openSUSE-Gnome <captain_magnus> We have three meeting when this is done... We can go back and review how long each subject takes etc <jpr> AI: review meeting format in 3 more meetings <jpr> captain_magnus: good idea *jpr sees captain_magnus becoming our Emily Post of meetings <sreeves> I prefer bumping items than hard artificial time constraints on each item, as long as the moderator is active in not letting an item get too out of hand <jpr> i think we should all degree captain_magnus Meeting Master <mw> captain_meetings? <captain_magnus> Great, next meeting will be 6pm *my* time :-) <mauropm> =) <Riggwelter> lol <jpr> sreeves: would the experiment work than as a test? <jpr> meeting time is an issue <jpr> main opensuse project meetings <jpr> are going to rotate times occasionaly <jpr> to pick up people in Asia and Australia <jpr> is that something we should consider <Iznogood> only seems fair <jpr> once a month <jpr> or something? <Riggwelter> good plan *captain_magnus agrees with a smile <hpj> fine with me <jpr> any differing opinions? <jpr> the one con i can think of <jpr> is that people now just know when to show up <mw> meeting times have to stink for some of the people some of the time <jpr> however <jpr> it think its far outweighed <jpr> by the number of potentional people <jpr> we could reach <jpr> so, AI: rotate meeting times once a month for Asia/Australia <jpr> ? <Riggwelter> agreed <captain_magnus> +1 <mw> yes <sreeves> sounds good <jony> +1 :) <mtgordon> Rotate how? By 12 hours? <jpr> still some middle ground *btimothy -1 ... likes consistency ;) <jpr> something like +8 <captain_magnus> mtgordon: Set it back with 4 hours or forward with 6+ hours... <jpr> or - 4 <Riggwelter> jpr: If you make it the first meeting of each month, makes it easier for ppl to remember <jpr> yes <jpr> ok <jpr> did we all agree weekly is still good? <jpr> at least for now? <sreeves> yes <captain_magnus> Agreed <btimothy> Riggwelter: ah, good suggestion ... consistently the first mtg. or something like that :) <btimothy> first mtg. of the month <jpr> ok <jpr> revised action <captain_magnus> Can we also have everyone to mention their timezone before they leave so that we can trial a different time once a month and if it should be -4 or +6 or more hours <jpr> AI: : rotate meeting times once a month for Asia/Australia, the first meeting of the month *JLS (i=jls@nat/novell/x-de65468673c39e59) has joined #opensuse-gnome <jpr> ok <jpr> great <jpr> that concludes the second agenda item <jpr> :-) <jpr> oS project meeting summary <jpr> discussed meeting times <jpr> review action items <jpr> esp. when partnerfate might be available for community feedback <jpr> first new factory sync is in progress <jpr> (and its broken :-) ) <jpr> oh, and mail notification with the wiki is being worked on <jpr> thanks to henne poking it ahead i think <jpr> anything else anyone wants to add on that? <jpr> archives and summaries are online <jpr> (and yes i should have prepared better for this section) <jpr> next action is cancelled <jpr> i blog about it

<jpr> so, over to mtgordon to talk about launching a bug squash day <captain_magnus> I think we have a misunderstanding when it comes to acronyms... <jpr> that we first discussed last week <jpr> captain_magnus: oh? *mtgordon waits for captain_magnus <captain_magnus> Rodrigo thought it had to do what repos we're using <jpr> captain_magnus: oh, in the actions? <jpr> ok <captain_magnus> And I thought that we needed to explain what G:U G:S etc means <jpr> oh, right <jpr> ok <jpr> captain_magnus: lets deal with that after <jpr> mtgordon: go ahead mark <mtgordon> OK, so... <captain_magnus> Ok, though you menation AI's from last meeting... <jpr> one in particular right now <jpr> mtgordon: ok, really go now <mtgordon> Upon JP's request, about an hour ago, I started looking into bugs from highly obsolete versions. <mtgordon> 9.*, 10.[01] <mtgordon> Open bugs for gnome, evo, mozilla, OOo, mono.... maybe a couple others: 146 <mtgordon> One person could go through slowly. More people could go through quickly. <mtgordon> It would be good to figure out, for example, which of these are already fixed in upstream versions that we've since shipped. <mtgordon> Detailed investigation on the platform in question may not be trivial (who's still running 9.3?). <jpr> (virtual box!) <mtgordon> Inability to reproduce the bug on 10.3 may (or may not) be meaningful. <Riggwelter> mtgordon: No-one who wants support ;) <captain_magnus> With obsolete versions, we're talking about "unsupported" right? <mtgordon> Yeah. <mtgordon> The point is mostly to thin out the junk to see whether there's anything back there we still ought to fix, IMHO. <mtgordon> Tidiness is nice but is secondary. <mtgordon> (and by "fix" I mean moving forward) <jpr> no, i think its not just unsupported <jpr> its not clear to me we'd fix many non-security 10.0 issues for instance <captain_magnus> So anything that we can still see in 10.3, we should move forward to 11.0? Unless it's "critical"? <mtgordon> That makes some sense to me, yes. *federico1 has quit ("Leaving.") <Iznogood> and those not found in 10.3? wontfix? <mtgordon> One question, a bit of a nitpick, is how to resolve old bugs that are fixed in newer versions. <mtgordon> Right, that question. <mtgordon> In 10.3, they're FIXED. In 9.3, where they're reported, they're technically WONTFIX. <captain_magnus> Well, depends for what version the bug was filed I reckon <mtgordon> True. <mtgordon> There's a gray area between FIXED and WONTFIX. I'm not completely sure what the formal policy is. <captain_magnus> If the bug was files for 10.2, then ping the developer, if it's older, and it's still in 10.3...? <mtgordon> I'm not looking at 10.2 bugs. <jpr> traditionally we have marked it RESOLVED/FIXED <jpr> and commented where it was fixed <jpr> ie <jpr> "fixed in openSUSE 10.3" <mtgordon> That's what I've been doing. Does that seem correct? Or is this not the time to discuss this? <captain_magnus> Sounds fair <jpr> seems like a good starting point <jpr> might want to run it past the opensuse qa lists <jpr> or the project lists or something <mtgordon> So the more people understand this policy, the more people can help. <captain_magnus> Bug reported can always complain and we can reconsider.... <jpr> to ensure we aren't breaking anything <mtgordon> Fair enough. I'll look into that. *btimoth1 (n=boyd@70.58.109.176) has joined #opensuse-gnome <mtgordon> Reporters likely won't care. They've probably moved on to newer versions themselves. <jpr> what do we do with bugs that we can't replicate on the old platform either? <mtgordon> It's mostly people who run reports who would care, IMHO. <jpr> so we can't confirme its fixed <captain_magnus> jpr: Do you expect anyone to use an older platform to try to reproduce? <mtgordon> That's not such low-hanging fruit, I'm afraid. <mtgordon> Really old, maybe NEEDINFO. <jpr> captain_magnus: maybe, need virtualized setups *munkii (n=munkii@217.54.184.229) has joined #opensuse-gnome <mtgordon> If the reporter says, "Yeah, I installed 10.2 ages ago and I'm not seeing the problem any more," it's FIXED. <captain_magnus> jpr: But we wouldn't go any further back than 10.2 for that <mtgordon> If after two weeks we hear nothing but crickets, we can resolve INVALID or WORKSFORME. <jpr> we have NORESPONSE <jpr> now i think <jpr> as a resolution <mtgordon> Oh, we do? I hadn't realized. <mtgordon> Fair enough. <captain_magnus> Perhaps some brainstorming needed on the wiki for this? <Riggwelter> NORESPONSE =~ SODOFF ;) <captain_magnus> We have 10.8 months before 11.0 :-) <mtgordon> So, one of the possibilities is to have an organized effort, a bunch of people working on the bugs at the same time, trying to plow through them. <mtgordon> In terms of momentum, shared experience, etc. this can be useful. <captain_magnus> mtgordon: I think that's the best <mtgordon> This is the "bug squash day" concept jpr described. <mtgordon> Any thoughts on when? <jpr> its a great way to get people involved <jpr> imho <captain_magnus> A lot of people only know bug reporting etc so they would feel very involved <btimoth1> and would the idea be to take as many low-hanging-fruit bugs and fix them? <captain_magnus> btimoth1: No, mark them as invalid :-) <btimoth1> i.e., bugs we think we could fix in one day? <jpr> not sure the squash day would be right for that <mtgordon> Fix? No. Mostly the effort is to thin out the bugs that have since been fixed and push the still valid ones to newer versions. <jpr> but we could have a follow up day <jpr> to do that <btimoth1> gotcha. sorry, I must have misunderstood at first <munkii> gtk yast still needs a huge improvement, is there any plans for that? <jpr> (we could even see about marking bugs at some point easy_fix or something to help new devs gets started) <jpr> munkii: off topic right now <mtgordon> That's a bit outside the scope of this project, at last for now. <jpr> munkii: save for Q&A please <munkii> and I just uncovered several bugs with the package manager too <captain_magnus> jpr: So that's an AI: Organize a bug squash day and specify the "rules" <jpr> so i think the open question is "when" <munkii> is that intopic? <jpr> munkii: no, but it will be later in the meeting <jpr> captain_magnus: yes <munkii> jpr: sure I can wait =) <mtgordon> The community might be more able to help on weekends. <jpr> timing, i would suggest 10-14 days away? <munkii> what's the topic now, I just popped in <munkii> ? <mtgordon> However, weekends are difficult for me. <jpr> we can review the "rules" next meeting? <mtgordon> munkii: clearing out old bugs in bugzilla <jpr> munkii: Ancient distro bug squash (mtgordon) <captain_magnus> We just steal apokryphos page for the bug squash day thing and replace it with GNOME :-) Then add that page to the wiki, send an email to the ML <jpr> anybody have any other ideas on timing? <jpr> hehe <jpr> good point though <mtgordon> Anyone have any timing preferences? <jpr> we could co-ordinate with a project wide one <jpr> apokryphos: when is the next one? <mtgordon> Are weekends better? Evenings? Days? However those are defined where you are? <jpr> mtgordon: how long do you envision it lasting? <jpr> if its a whole day <captain_magnus> mtgordon: We need a marathon I reckon... So run it over at least two days <jpr> usually people can come in off hours <Riggwelter> if we were to co-ordinate an oS project wide bug squash "day" - how about replicating the hack *week*? <captain_magnus> (That way people can come and go during that time) *btimothy has quit (Connection timed out) <hpj> maybe friday would work <jpr> 24 hours of a friday might do <hpj> novell people would still be at work, and community people wouldn't have work the next day <btimoth1> jpr: btw, may help the flow of meetings to have you/someone change the channel topic when we move on to different agenda items for latecomers like munkii (sorry for the off-topic message) *btimoth1 is now known as btimothy <jpr> we can go in circles <captain_magnus> jpr: It can be done at any time of the week if it's for more than one day *henrix has quit ("Ex-Chat") <btimothy> I like the Friday suggestion <jpr> mtgordon: is that enough feedback for you to create a time proposal for further discussion? <mtgordon> Yes, I think so. <jpr> mtgordon: check with apokryphos or the wiki on project wide bug days too i guess <mtgordon> jpr: Will do. <jpr> it wouldn't do to have ours and then 2 days later the project one :-) <mtgordon> jpr: Good point <captain_magnus> apokryphos doesn't have a current one planned <jpr> mtgordon: so you'll have a page up in the wiki to discuss this squash for next week <jpr> or sooner? *mtgordon nods <captain_magnus> I was thinking of stealing his previous one when I mentioned it <jpr> excellent <jpr> right <jpr> maybe its time to have another one project wide :-) <jpr> ok

<jpr> next topic <jpr> packaging policy <jpr> take it away mw *jpr has changed the topic to: Meeting in progress - Packaging policy (mw) | http://en.opensuse.org/GNOME/Meetings/20071011 | http://en.opensuse.org/GNOME <jpr> earth to mw <munkii> ping mw? *captain_magnus thinks jpr needs to update the agenda *way* earlier than 2 seconds before the meeting... <jpr> hah <jpr> autorefresh my man <jpr> autorefresh <hpj> (i like the idea of changing the topic as we go) <captain_magnus> I had all my URL's sorted and now I'm lost :-) <jpr> i'm going to skip down a bit and hopefully mw wakes up <mw> ugh, you added that to the wiki page very recently <jpr> hehe <jpr> yes <jpr> mw: i gave you a heads up yesterday on having the page though :-) <mw> yeah. didn't get it done though :( <jpr> yesterday afternoon on my way to the airport <jpr> ok <jpr> mw: ETA? <mw> tomorrow morning <jpr> ok <jpr> mw: it was a rush job, sorry <jpr> Riggwelter: i suppose nothing new to add on the Community policy? <jpr> still blocked <Riggwelter> blocked on Packaging policy <jpr> ok <munkii> oh well, I think G:S needs to have more miscellaneous packages instead of just concentrating on GNOME Desktop apps, is that possibility or you leave that for 3rd party repos? <Riggwelter> mw: Don't rush it though, better to get it right than quick <jpr> munkii: part of the community policy <jpr> is working that out somewhat <munkii> jpr, you mean Gnome:community? <jpr> munkii: in general the extras are going to GNOME:Community these days i believe <jpr> yes <jpr> Riggwelter: comments?

*jpr has changed the topic to: Meeting in progress - GNOME:Community policy status (Riggwelter) | http://en.opensuse.org/GNOME/Meetings/20071011 | http://en.opensuse.org/GNOME <munkii> G:C is pretty poor <Riggwelter> yeah, look at http://en.opensuse.org/GNOME/Community_Inclusion_Policy <jpr> it was originally a dumping ground <jpr> the policy is to get some standards there <captain_magnus> mw: Riggwelter: Can you hold a packaging class in this channel? Advanced openSUSE Training - GNOME Packaging? <jpr> so people can rely on the packages <Riggwelter> once the policy is nailed, we're going to purge <Riggwelter> captain_magnus: something to think about, time constraints allowing mauro_ mauropm metavoid mtgordon munkii mw <mw> captain_magnus: yeah, something to consider, but not a bad idea <jpr> esp. if we can show the nice plugins we have to make it easier <mw> although i don't think anything beats getting your hands dirty and trying it yourself, making mistakes, fixing them, and repeating the process over <jpr> anything else on G:C? <munkii> is there any chance that the G:C maintainers would consider the suggestions in whishlist GNOME? <Iznogood> +1 <Riggwelter> mw: That's part of the policy in a way :) <Riggwelter> munkii: Some of them are already in G:C <jpr> wishlist handling is a good point <munkii> Riggwelter: well, I haven't seen any so far, I found some of them on user: repos though <jpr> its not really being covered by G:C, internal packaging <jpr> or the feature request processes atm <jpr> formally that is <munkii> any plans to use FATE soon? <jpr> wait for the agenda item coming <jpr> and see opensuse project meeting minutes <munkii> ah, ok <jpr> AI: figure out where wishlist items live in the feature process <jpr> good one munkii <Riggwelter> the policy sort of implies (although it could be made clearer) that G:C is staging point for wishlist items as well as other things <jpr> agreed <jpr> we should probably write that down <munkii> =) <jpr> G:C->G:U <jpr> ok *mtgordon wonders how many of the old bugs are wishlist items. <jpr> ok <Riggwelter> mtgordon: probably a lot <jpr> anything else on GNOME Community <jpr> ? <jpr> ok

<jpr> next <Riggwelter> 3...2...1... <jpr> bug plan status <jpr> federico and rodrigo are both recently on the road and not able to join today *jpr has changed the topic to: Meeting in progress - How to handle feature requests and mini-projects (JP, Cyberorg, captain_magnus) | http://en.opensuse.org/GNOME/Meetings/20071011 | http://en.opensuse.org/GNOME <jpr> captain_magnus: would you like to take it? <captain_magnus> jpr: Should I be honest? :-) <captain_magnus> We're still discussing the best option for this <captain_magnus> What's holding us up is that we don't have access to fate yet <captain_magnus> I did add "examples" of the same feature request to our current suggestions (excluding fate) <captain_magnus> You can have a look at examples on http://en.opensuse.org/GNOME/FeaturePlanning <jpr> i think the wiki one could be much better with an infobox template <captain_magnus> At the moment, unless we (cyberorg and myself) get access to fate, it's difficult to asses... <jpr> top level project is working on that <jpr> (i have no access either unfortunately) <jpr> as a general question to everyone <captain_magnus> We are trying to put our discussions on that page (http://en.opensuse.org/GNOME/FeaturePlanning) for all of you to follow it and feedback is more than welcome <jpr> should we create a rough dumping ground page for 11.0? <jpr> so we at least have some ideas down <captain_magnus> (Am I allowed to answer?) :-) <jpr> even if it might mean transferring them elsewhere? <jpr> captain_magnus: no! <jpr> elsewhere in the future <munkii> a clean features wishlist should do fine <btimothy> I don't see why we shouldn't start a 11.0 page if there are already ideas <jpr> the "clean" part is hard :-) <jpr> we should limit it to one page and a straight forward list with maybe one sentence of explanation right? <captain_magnus> jpr: When it comes to idea.o.o, it's a matter of using the right tags... but I am still not sure what sort of maintenance that's needed for it... <jpr> yah *captain_magnus is biased... <jpr> AI: create 11.0 feature wish list page <jpr> ok <jpr> closing that out

<jpr> task review *jpr has changed the topic to: Meeting in progress - Task Review | http://en.opensuse.org/GNOME/Meetings/20071011 | http://en.opensuse.org/GNOME <jpr> sreeves: live gnome CD test <jpr> sreeves: are you guys done there? <sreeves> I have not seen the final GM live CD yet <sreeves> so no <jpr> sreeves: there are new test builds <jpr> sreeves: ask coolo <munkii> yep, but we should have a general maintainer for that list, just for reality check purposes, we don't want it to get over-dreamy like the general feature list <jpr> munkii: yes <jpr> munkii: sounds like a volunteer to help me watch it :-) <munkii> you won't believe what kind of non-sense I had to remove from there <jpr> mw, sbrabec: G:S merge? <captain_magnus> munkii: jpr: Depends on the final solution... <jpr> i think gnome stable is now up to date? <mw> should be <mw> need to check out G:U <sbrabec> Yes, but still does not compile due to BS bug. <jpr> ok, please note that in the status <sbrabec> bug 332132 <bugbot> openSUSE bug 332132 in openSUSE.org (BuildService) "build script corrupts spec file" [Critical,Needinfo] https://bugzilla.novell.com/show_bug.cgi?id=332132 <sbrabec> G:S should not publish its builds just now <jpr> in the "not started" list <jpr> Fix GNOME/Submitting Bugs page to include more information <jpr> is something we should really get going <captain_magnus> I think we need one more column in the tasks list for status <jpr> is any one interested in picking that up? <jpr> captain_magnus: after the review please <jpr> mtgordon: you have some of that knowledge right? <mtgordon> jpr: I should probably help with that, yes. <jpr> anyone else? this is a good opportunity to get better bug reports <jpr> which means faster fix times in development :-) <captain_magnus> Haha <jpr> i'm serious <jpr> nothing slows a bug down like having hackers as for logs <jpr> mtgordon: i suggest you talk to AlbertoP <jpr> for help <mtgordon> jpr: OK <jpr> any other tasks we need to review this week? <jpr> captain_magnus: glossary? <captain_magnus> Have not started the glossary... I think myself and Rodrigo needs to talk about what's needed <captain_magnus> I will ping him when I see him the next time <jpr> ok

*jpr has changed the topic to: Meeting in progress - Q&A | http://en.opensuse.org/GNOME/Meetings/20071011 | http://en.opensuse.org/GNOME <jpr> first the pre-asked questions <jpr> then I'll throw it open <jpr> Q: How do we move forward with the "Debugging topics" (In this case; http://en.opensuse.org/GNOME/Multiscreen)? <jpr> A: We finish the bug plan so we know all the bugs we are going to fix and so stuff doesn't get lost <jpr> the bug plan is *very* important <jpr> so please give feedback to rodrigo and federico *Riggwelter goes to bath Rigg Jr <jpr> Q: I think it's vital to have a due date on *all* tasks or they run a risk of never getting completed. We could use something like "*Oct 31" and "Oct 31", where the '*' indicates preliminary. <captain_magnus> jpr: The Debugging topics is part of the bug plan <captain_magnus> sort of *nags has quit ("Linux Desktop Testing Project - http://ldtp.freedesktop.org") <jpr> A: yes, please add a due date column <jpr> or maybe ETA is a little bit better <jpr> not everyone is paid to work on opensuse <jpr> nor is people who are paid <captain_magnus> Agree, ETA is good <btimothy> eta is good <jpr> not volunteering time too <jpr> :-) <jpr> Q: If my point above is accepted, how about creating an iCal out of it so that we can get alarms etc. <jpr> A: sounds good <jpr> task on the wiki i guess <jpr> Q:Looks like we ended up with (at least) two orphan pages. Be good if they good be merged to our "new infrastructure" somehow; http://en.opensuse.org/OpenSUSE_GNOME_post-10.3_ideas and http://en.opensuse.org/Roadmap/10.3:GNOME <jpr> yes <jpr> A: both should be obsolete with the feature wishlist page for now <jpr> ok <jpr> munkii: you had questions earlier <munkii> ah, we're in Q&A now? <jpr> yes <munkii> yes, let me retrieve them <jpr> (and throwing open the channel generally for questions) <munkii> munkii: gtk yast still needs a huge improvement, is there any plans for that? <captain_magnus> jpr: You missed one! <captain_magnus> A simple refresh or what ever you called it :-) <jpr> btimothy: want to field that at least partially? <btimothy> sure ... <jpr> captain_magnus: not a question <btimothy> there are definitely a lot of improvements needed to yast2-gtk ... <jpr> captain_magnus: statement or AI :-) <btimothy> our strategy so far has been to take the most annoying things and get those fixed asap <captain_magnus> jpr: Refersh again... It's a question now <btimothy> granted, I don't really know what I'm doing in yast2-gtk, but at least some of the package selection bugs have been worked on <btimothy> I'm hoping that they'll approve the latest fixes as a patch for 10.3, but who knows <munkii> btimothy: but the package manager needs a lot of improvements, features wise <btimothy> agreed <btimothy> I'd like to see us evaluate PackageKit <btimothy> we talked about that earlier today <afonit> I remember in the 10.2 package, the devel packages were next to the main package so it was easy to install the devel's, also there was an option in the menu to install all devel packages for all installed packages, I do not see that in the 10.3 package installer <btimothy> the yast2-gtk was originally written by a summer of code project <munkii> will these improvements be observed during 10.3 life span? <jpr> yes, if there are *particular* bugs, please make sure they are filed <btimothy> and now it's not really abandoned, but there isn't really a team "owning" it yet <jpr> there is going to be a review of them next week <jpr> well, Ricardo, Michael and Boyd do fix it :-) <jpr> its not unmaintained or anything <btimothy> right <jpr> just a little background (and correct me if I'm wrong boyd) <jpr> the issue with the package selector <jpr> is that most things in Yast <btimothy> munkii: when you say yast2-gtk needs to be fixed ... or needs improvements, please back those with bugs reported in bugzilla <jpr> are widget abstractions <jpr> ie "put a button here" <jpr> so yast-gtk does pretty well *wberrier has quit ("Leaving.") <jpr> however the package selector is an entirely <jpr> a package selector widget <jpr> ie there is no real abstraction :-) <btimothy> 100% correct <jpr> hence the feature disconnect <munkii> btimothy, I particularly meant it feature-wise <btimothy> munkii: feature wise with the package selector or with all of yast? <jpr> munkii: fyi the code is available on svn.opensuse.org too :-) <jpr> other questions? <captain_magnus> btimothy: Package selector... <jpr> (yast2-gtk can continue after meeting now please) <jpr> last call for alcohol <captain_magnus> jpr: I made my last on q&a thing a question,,, <jpr> A: sure we can try <jpr> someone needs to step up and take the lead *captain_magnus looks at jpr <jpr> as always with this thing <btimothy> btw, if you feel strongly abt. the yast2-gtk package selector improvements, please go add votes to this bug: https://bugzilla.novell.com/show_bug.cgi?id=300750 <jpr> nope, not me :-) <bugbot> openSUSE bug 300750 in openSUSE 11.0 (YaST2) "yast2-gtk: package manager: quick search and sorting are sorely needed in plain view" [Major,New] <jpr> captain_magnus: federico has a canned talk like that though <munkii> yes, I think gtk-yast in general needs a lot of improvements, but the package selector seems to be the one in desperate need for features, it's plain as heck <jpr> and mw and sbrabec have done packaging presentations iirc <jpr> LAST CALL FOR QUESTIONS <Iznogood> could we go back to Community_Inclusion_Policy ? What about programs that are "dead" but working. where can they go? <munkii> I have another one <captain_magnus> jpr: Well... My Q was more about having a specialist on the channel for a specific topic <btimothy> Q: Do we have anywhere a record of the top 3 - 5 things we all (as developers) think ought to be done to openSUSE 11 to make us on par/better than Ubuntu as far as getting people to use/install/adopt openSUSE? <jpr> A: we do not <captain_magnus> Have a wiki page about something interesting (but easy enough for beginners), then have them on the channel to answer stupid questions <jpr> munkii: just say it <mw> it'd be a very controversial list <munkii> how long are we expected to wait for the next big improvement in gtk-yast, given that it has no devoted team <btimothy> reason I ask is that I'm very interested in knowing where everyone would think we should focus most of our time to accomplish greater adoption <btimothy> I personally believe it's the entire package management ;) <jpr> captain_magnus: could do <munkii> btimothy: yes *captain_magnus wonders who logged this meeting and will write up the ai's etc, since rodrigo isn't here... <jpr> btimothy: are you talking project wide? <benJIman> Regarding the package selector, have you been in touch with those maintaining the Qt version regarding the design? <jpr> btimothy: that i don't know <jpr> i was referring to gnome specifically <btimothy> jpr: project wide and ... even GNOME too <jpr> benJIman: yes, they are internal novell people <benJIman> Because both are sorely in need of improvement, and it's unpopular and inconvenient to have them looking completely different. <btimothy> since the package management is exposed in GNOME, it's a big eye sore right now <btimothy> munkii: yeah, we are all the dev team. I think we can tackle the yast2-gtk problems <benJIman> jpr: Perhaps the process could be more open, using the -ux list etc. <jpr> benJIman: stefan hundhammer is doing some review of the situation i believe <jpr> thats a good point <jpr> it might be on yast-devel <benJIman> sh seems to think that his UI is perfect though. <jpr> i'm not sure <captain_magnus> benJIman: We started an email thread about it but it died very quick... Nobody offered any kind of input apart from the original poster <benJIman> captain_magnus: I've not seen one. <benJIman> captain_magnus: Oh you mean prior to 10.3? <benJIman> captain_magnus: But now is the chance to actually do things. <jpr> benJIman: ah, well thats what blogs and and mail are for - gather popular opinion one way or another :-) <captain_magnus> benJIman: Huh?? I'm sure we talked about it in -chat <munkii> btimothy: it's not just the problems I'm concerned about, I'd really love to see some eye-popping features <captain_magnus> munkii: Such as..? <munkii> frankly I'd like it to beat the qt-yast <btimothy> PackageKit! :) <jpr> ok <benJIman> jpr: An open design process that everyone likes means we can adopt a great UI for both versions, hopefully. <captain_magnus> munkii: We can't do that... Both package managers need to be on par...! <benJIman> Perhaps I'm being overly optimistic.

*jpr watches channel stray away from straight Q&A *Iznogood suggest a shameless copy of the add remove software from ubuntu, it is actuallay cool <jpr> i'm going to end the meeting <jpr> but please keep discussing <jpr> thats what the channel is for *captain_magnus ties jpr to the meeting :-)