<jpr> Welcome to the first openSUSE GNOME Team meeting! sreeves thinks jpr's clock is slow - it's 10:02 <jpr> I'm glad we finally got this meeting going as we move on to 11.0 <jpr> First time we've had one of these, so we haven't figured everything out, but I'm sure we can sort that out pretty quickly <jpr> We are working off the agenda at http://en.opensuse.org/GNOME/Meetings/20070927 <Riggwelter> rodrigo: lol <jpr> I'm JP Rosevear, I work for Novell on the desktop team <jpr> i'll moderate today's meeting <jpr> and with that I think I've cleared the introduction agenda itemes

<jpr> and I'd like to invite boyd and scott to discuss the wiki organization project <jpr> they started <jpr> btimothy, sreeves : please go ahead <btimothy> hello everyone :) <btimothy> if you haven't figured it out, jp's my boss ;) <btimothy> We now have a main "GNOME" page that acts as a jumping-off point for all things GNOME in openSUSE: http://en.opensuse.org/GNOME <btimothy> it's split up into different sections <btimothy> hopefully catering to different types of users ... <btimothy> or at least different activities you might do with openSUSE GNOME (developers, users, etc.) <btimothy> this page is meant to be the main "jumping-off" page for everything related to GNOME in openSUSE <btimothy> you can access our development plan <btimothy> our individual tasks <btimothy> guidelines on creating patches <btimothy> dev practices and standards, etc. <btimothy> if you see anything missing from this page, please add it <btimothy> or if you have suggestions on improvements to the categories/etc. please let us know <btimothy> a couple of weeks ago we started working on some ideas of what we could do to help the wiki out for GNOME-related stuff <btimothy> we created a page http://en.opensuse.org/GNOME/Wiki_Layout <btimothy> going forward, this page will contain general plans for what we want in the wiki <hircus> the Community Inclusion Policy probably should clarify what happens if a package is suitable, but pulls in many dependencies <btimothy> ...like any new GNOME-related page should be placed as a subpage of GNOME/ <btimothy> the GNOME/Wiki_Layout is a good example of that <captain_magnus> btimothy: Nice work... <btimothy> We're hoping...as we figure out exactly where to focus ... <btimothy> that the ... <btimothy> http://en.opensuse.org/GNOME/Tasks page will list what everyone's working on <btimothy> and that page will also have things where nobody has been assigned yet ... <btimothy> that's YOUR signal to jump in and help make GNOME in openSUSE better :) <btimothy> captain_magnus: thanks ;) <btimothy> and the only other thing really I have to say about the wiki is ... <btimothy> it's a Wiki ! If you see typos/problems/etc. jump right in and help make it better <srag> btimothy, GNOME is OpenSUSE is already great! :) <jpr> sreeves: anything to add? <btimothy> or if you see something outdated, update it <rodrigo> srag: it should be greater :) <srag> yeah! <btimothy> or point out to someone that it's out of date <hircus> so, in case of dependencies, do we have a consensus? <jpr> hircus: there is a separate agenda item on the community policy <btimothy> any other questions about the wiki specifically? <jpr> hircus: lets wait until then for your questions <hircus> jpr: sorry, just noticed <jpr> np <captain_magnus> btimothy: Only one question on the http://en.opensuse.org/GNOME/Tasks <btimothy> I've entered a bug/enhancement request for someone enabling/installing an email update notifier <btimothy> so you can be notified via email of wiki page changes <btimothy> no update on that yet <btimothy> captain_magnus: yeah? <captain_magnus> Who will make sure that the tasks are being done and ticked off? <jpr> (just ask your on topic questions, don't ask to ask :-) ) <henne> btimothy: bug number? :) <btimothy> henne: https://bugzilla.novell.com/show_bug.cgi?id=325753 <rodrigo> btimothy: I guess we should vote for that wiki-notification bug <captain_magnus> Will it be up to each person that's assigned and if so, who will clean it up once it's done <btimothy> I kind of assumed that jpr would track the tasks page <captain_magnus> btimothy: Sounds good... Delegate to the boss :-) <btimothy> and after a while clean up the done tasks ... I like seeing a list with at least some of the things finished for a while :) <jpr> no, this is a community team <jpr> its up to the person doing the task to mark it closed imho <Riggwelter> I agree with jpr on this btimothy agrees with jpr <jpr> if something is assigned but not getting done <jpr> we should bring it up in this meeting i think <Riggwelter> people who take responsibility for a task have to realise that keeping its wiki status updted is part of the task <captain_magnus> What happens if they don't mark it off or update it? Someone needs to be responsible... Or should that be the community effort? <jpr> community effort <jpr> it could be raised in this meeting i think <captain_magnus> There are already tasks that are overdue (not a big deal as such), but not updated... <captain_magnus> (I should say task, not tasks) <jpr> yes jpr looks at scott and rodrigo :-) <rodrigo> I already tested it, didn't update the wiki though :( <btimothy> ah, and on our meeting page (http://en.opensuse.org/GNOME/Meetings/20070927) I had a couple questions related to the wiki. anyone have ideas/suggestions? <rodrigo> from my part it can be marked as complete, since it was just about making sure it worked <captain_magnus> jpr: Great idea... Should be on the agenda to walk through the tasks (what should be updated, added etc) <federico1> dum de dum <jpr> do other people agree with captain_magnus on that? <rodrigo> yes <Riggwelter> jpr: yes <btimothy> yep <bradya> I agree <jpr> ok <Riggwelter> jpr: Tasks are part of matters arising really <captain_magnus> jpr: We agree with you, not me :-) <federico1> should we talk about the order in which to fix bugs? <jpr> anything else on the wiki? <jpr> any questions that is <jpr> before we move to federico/rodrigo on the bug plan? <sreeves> one other thing to note is the team page http://en.opensuse.org/GNOME_Team <sreeves> lists the people that are currently active in working on GNOME things <jpr> and I see a lot of people absent :-) <captain_magnus> Shouldn't that page be moved to http://en.opensuse.org/GNOME/Team instead of http://en.opensuse.org/GNOME_Team? <sreeves> if you get actively involved in helping in any way feel free to add yourself to that page <mw> captain_magnus: yes <Riggwelter> captain_magnus: The current format is consistent with other wiki entries for other teams <mw> Riggwelter: well, one should redirect to the other, in any case <jpr> thats what redirects are for :-) <Riggwelter> but yes, it should be GNOME/TEam <jpr> (we did that for meetings) <captain_magnus> Riggwelter: Ok, I thought we wanted to have everything in GNOME/xxx <Riggwelter> I reckon current should redirect to correct <jpr> we should always have links consistent with the rest of the project i think <jpr> and maintain the GNOME/ structure <jpr> lots to say on the wiki <jpr> but i think i need to cut it off here <Riggwelter> nod <jpr> since we need to move on <Riggwelter> time is money :) <captain_magnus> I have all night :-) <jpr> it is a wik, and there is a wiki task list <Riggwelter> captain_magnus: I don't <jpr> or discuss post meeting with btimothy and sreeves

<jpr> next topic <jpr> Bug Plan <jpr> federico1: take it away <captain_magnus> jpr: Just in between topics... Are you taking minutes for the AI? <jpr> federico1: take it away.... <jpr> captain_magnus: rodrigo is logging this, I'll review for action items <rodrigo> captain_magnus: I'm saving the log <captain_magnus> Ok, cool <jpr> ok, no federico <jpr> we'll come back to him <jpr> next <rodrigo> ok, I'll go ahead captain_magnus thinks federico1 is working on his house :-) <rodrigo> oh <jpr> patch upstreaming <jpr> mw, rodrigo : go ahead <rodrigo> ok <federico1> sorry, was working on the wiki <jpr> federico1: you have to wait now <federico1> ok <captain_magnus> s/wiki/house/ <jpr> rodrigo/mw: go <rodrigo> mw and I have been working on writing osc plugins <rodrigo> to, first, get an indication of the patches we have in the packages <rodrigo> and to write tools to help us dealing with the patches <rodrigo> first of all, we've created a format to mark patches in the .spec files: <rodrigo> http://en.opensuse.org/GNOME/Patches <rodrigo> no packages are marked yet, but we're starting soon <mw> does the format to mark patches look sane to people? <rodrigo> the idea is to know exactly what each patch does (a new feature, a fix) as well as the kind of patch it is (opensuse-specific, to-be-upstreamed) captain_magnus adds a URL for people to understand what OSC is: http://en.opensuse.org/Build_Service/CLI <rodrigo> captain_magnus: yeah, right :) <Riggwelter> mw: as sane as could be expected <rodrigo> then, we've written 3 plugins so far: <mw> Riggwelter: heh. i wonder if "PATCH-" is redundant. also whether a short description in addition to bug numbers would be useful <federico1> mw: yeah, it's nice - why in the spec file instead of in the patches, though? <rodrigo> Rodrigo's branch: http://www.gnome.org/~rodrigo/git/osc-plugins.git <rodrigo> Michael's branch: http://primates.ximian.com/~maw/git/osc-plugins <Riggwelter> mw: PATCH helps you scan the file <mw> Riggwelter: true <snorp> <snorp> nice :) <jpr> rodrigo/mw: could you talk a little about the motivation for this? <mtgordon> We might want to identify backported patches as such, since we can expect to drop them in the future. This makes them distinct from opensuse-specific patches we expect to maintain internally moving forward. <mw> mtgordon: doesn't FIX-UPSTREAM cover that? <mtgordon> Ah, nm. <rodrigo> jpr: yeah, if people run: 'osc-listpatches --summary-only GNOME:STABLE' they'll understand what's the motivation :) <hpj> federico1: i like the spec file approach - annotations can get lost when patches are re-diffed <mauropm> mw, rodrigo : it looks really nice! <Riggwelter> mw: A comment could (a) help (b) confuse :) <jpr> rodrigo: well, spell it out for everyone :-) <rodrigo> we have packages, like evolution-data-server, with lots of patches (83 for e-d-s, 69 of which are disabled :-( ) <mw> anyway, the reason we're doing this is because some packages are totally out of control wrt number of patches <federico1> hpj: ah, good point <hircus> is there any Bugzilla integration right now? <rodrigo> and dealing with patches in packages is very time-consuming <federico1> I'm sold, then <mw> hircus: yes, we are hoping that the comments on patches will have entries like bgo1234 or bnc9876 <hircus> if the Novell bugzilla entry refers to the upstream bug filing, and the upstream bug is closed, presumably the patch can be disabled captain_magnus noticed that only jpr and btimothy introduced themselfs... :-) But let's leave that to the end if people are interested... <jpr> hircus: when the version its fixed in upstream is packaged <mw> hircus: it'll be able to be disabled in the future, but not "now" :) <hircus> mw: yup, looking at it now. My question is whether we still need to poll <mtgordon> Upstream bugs are often closed when a fix is checked in, not when a tarball is released. <mw> anyway, knowing what patch does what and who's likely to be interested in it will make upstreaming patches far easier henne wonders why all the information is not in the patchname <rodrigo> mtgordon: yes, that's why we need to keep for some time some upstreamed patches <hircus> mtgordon: ah ok. so we can only know that it's potentially fixed <rodrigo> in fact, marking the bugs with this might help us in writing more osc plugins to, for instance, automatically upstream a patch <hircus> but won't the patch simply not apply cleanly if upstream's tarball has the patch? <jpr> rodrigo/mw: henne had a q that was missed <mw> jpr: i saw it <rodrigo> I was thinking we might need a PATCH-FIX|FEATURE-UPSTREAMED category <rodrigo> the problem with putting all info on the filename <mw> i'm trying to remember why we didn't / don't want to just encode all this in the patches' names <rodrigo> is that not everyone will follow the guidelines <federico1> I just added a PATCH-NEEDS-REBASE category <jpr> rodrigo: but we expect them to for added the comments? <jpr> *adding <rodrigo> mw: that's what we talked, right? <mw> rodrigo: yes <mtgordon> I suppose it's easier to annotate the spec than to rename the patch. <rodrigo> jpr: yes, right :) <mtgordon> Sane patch naming should, of course, be encouraged. <mw> mtgordon: right <federico1> either way, we can have the tools say when a patch does not have metadata <rodrigo> federico1: patchlint osc plugin that mw wrote does that <federico1> rodrigo: oh, sweet <hpj> will someone be responsible for poking people to add any missing annotations? <mw> the plugins are available in home:maw osc-plugins-gnome <federico1> many patches have comments before the "---" line - it would be nice if the tool could extract those comments and present them for easy viewing <federico1> hpj: wall of shame :) <hpj> works for me :) <jpr> is there instructions for checking out and building these plugins via git¿ <rodrigo> hpj: for now, we'll do it ourselves, but yeah, in the future, wall of shame :) <mw> hpj: i guess we'd say "before commiting, run osc lint*" and see if it checks out <rodrigo> we should encourage people to do that, or even force them, given WE are the maintainers of the packages :) <jpr> and will we propose this as a standard project wide after experimentation? <federico1> hmm, does osc run rpmlint? <federico1> we have a ton of stuff in rpmlint these days <rodrigo> jpr: hopefully <mw> jpr: standard git and autotools instructions, if that's what yuo mean <henne> federico1: both build and the buildservice do <rodrigo> the build service people said they might include our plugins in the osc source itself <mw> jpr: the lint plugins have a concept of standards, although only gnome's is (half-) implemented so far <jpr> mw: are the repos in the wiki? <mw> jpr: no idea if other groups would agree to what we've agreed upon <rodrigo> AI add info about osc-plugins to wiki :) <jpr> cool <jpr> any last q's on patch upstreaming? <federico1> mw: they'll see that it's soooo convenient to have, that they'll adopt it <mw> federico1: hopefully <federico1> mw: "WHAT? you don't have annotated patches!? how can you work like that?" <federico1> mw: "fuggin' amateurs" - and they'll do it :) <jpr> ok <jpr> bug plan <jpr> http://en.opensuse.org/GNOME/Bugs <federico1> OKAY PEOPLE <rodrigo> federico1: what NEEDS-REABASE mean? <mw> that reminds me that the lint plugins don't work on . but only against checked in packages. got to fix that ;) <jpr> rodrigo: after the meeting <federico1> rodrigo: you update a tarball, a patch no longer applies, it gets commented out in the specfile <rodrigo> federico1: ah ok <federico1> rodrigo: someone needs to rediff / see if it's upstream now / etc

<federico1> okay, bug plan <rodrigo> jpr: one last thing <rodrigo> should we add UPSTREAMED category? <jpr> rodrigo: lets move that discussion to the wiki <jpr> or next week <rodrigo> ok <jpr> federico1: go ahead <federico1> so, rodrigo and I have been building a list of bugs to fix <federico1> these are not all the bugs in the distro; just the ones that seem like they'll hurt a lot of people <federico1> or that disappoint the most people <federico1> crashes are bad, but if they are in a component one seldom uses, they may get a lower priority <federico1> I've been thinking of "things that are obviously wrong out of the box" (like the bug where gnome-panel shows up in the wrong position on widescreen laptops), versus "functions that don't work when I use them" (like banshee being unable to rip CDs with data) <federico1> I think those are the most important bugs hircus needs to go -- bye for now <rodrigo> http://en.opensuse.org/GNOME/Bugs <jpr> federico1: anything more to add before questions? <federico1> one more thing <captain_magnus> Since I have a few bugs in there, I have to agree with federico1 :-) <matematic> who will actually decide which bug is important and which not? <federico1> it would be nice to pick a topic, and fix all/most of the bugs related to that. I just started http://en.opensuse.org/GNOME/Multiscreen for people who have trouble with xinerama <jpr> ok, questions on the bug plan <rodrigo> well, there's one more thing, the voting system, if we are going to use that to know what people want fixed <hpj> i like the bug topic idea <jpr> i have one, will you produce a policy for when to send bugs upstream only <jpr> and not fix them as part of the gnome team work <federico1> captain_magnus: oh, yeah, I forgot to NEEDINFO some bugs :) <federico1> matematic: that's the *big* question :) <captain_magnus> federico1: Slack :-) <jpr> opensuse gnome team that is <federico1> matematic: it relates to the mail I sent last week about voting on bugs, or marking duplicates <federico1> jpr: hmmmm <captain_magnus> I see more "Should go upstream" with GNOME bugs in openSUSE than any other component... <henne> federico1: how do you expect to deliver those fixes? via online update or buildservice? <matematic> I think that voting system is fair enough <captain_magnus> That could be becuse we do more upstream work directly with regards to GNOME.... <bradya> it would be nice to every now and again have a bugfest day and focus on a topic as Federico pointed out. I believe the KDE guys do this every so often <federico1> jpr: probably when we don't have enough resources to fix the bugs we have. Or ideally, I'd like every upstream bug to go upstream as soon as possible --- then we can parallelize the job of fixing things with upstream. We fix some, they fix some. <captain_magnus> But I don't know... <jpr> federico1: ok, but to not conflict with our "fewer patches goal" won't we simply have to reject fixing some bugs? <rodrigo> captain_magnus: it is certainly the case for most things <jpr> if upstream disagrees with the bug or the approach to fix it? <federico1> matematic: for example, I was surprised to see that many people voted on a bug in 10.1 for audacity - do so many people create podcasts or something? :) we have to make them happy. <captain_magnus> rodrigo: Why don't we fix it for openSUSE first, and THEN submit the PATCH upstream? <federico1> bradya: that's a good idea, then everyone is on the same channel <mw> jpr: is the goal really few patches, or that (most) patches only "live" for a short period of time? <rodrigo> captain_magnus: usually, they are either top bugs upstream, or new features we are not interested in now <jpr> i think its both <jpr> we need fewer long maintained patches <mw> right <jpr> and shorter lived patches <hpj> that typically means spending more time on each patch <federico1> jpr: yeah, we'll have to. I'm not sure yet how to make that call <jpr> captain_magnus: should_go_upstream is often used when we don't have the resources to fix a bug <hpj> to make it acceptable upstream <matematic> federico1: exactly may be some of us don't think that a bug is important but for another 100 to be very annoying. <jpr> captain_magnus: or its a policy decision upstream <jpr> at least thats how its used now <jpr> federico1: are you aware of the current should_go_upstream keyword in bugzilla? <federico1> matematic: I'm especially interested in bugs that more than one person is seeing <jpr> (and its use) <federico1> jpr: I've seen it, but I don't know the policy <jpr> gekker: have you sent the policy to feddy? <mw> hpj: yes, more initial work, but probably less work overall <captain_magnus> I think we should have an explanation on the wiki for those sort of things then <matematic> federico1: seeing is the key word I think that the bugs which are obvious could be fixed with higher priority and patches upload for update as soon as possible <hpj> mw: hopefully - it does indicate that we should be more aggressive about letting upstream fix things for us, though <federico1> I think we could also use some quorum from opensuse users when upstream doesn't want to accept a fix - for example, my nautilus-drives-and-volumes mega-patch :) <captain_magnus> Add a few different reasons that can be pointed to from within a bug report: (Not enough resources, need to discuss with upstream on how to implement etc) <federico1> jpr: yes, he did - read only the first pages so far :) <matematic> federico1: example: missing attachment icon in Evolution. <gekker> jpr: yeah <federico1> matematic: oh, yeah, that would be one of the things that are "obviously wrong out of the box" <gekker> federico1: v3 will come out if I'm ever allowed time to work on it again... I'll keep you in the loop <federico1> gekker: thanks! <btimothy> federico1: and you'll update the wiki?  :) <matematic> federico1: yes but as we can see the attachment is still missing since last beta which makes bad impressions on the work done <federico1> btimothy: sure <federico1> matematic: what's the bug number? <jpr> federico1: will you try to achieve one grand-unified query to see this list of bugs? <jpr> btw, i think "fixing all bugs in one category" is a great idea <matematic> federico1: https://bugzilla.novell.com/show_bug.cgi?id=308959 <bugbot> openSUSE bug 308959 in openSUSE 10.3 (GNOME) "mail attachment icon is missing" [Major,New] <federico1> jpr: if we do the "bugs under the same topic" thing, we can have links in the wiki to search for each topic (stuff in the status whiteboard) <jpr> cool <jpr> anything else on bug plan? <jpr> Next we'll move to Riggwelter and the community inclusion plan <federico1> rodrigo: anything else? <rodrigo> no <jpr> Riggwelter: your on <federico1> I just want to ask people to VOTE ON BUGS and WIN BACK THE LAND <federico1> err <federico1> just vote on bugs

<Riggwelter> ok, by way of intro, I used to work at SUSE, now purely community <Riggwelter> So, we've got the GNOME:Community repository and it's been a bit of dumping ground <jpr> (runs planet suse !) <federico1> matematic: thanks, I'll add it to the list <Riggwelter> It needs tightening up and so we've dicussed (at leeeeeength) on opensuse-gnome list it captain_magnus wishes he could spell "traiter" -> Riggwelter :-) <Riggwelter> The fruits (In draft) are at http://en.opensuse.org/GNOME/Community_Inclusion_Policy <Riggwelter> capt:I got ordained instead :) <captain_magnus> Riggwelter: :-) <bugbot> New openSUSE 10.3 (GNOME) bug 329043 filed by snorp@novell.com. <Riggwelter> Basically, we need to know that there is the possibility of smooth flowing between G:C and Factory (in either direction) <bugbot> Bug https://bugzilla.novell.com/show_bug.cgi?id=329043 Normal, P5 - None, NEW, notification messages cannot be dismissed <Riggwelter> and the policy is designed to ensure that <Riggwelter> it's not much to read so I'll let anyone who hasn't already done so catch up <matematic> Riggwelter: I saw the inclusion policy what was not quite clear is " It has the potential to be included in openSUSE" <mw> i agree with matematic <Riggwelter> noted <Riggwelter> my concern is that if that's headlined too much we get spammed with "oooh, put my package in, and mine, and mine" but it needs to be in there <federico1> Riggwelter: can it be done organically? you create a new package in your personal repo, and mail the list - "hey, everyone, I just packaced foobar-2.3.5, can someone test it as well as myself?" <mw> i've thought for a while is that we should be moving a number of packages out of openSUSE proper and into G:C <Riggwelter> federico1: that's the idea <federico1> Riggwelter: if people then say it is stable, it gets put in FActory <Riggwelter> federico1: section 1 says that but the language should maybe be polished <Riggwelter> mw: Section 2 :) <mtgordon> What sorts of packages *don't* have the potential to be included in openSUSE? <captain_magnus> Don't we have votes in buildservice now? (Since we're talking about voting for things) <jpr> Riggwelter: do you think its important to get specific GNOME packaging guidelines in place <Riggwelter> mtgordon: unmaintained upstream for a start <jpr> to refer to in the policy? <matematic> mtgordon: restricted formats for sure :) <henne> mtgordon: very fast moving packages for instance <Riggwelter> jpr: I think that's key <mw> Riggwelter: yeah. specifically packages that haven't declared stability and are apps <jpr> ie things over and above the usual guidelines <federico1> henne: git? :) <jpr> like %gconf <Beineri> matematic: those are also not allowed in the build service <henne> matematic: you wont have any luck with them in the BS either <Riggwelter> we need to discuss %gconf* and %fdupes <mtgordon> I'd think that fast-moving apps have the *potential* to be included... once they're sufficiently stable. <jpr> the lang extension too <Riggwelter> mtgordon: exactly, they can be "staged" in G:C <Riggwelter> jpr: thanks, forgot lang <federico1> or the kernel - tons of forks, they don't use the bugtracker, tons of changes every release :) <jpr> do we have someone who's interested in writing up the "extras" for GNOME packaging standards? <Riggwelter> let's move the kernel to G:C - all agreed? <rodrigo> are there 'templates' in the build service, so that you create a gnome package with all the gnome-specific parts put in? <jpr> as a draft <Riggwelter> rodrigo: hope that makes it to the minutes as an AI <jpr> rodrigo: that would be a cool idea <federico1> rodrigo: that would be really nice to have <mw> rodrigo: that'd make a good plugin :) <Riggwelter> templates would rock <Riggwelter> I've thought about it in the past <Riggwelter> give me that AI <federico1> rodrigo: like a fully commented-out specfile with all the goodies; I could use it for Mortadelo <mw> osc template --style=gnome <jpr> Riggwelter: excellent <rodrigo6> mw: yeah, right, but usually when you create a package in the bs you create the basic spec there <jpr> Riggwelter: i'm sure you can beat on mw to review it :-) <rodrigo> mw: but yeah, a plugin would work :) <jpr> rodrigo: osc-new_gnome_package ? :-) <rodrigo> yeah <Riggwelter> the BS generated spec template blows <jpr> rodrigo: osc-new_gnome_package <name> <url> rodrigo adds it to the ideas list <mw> rodrigo: the templates in the BS aren't too hot <rodrigo> mw: but can you write new ones? <henne> rodrigo: Template Based Package Creation is also on the future ideas list of the BS <rodrigo> ah cool <jpr> if there are templates in the BS that suck, we should send patches for the bs <Riggwelter> ror: will you be attending BS meetings? <nonsequtir> Just installed openSUSE 10.3 RC3, evince doesn't correcly scale PDFs when viewing, for ex, switch to full page with and it redraws, but leaves the page the same size, albeit in more whitespace. Anyone seen this? <Riggwelter> s/ror/rod: <jpr> i think sbrabec also has a tool <Riggwelter> nonsequtir: not the time <matematic> nonsequtir: fill a bug in bugzilla <jpr> that tries to automate the first packaging run <henne> jpr: yes but that is totaly disconnected :( <nonsequtir> (Sorry, forgot the meeting !) <Riggwelter> ok, so, gconf scriptlets <rodrigo> Riggwelter: if you send me a basic template with all the goodies, I can write quickly a plugin for osc <jpr> henne: yah, but it has a bunch of knowledge in it <Riggwelter> rodrigo: I'll do it tomorrow morning if I have time <jpr> ok, getting low on time <jpr> Riggwelter: anything else on the policy? <jpr> for today <jpr> or any other questions on it? <Riggwelter> not from me other than to say that once we have it more nailed, we need to make packages already in G:C meet it :) <jpr> hehe <jpr> yes <jpr> ok <rodrigo> :) <Riggwelter> and I'm as guilty of it as anyone ;)

<jpr> mw: 2 minutes update on the status of moving 2.20 to G:S <mw> not sure i can fill 2 minutes, but ok <mw> so i think per stanislav's suggestion we'll use linked packages from G:S to factory <federico1> type slowly and you'll fill 2 minutes <mw> for the moment, at any rate, and maybe indefinitely <mw> the more interesting question is what to do with G:U <jpr> what about GNOME 2.20.1? <Riggwelter> mw: indeed <captain_magnus> (G:S = GNOME;Supported and G:U = GNOME:Unsupported??) <rodrigo> mw: I think it would be very nice to have there gnome unstable releases <jpr> won't we have to unlink at that point? <matematic> is not too early for for 2.20.1 to enter unstable <mw> i'd like to see all of the future work going through there <jpr> captain_magnus: stable/unstable <Riggwelter> STABLE/UNSTABLE <rodrigo> mw: once we coordinate with the gnome build brigade <mw> jpr: yes, you're right, doh. <jpr> matematic: 2.20.1 should go right to G:S <jpr> unless we change the meaning of G:S <jpr> G:S is supposed to contain the latest stable release of GNOME <jpr> mw: do we need to update the due date then? <mw> the problem with G:S as it stands is that it doesn't necessarily receive security updates <Riggwelter> Thread starting at http://lists.opensuse.org/archive/opensuse-gnome/2007-09/msg00109.html is about this <matematic> stable according to GNOME releases? <jpr> ah, right <mw> i'd be reluctant to use it, personally, right now <mw> for just that reason <jpr> how many security updates are we talking? <jpr> maybe we just need to bit the bullet and do those <mw> if it's linked to Factory, then it'll get timely security updates, but then using G:U for ongoing work would be tricky <mw> jpr: not a whole lot -- some in evo, some in evince, packages like that <mw> the majority dont' see any <jpr> should we take this discussion back to the list? <mw> yes <jpr> ie the policy part <jpr> ok <Riggwelter> yes <jpr> presumably we need to actually write the policy down when its final <jpr> as well <mw> right <jpr> (even as a draft maybe( <mw> is the current policy written down anywhere? <jpr> no <jpr> well <jpr> yes <jpr> via email <mw> so it's just our senseless consensus? :) <jpr> very roughly <jpr> months ago <matematic> what is in G:U at the moment 2.19 ? <jpr> when they were first created

<jpr> ok, two items to go <jpr> first features <jpr> i'll send some stuff on the list <jpr> basically i volunteered at the project meeting to run a wiki based test of feature planning <jpr> as opposed to bugzilla or fate <jpr> basically a prototype to see if it will work or not <jpr> we have options like ubuntu's blueprint <jpr> or fedora's name scheme, ie wiki/Feature* <jpr> is there any one with a non-Novell perspective that would like to get involved with me there? <cyberorg> i liked idea.o.o <jpr> that was also suggested <jpr> cyberorg: is that a volunteer :-)? <matematic> doesn't we have idea.opensuse.org for this? <jpr> cyberorg is our kick ass compiz-fusion maintainer <jpr> i.o.o hasn't moved much since hack week <jpr> but yes, we could revitalize it there <cyberorg> jpr, i have two things, if i can sqeeze some time out of that :) <jpr> matematic: you also volunteering? :-) <captain_magnus> jpr: Non-Novell means people at Novell that doesn't work with that for a living I hope? <jpr> sure <jpr> i'm just concerned about getting someone's perspective who's never used fate for instance <matematic> jpr: I'm not sure that I'll have enough time but why not <jpr> so its not in a vacuum <jpr> cool

<jpr> last agenda item <jpr> Q&A <jpr> Q: Any plans for automation testing ? I propose LDTP for this task :) <captain_magnus> Then I would also suggest idea.o.o.... <jpr> A: not specifically, although automation of testing is also good <jpr> *always good <jpr> nags asked the question i think because he did some of this for hackweek <jpr> best thing might be to look at an osc plugin <nags> jpr, oh ya :) <jpr> and check in test scripts <jpr> osc-run_tests <jpr> or something <jpr> that would be cool :-) <jpr> Q: Any plans for new features to go into openSUSE 11.0? <Riggwelter> how about thought control? :) <jpr> A: Nothing specific, we are working on the method for that first <jpr> Q: There's a Bugs:GNOME wiki page that kind of describes how to submit a bug. We've also created a GNOME/Bugs page that lists what bugs we feel are the most important to fix. Do we want to merge these? Or do we want to have the Bugs:GNOME page redirect to a GNOME/Bugs HOWTO page? <Riggwelter> redirect - same as GNOME_Team <captain_magnus> Riggwelter: Agree <jpr> A: I personally think they should be separate, one is how gather bug info <btimothy_> although they are different things <btimothy_> jpr: right <jpr> the other is the plan for what to fix <jpr> comments? <Riggwelter> they should certainly both be under GNOME/ <mw> agree. the page with bugs should link to the page about how to report them, and vice versa <Riggwelter> whether they're one page or two <bradya> I agree with Riggwelter <captain_magnus> We need to fit the GNOME stuff under the same umbrella or we'll be lost <btimothy_> i can move Bugs:GNOME -> GNOME/Bugs_HOWTO <jpr> i think we still redirect <captain_magnus> Meaning, use GNOME/xx for everything... Redirect if we have to <jpr> Bugs:KDE <Riggwelter> jpr: you're right actually, two pages, both under GNOME/ <jpr> Bugs:Yast eetc <jpr> are all there <btimothy_> jpr: when you move a page, it automatically sets up the redirect <jpr> ok <Riggwelter> it can redirect for consistency with the rest of the project <hpj> i'm in favor of two interlinked pages, like mw <jpr> yes, it should be key to keep consistency <jpr> btimothy: actually, consistency should be the in the wiki_layout page right? <Riggwelter> both openSUSE consistency and openSUSE::GNOME consistency :) <jpr> it should be policy <jpr> yes <jpr> GNOME is not represented very well on the HOWTOs page. Could we create a GNOME/Tips and Tricks page and then include a link to it from the HOWTOs page? Anyone have some tips and tricks they'd like to share? You could be the one to create the GNOME/Tips and Tricks page!  :) <jpr> Q that is <jpr> A: Damn straight <rodrigo> we need to add lots of gnome docs to the wiki <rodrigo> so yeah, I agree :) <apokryphos> one useful thing might be an upgrade guie, like http://opensuse.org/KDE/Upgrade <jpr> in fact we have several desktop general things in the KDE equivalent i believe <jpr> that we could link to <jpr> or copy to start <apokryphos> users tend to ask that whenever there's a new version.. captain_magnus thinks that jpr forgot about the live q&a... <jpr> like captain_magnus getting there <Riggwelter> I need to duck out at this stage to give Rigg Jr his bath - have a lot of fun... <btimothy_> if any of you have the answers, create the page :-D <jpr> apokryphos: oddly, ximian desktop had one called "Doorman" <jpr> captain_magnus tried to resurrect it <jpr> but we failed him <jpr> for 10.3 <jpr> Q: Any plans of integrating and take full advantage of what compiz has to offer at application level? Also would like to know if any applications/libs are being written/planned like libsexier, AWN etc that would be part of next GNOME versions. <captain_magnus> jpr: Got ideas for 11.0 :-) <jpr> cyberorg: i assume you mean new stuff like svg rendering through compiz? <jpr> or? <rodrigo> I am currently looking at the gnome-panel discussion, and kiba-dock, awn, etc are being talked about <jpr> (thats on the upstream GNOME desktop-devel list for those interested) <rodrigo> that is, people are talking about having a new panel that merges all the good ideas from g-panel, kiba-dock, awn <cyberorg> jpr, i thought there would be more gnome hackers here :) <rodrigo> yeah, right: http://mail.gnome.org/archives/desktop-devel-list/2007-September/thread.html <rodrigo> GNOME Panel++ thread <jpr> cyberorg: there are lots here <jpr> but no david unfortunately <captain_magnus> cyberorg: openSUSE GNOME hackers are the only real GNOME hackers :-) <cyberorg> jpr, something close to what kde4 has done with compositing <jpr> david does have a bunch of plans for apps to be able to take advantage of compiz <jpr> to request effects on certain windows etc <jpr> also Fedora 9 is planning to use compiz by default from what I understand <jpr> so we should definitely look at that for oS 11.0 <henne> ubuntu too <cyberorg> cool :) <jpr> it would be pretty bogus if the creators of compiz didn't do that :-) <jpr> ok <jpr> general Q&A <jpr> go <captain_magnus> Suggestion; Build service/Packaging stuff should be either at the start or the end. I don't know anything about it and it's more for people who's involved, or who wants to be involved. So I suggest that we move those sort of subjects to the beginning or the end of the meeting. <jpr> noted <jpr> i'm not sure of the developer/user balance for these meetings yet <jpr> others? <captain_magnus> Hence my suggestion <jpr> yup <captain_magnus> I just want to say that I think this was great... <jpr> that reminds me <jpr> at least for now, we plan to keep these weekly <captain_magnus> And the work that's been done on thw wiki etc is impressing <jpr> we short changed the agenda already :-) <jpr> yes, thanks to all who have been editing <captain_magnus> jpr: I can't be there for more than this one... :-( 3.30am is pretty bad <jpr> times are hard to pick unfortunately <jpr> always bad somewhere <jpr> anything else? <captain_magnus> I know... Just saying... We have the same issue with the openSUSE status meetings in my time zone <henne> jpr: yes <jpr> henne: shoot <Beineri> captain_magnus: *project* meeting :-) <henne> what about summarizing in the project meeting? <henne> like buildservice etc do <jpr> oh, thats a good idea <captain_magnus> Beineri: Ops, sorry, don't know as I can't attend :-) <jpr> henne: why does the BS team not post the summary they use to the project meeting archive? <henne> that includes sending a mail to opensuse-gnome with a summary of the week <jpr> then everyone doesn't have to recreate the summary <jpr> from scratch <henne> jpr: every group posts to their own mailinglist and we collect in the agenda <jpr> hmm <jpr> ok <jpr> ah, cool <jpr> ok <btimothy> I only see 1 vote on this bug (GO ADD YOUR VOTE NOW!!!!): https://bugzilla.novell.com/show_bug.cgi?id=325753 <jpr> another AI <jpr> anything else? <btimothy> yes ^^^ :) <jpr> (future meetings I'll try to keep to an hour) <jpr> :-) <jpr> ok <jpr> THANK YOU ALL FOR COMING