<jpr> Happy 10.3 release and elcome to meeting #2 for the GNOME team! <jpr> We may be short a few people in .de and the EU who are already partying, but I think its a good idea to press on and get in the habit of having these meetings <Riggwelter> [1] - a thing of beauty <jpr> Hopefully we all agree last week was a succesful kick off captain_magnus nods <jpr> We've done a great job tackling the remaining criticals for the release today, and we should continue to monitor all majors and criticals going forward to support 10.3 as much as possible. <jpr> while looking forward to openSUSE 11.0 <AlbertoP> yup <Riggwelter> hear hear <jpr> as part of that several of us will be at the GNOME summit in boston this weekend <jpr> getting the 2.21/2.22 scoop <jpr> and talking up some of our own ideas <Riggwelter> taking 10.3 media to give out? <jpr> wasn't ready in time <jpr> but i have other swag <Riggwelter> :) <jpr> tshirts, stickers and stuff <aTypical> I want a tshirt.  ;-) <btimothy> 10.3-related swag? :) <Riggwelter> there's always one ;) <jpr> if anyone feels particularly strongly about any upstream issues <jpr> please poke btimothy, sreeves, mw, hpj, jpr or rodrigo <Riggwelter> jpr: float the idea of moving to Qt instead of GTK+ ;) <jpr> before this weekend <jpr> and we'll see what we can do <jpr> any questions about that? <aTypical> Not from me. <captain_magnus> Crystal clear <jpr> ok

<jpr> next item on the agenda <jpr> boyd, scott <jpr> take it away <captain_magnus> (wiki status (boyd and scott)) <jpr> btimothy: and sreeves <jpr> then to light up their tab :-0 <btimothy> jpr: well, scott and I aren't sure that there's anything new to report <sreeves> I don't have much to update this week on that <btimothy> other than to thank everyone for your help in filling out what's already there <jpr> my question was, should we consider the task done <jpr> and note its ongoing now? <btimothy> I think we're definitely moving in the right direction and have a good base <jpr> with the http://en.opensuse.org/GNOME/Wiki_Layout/Tasks <jpr> items? <btimothy> I think we can definitely mark the initial task as done <jpr> how do other feel on that point? <captain_magnus> Wiki is sloooow <btimothy> going forward, I think we just need to all take part in following the Wiki_Layout and help building the content up <rodrigo> apart from no mail notifications :), wiki is looking quite good <captain_magnus> Agreed, wiki is good... Might have some issues with the "tight" layout but... <jpr> any objections? <jpr> ok, if there are any tweaks, can probably go to the layout page or mailing list for discussion <btimothy> rodrigo: still haven't really heard anything on the mail notifications. the bug sits in bugzilla <rodrigo> yeah <btimothy> jpr: agreed <jpr> btimothy: i think henne was going to poke it, you might want to mail him <jpr> off the list! <btimothy> jpr: will do

<jpr> next <jpr> bug plan status <jpr> federico, rodrigo ? <rodrigo> I'll let federico update on that, he did the last additions to the page/plan <jpr> ok <jpr> federico1: proceed <jpr> one again federico1 is not paying attention <jpr> next item <mw> hehe <jpr> feature requests and mini projects <jpr> jpr, cyberorg, captain_magnus <captain_magnus> We've had discussions <jpr> captain_magnus: why don't you go ahead <captain_magnus> But we have not come to a conclusion yet... <captain_magnus> I prefer idea.o.o <captain_magnus> But we have yet to see fate in action <jpr> we have four main alternatives <jpr> 1) idea.o.o <jpr> 2) bugzilla <jpr> 3) wiki <aTypical> Maybe for us new people you could explain a little about what your group is doing? <cyberorg> idea looks good, out of the three <jpr> 4) partnerfate <federico1> I'm here <jpr> ah, sure <jpr> so <federico1> just finishing up the wiki :) <federico1> ok <captain_magnus> aTypical: We are trying to figure out the best way for people to suggest new ideas etc for GNOME <jpr> we are experimenting with how to handle features <jpr> project wide they have proposed partnerfate <jpr> i volunteered the GNOME group in the project meeting <jpr> to run some prototypes <jpr> as alternates <jpr> the 4 items above are the proposed alternatives <btimothy> my only beef with idea.o.o is that it's hard to see all the ideas "at once" for idea discovery <cyberorg> jpr, it would make sense to use the same tool the entire project uses <jpr> cyberorg: its not available yet <mw> i'm not wild about yet another nonstandard tool, which is what fate most definitely is <jpr> cyberorg: and i'm not convinced its the best way <captain_magnus> cyberorg: That's the plan eventually... We are taking the lead <jpr> although you and captain_magnus seem more up for it than mean <federico1> a wiki is nice to propose features, since you can flesh them out nicely <hpj> wiki +1 <jpr> everything has pros and cons so far <mw> i agree with federico <btimothy> wiki +1 <federico1> FATE looks to me like the "manager's feature spreadsheet of death" <jpr> well <mw> well, a wiki to flesh out the idea, bugzilla to track it <jpr> partnerfate is much more trimmed down <jpr> its closer to idea.o.o actually <mw> ie, to assign someone responsibility to make it happen <rodrigo> idea.o.o looks very good to me, if we can make it easier to search/look at ideas <jpr> idea.o.o is not really maintained atm <jpr> i got the source <rodrigo> then I'd vote for the wiki <cyberorg> btimothy, idea is built on DokuWiki so someone might be able to hack one page listing of all ideas <jpr> captain_magnus, cyberorg : have a chance to look at it? <matematic> jpr: also not very popular <aTypical> what is idea.o.o? <btimothy> another benefit of wiki is ... you can just quickly view/add/edit/etc. <matematic> I found it accidentally <captain_magnus> jpr: Look at..? <matematic> aTypical: idea.opensuse.org <aTypical> thank you <btimothy> cyberorg: possibly <jpr> idea.opensuse.org <jpr> it was the site used during the hackweek <jpr> in June <hpj> the wiki needs mail notification and maybe some templates to do it <hpj> but nothing big i suppose <jpr> captain_magnus: the idea.o.o source <federico1> hpj: yeah, that would help a lot <captain_magnus> jpr: Hah! Yeah, had a quick look but not a web hacker... <jpr> hpj: infobox templates would be used to help standardize <afonit> wow, wow, wow thanks for the super fast package manager, in 10.3 that is great <jpr> however <jpr> it still requires a lot of manual oversight <federico1> the template could have "use case", "GUI mockups", etc. <jpr> making sure the features are listed all in one spot <jpr> they use the templates <jpr> etc <captain_magnus> I would ask for jpr, cyberorg and myself to get one more week to look into it.... <cyberorg> jpr, couldn't get idea source working here though <captain_magnus> Each tool have it's pro's and con's <captain_magnus> What's really important is for noobs to be able to file a request <captain_magnus> without having to read a manual <aTypical> captain_magnus, agreed. <jpr> also <jpr> wiki doesn't have voting <jpr> which is nice on bugzilla and idea.o.o <jpr> i might suggest we get a wiki page going as a dumping ground in the mean time <jpr> but keep it to a single page <captain_magnus> So far, none of the solutions is up for it (my feelings) <jpr> i have like 30 things already <jpr> that i'd like people to get talking about <federico1> captain_magnus: I think we should minimize the number of tools... we already have bugzilla, which is nice to follow up on how a bug gets fixed; and the wiki, which is nice and freeform (and everyone knows how to use it) <jpr> (granted some are simple package requests) <cyberorg> ok, we'll put pros and cons of each on a wiki page, and let jpr move to next agenda :) <captain_magnus> federico1: bugzilla is easy for you and me... Ask a noob to file a rfe in bugzilla and you'll see that it's not so easy for them <jpr> i see three AIs then <jpr> a) pros and cons on a wiki page <jpr> b) create and initial dumping ground page for brainstorming (one page only) <matematic> captain_magnus: bugzilla is not a bug track system for noobs <jpr> c) continue research of cyberorg captain_magnus jpr <hpj> i haven't tried idea.o.o, but it sounds like we must be prepared to maintain it and possibly extend it if we're to use it <federico1> captain_magnus: that's what I'm talking about... RFEs should go in the wiki :) <jpr> hpj: yes <captain_magnus> metavoid: We want everyone to be able to ask for a new feature! And we're looking at 4 different tools at the moment <jpr> does everyone agree on those 3 action items? <btimothy> I may have pointed it out before, but we've used the wiki idea for Tomboy and then bugzilla when we decide on a specific task...or create additional wiki pages for more in-depth discussions: http://live.gnome.org/Tomboy/PlaceForNewIdeas <captain_magnus> jpr: Yes <jpr> am i missing anything? <rodrigo> jpr: yes <hpj> jpr: yes <btimothy> seems to have worked pretty well and it's nice and simple/easy <jpr> cyberorg: agreed on the AI? <federico1> jpr: looks fine <federico1> there are also voting plugins for mediawiki which we could use <jpr> federico1: oh, good to know <btimothy> jpr: AIs look good <mw> AIs look good <jpr> ok <jpr> cyberorg defaults to a "yes" <jpr> :-) <federico1> (also, have people seen the fckeditor plugin for mediawiki? it's teh sexy for wysiwyg editing) <cyberorg> jpr, yeah <jpr> ok, thanks for the feedback <jpr> aTypical: we'll also put the background info on the wiki page as well <aTypical> Thanks. <captain_magnus> jimmac might be able to help out?? <jpr> you raised a good point

<jpr> federico1: ok, federico1 go to it - maybe provide a two sentence project summary <federico1> ok <federico1> Rodrigo and I have been thinking of how to sort bugs for fixing them <federico1> so far we have this: http://en.opensuse.org/GNOME/Bugs#Criteria_for_bugs_to_fix <aTypical> If I could also make one more suggestion. You might want to put the channel in moderator mode while holding meetings. We've done that with the group I work with and it helps keep the channel focused on one topic at a time. <federico1> the idea is that there are things which prevent you from getting work done, and things that are annoying but you can still do your work <federico1> and so we should fix the work-stoppers first <rodrigo> we already have a big list of bugs to fix in http://en.opensuse.org/GNOME/Bugs <captain_magnus> federico1: Agree with the priority <rodrigo> (sorted by category) <captain_magnus> aTypical: We have not had to much noice "off topic" in our meetings so no point of moderating at this point in time <hpj> federico1: then we'll be fixing printing bugs forever :) <aTypical> OK. <federico1> Now, to actually do the sorting, we can use the same method as used for http://live.gnome.org/GtkFileChooser --- sort the bug list by bug number, then go one by one and put them in the wiki. In the wiki we also write "number of last classified bug: 123456" and update that when we add more bugs to the list. <federico1> hpj: that's not a bad first priority given the way things are :) <federico1> now, we don't need to put every single bug in the wiki <federico1> for example, uninteresting enhancements can remain solely in bugzilla <hub> there is definitely a crah bug somewhere in X <federico1> but for really interesting ideas, it would be good to have them in the wiki as well <hub> I was nowhere near backspace <jpr> hub: meeting <hpj> can't we just put a link on the wiki page, to a bugzilla query with the specific list of bugs? <hub> sorry <hpj> then people can sort it however they want, and there will be less work to update the bugs on the wiki page <federico1> hpj: sure - we just need to tag bugs appropriately <rodrigo> hpj: there are queries already, but we added some important bugs out of those lists <rodrigo> in the long term, we might just want the queries <captain_magnus> federico1: Could we tag them by priority in bugzilla? <rodrigo> (once people vote enough for bugs, for instance) <jpr> currently Priority would conflict <jpr> with internal support usage <jpr> we could use the whiteboard however <jpr> if we standardize the tags <jpr> gnome_workstopper <jpr> or something <rodrigo> yes, that would work <rodrigo> and we could just have the queries pointing to those bugs <jpr> federico1: do we not need to differentiate between bugs in the must recent shipped product and older? <captain_magnus> Hmm... whiteboard is free text... Keywords is not... Would keywords conflict internally as well? <jpr> and also distinguish between bugs in factory and released products <jpr> captain_magnus: no, but we'd need our own keywords <rodrigo> captain_magnus: I don't think so, if we use some namespace for out keywords <jpr> federico1: i can see for instance not fixing a "normal" in 10.2 now <jpr> if its fixed in 10.3 <decriptor> hey all, trying to get a head count for the provo launch party <captain_magnus> jpr: Would it not be better to create our keywords then... That way, we can't make a typo etc, which could make a bug "disappear" <jpr> decriptor: meeting in progress <decriptor> ooops sorry <jpr> captain_magnus: sure <jpr> federico1: listing bugs we won't fix downstream only might also be useful <federico1> hmmm <jpr> federico1: ie we won't unilaterlly change strings <jpr> because that breaks translations <federico1> jpr: I'm still wondering how to see if old bugs are present in the newest release, other than just testing them all by hand :) <jpr> i checked earlier today <jpr> there are 58 GNOME bugs <jpr> 10.1 and older <federico1> maybe we can find volunteers, and ask them "you test bugs 100000 to 105000", "you test 105000 to 110000", etc? <jpr> maybe we should kick off a project to review them all <jpr> we could probably do it in < 4 hours of IRC time <rodrigo> yes, bug squashing days! <jpr> especially if it was parallelized <captain_magnus> Kick off a project and offer people a gecko if they are useful :-) <rodrigo> yeah, some kind of prize would attract more people :) <aTypical> captain_magnus, I already have a gecko. I want a t-shirt.  :-) <jpr> mtgordon: this has probably been in the back of your mind for a while, can i append an agenda item to this meeting? <cyberorg> *geeko <decriptor> I'll help squash bugs for swag :P <captain_magnus> aTypical: If you were my customer, I would give you a t-shirt :-) <mtgordon> jpr: sure <aTypical> You're a good man, captain_magnus <jpr> great <jpr> lets go back to federico's bug plan <jpr> federico1: so, do you think we need to differentiate policy <jpr> federico1: based on what i said above? <aTypical> jpr, any thought of putting the bug fix out to LUGs and making it a competition? Maybe the group that checks the most can have an openSUSE sponsored party? <federico1> jpr: for old vs. new bugs? <jpr> federico1: for factory vs released product bugs <federico1> ah <jpr> federico1: and for bugs in products older than the last released <jpr> aTypical: oh, also a great idea <hpj> federico1: flow chart! flow chart! <mtgordon> jpr: I'm starting to see bugs specific to GNOME:Community, FWIW <jpr> good to know <cyberorg> apokryphos, is our guy who can get people excited about bug squashing, only problem is last time we ended up adding lot more bugs :) <jpr> they all get assigned to Riggwelter ! :-) <Riggwelter> lol <federico1> jpr: there's less of an incentive to fix bugs for older products, except when those bugs are still in the new product (those should automatically get a higher priority). I'd love a way to say in bugzilla, "happens in 10.2 and 10.3" <captain_magnus> God help him :-) <Riggwelter> I am here you know? ;) <apokryphos> bug hunting is more helpful ;-) <mtgordon> Well, it's one he packaged. <federico1> jpr: and for factory vs. released, we first have to get people to try out factory :) <jpr> people were a lot more this time <hpj> federico1: i second that feature request. list of versions, not just "appears in version x" <jpr> the numbers testing grow every time <jpr> cyberorg: well, i'm pretty sure we wouldn't end up with more 10.0 bugs :-0 <cyberorg> jpr, i wouldn't be able to find 10 anywhere, so i won't be adding to it <federico1> hpj: you could hack it with a meta-bug... bug A refers to 10.2, bug B refers to 10.3, and both are blocking on bug C - which has the real info <jpr> federico1: gekker 's document had i think normal or below for 10.1 would just be closed if it was fixed in 10.2/10.3 <hpj> federico1: cumbersome <federico1> hpj: very <hpj> federico1: also, think about cc lists etc <jpr> lets not get bogged down on my specific question <jpr> but i humbly request you consider it <jpr> :-) <federico1> jpr: is the bugzilla team responsive on feature requests? <federico1> jpr: going back to factory vs. released... <jpr> hit and miss <captain_magnus> federico1: They are <federico1> factory tends to be scary, because it is the whole distro in flux <jpr> i think its kind of irrelevant <mw> federico1: yeah, that's part of the raison d'être for GNOME:UNSTABLE <federico1> but if we make GNOME:Unstable work well so that you can test a newer GNOME on your stable distro, that sounds more doable <jpr> we *need* people to use factory <jpr> or how do we testing for 11.0 <captain_magnus> jpr: Agree <jpr> we can't bug fix everything after a release <federico1> jpr: yes, we do <federico1> but we have a very bad track record of pre-beta3 releases :) <jpr> ok <federico1> "gdm doesn't work" happens every time <hpj> is it possible to make factory break less early in the cycle? :) <jpr> but thats irrelevant to this discussion <jpr> isnt' it <jpr> ? <jpr> i think the key is that we are more apt to fix normal, minor bugs, get changes upstream <federico1> jpr: I don't think so... there are some things in our process that cause factory to be unusable until rather late in the development cycle <jpr> and pull them back in factory <jpr> for factory <jpr> we are much less likely to do those things in a released product <federico1> remember the only good line in the latest Bourne movie - "hope for the best, plan for the worst" <mw> hpj: gnome will probably have fewer nasty surprises in the leadup to 11.0, since there'll be more time between when gnome 22.0 comes out and 11.0 <jpr> federico1: i'm not clear how that relates to the bug plan specifically though <mw> hpj: we cut it pretty close for 10.3 <hpj> mw: yeah <hpj> mw: i was thinking about bugs below gnome in the dependency chain, though <mw> nod <federico1> jpr: ok... so it's probably easier to make people test GNOME:Unstable than Factory <federico1> (at this point) <rodrigo> yes <mw> hpj: i wish we'd gotten the -langification work done much earlier, for example <jpr> ok <jpr> tracking back on again <jpr> my fault <federico1> we probably need a few instructions on how to roll back your packages to GNOME:Stable <captain_magnus> I'm happy with the work federico1 and rodrigo has done on the wiki page... Looks good and it invites me to participate... <federico1> for things break horribly <jpr> it seems like we have quite a bit of detail work to do on the specifics of prioritizing the bugs, but we have great data now <jpr> yes/no? <mw> aye captain_magnus nods <rodrigo> yes <hpj> yes <jpr> federico1: anything more you'd like to add? <jpr> any help you need? <rodrigo> revieweing bugs would be really useful <federico1> probably just to request people to vote on bugs they consider important, and to see if their 10.2 / 10.1 bugs are still in 10.3 <rodrigo> so if everyone could do a little bit, that would be good <jpr> ok <jpr> thanks <jpr> next up <jpr> community inclusion <jpr> policy <jpr> Riggwelter: are you there? <cyberorg> novell bugzilla has a nice reminder that goes to asignee if the bug has not been acted for a week <Riggwelter> yes <federico1> one last thing <federico1> should we WONTFIX 10.1/10.2 bugs that don't get a reply in, say, 30 days? <captain_magnus> federico1: I think INVALID if needinfo for more than 30 days <jpr> we've had a policy to close bugs that are NEEDINFO'd to non-developers <decriptor_> federico1: what if you post a predefined bugzilla search for the 10.1/2 bugs? <jpr> for more than 14 days <rodrigo> federico1: probably we should add a query to the wiki, like the one for 'no activity in the last 30 days' <jpr> we currently have that policy in fact <jpr> there is also a NORESPONSE <rodrigo> federico1: then we can easily review those <mw> federico1: yes, probably, but only after a bug day <jpr> resolution now <federico1> ah, ok <federico1> decriptor_: hmm, I think we have one, let me check <rodrigo> decriptor: en.opensuse.org/GNOME/Bugs has querties for that <rodrigo> not for 10.1 though <federico1> decriptor_: yeah, check http://en.opensuse.org/GNOME/Bugs - we are just missing one for 10.21 <federico1> 10.1 federico1 high-fives rodrigo <jpr> federico1: actually i would suggest 10.1 and older <rodrigo> AI -> add query for 10.1 bugs <jpr> its only 58 bugs <jpr> total <rodrigo> yeah <jpr> ok

<jpr> next topic for real <jpr> Riggwelter: go <Riggwelter> this is a very quick update actually <Riggwelter> We're waiting on packaging guidelines to finally nail the G@C policy <Riggwelter> The BS doesn't (yet) support multiple templates, so that comes down to an OSC plugin <Riggwelter> and the spec template has been sent to Rodrigo <Riggwelter> brief enough guys? ;) <rodrigo> yes, the plugin is almost done, just need a bit of time <captain_magnus> Riggwelter: Yep :-) <jpr> who are you waiting on? <jpr> am i still connected? <mw> you are <Riggwelter> for...? <jpr> Riggwelter: the packaging guidelines <Riggwelter> ummm... <Riggwelter> let me check <Riggwelter> there doesn't seem to be a Task for it <jpr> Riggwelter: aha, problem :) <captain_magnus> haha <jpr> rodrigo: did we miss an action item last week? <Riggwelter> jpr: confirmed <Riggwelter> problem indeed <rodrigo> hmm, maybe <jpr> AI: rodrigo to look for who does packaging guidelines :-) <jpr> Riggwelter: good update rodrigo will review both transcripts tomorrow on the plan <jpr> anything else for Riggwelter ? <Riggwelter> I think it'll be in the log of last week, it was discussed IIRC <rodrigo> yeah, might have missed it <federico1> Riggwelter: can you access templates from the web interface? <rodrigo> federico1: no, there's only one federico1 would love one for Mortadelo <Riggwelter> federico1: BS doesn't support multiple temps at all <federico1> ah, ok <federico1> I'll just cut&paste, I guess <Riggwelter> (yet) <rodrigo> federico1: get the one Riggwelter wrote from my git repo <Riggwelter> federico1: I can DCC it to you <federico1> Riggwelter: mail is better, please - federico@novell.com :) <federico1> rodrigo: url me :)

<jpr> ok, next topic <mw> yo <jpr> G:S <Riggwelter> sent <jpr> mw: do you need to cover more than whats on the mailing list? <captain_magnus> GNOME:STABLE merge status (mw) <mw> jpr: i was going to summarize what i said on the list <jpr> do it <rodrigo> federico1: http://www.gnome.org/~rodrigo/git/osc-plugins.git <rodrigo> federico1: file is osc-plugins/data/template-gnome.spec <mw> ok, so, a week from today (20071011), I'll be updating GNOME:STABLE and GNOME:UNSTABLE to be essentially what's current in Factory <captain_magnus> jpr: If you copy/paste the agend topics, it's probably easier to create the minutes later on... <jpr> true <federico1> Riggwelter/rodrigo: thanks! <captain_magnus> mw: Stable as well? <mw> they'll start out identical, but will diverge from there: GNOME:STABLE will not long thereafter be updated to gnome 2.20.1, whereas GNOME:UNSTABLE will be updated to gnome 2.21.whatever <mw> i really want to push all gnome packaging and development that we (= anyone working on opensuse, internal or external) do into GNOME:UNSTABLE <Riggwelter> guys, I have to run, try to keep my AI points to minimum in my absence ;) <rodrigo> :) captain_magnus gived all AIs to Riggwelter <federico1> mw: that sounds really nice <mw> in about 5.5 months, gnome 2.22 will come out. at that point, we'll need to "branch" GNOME:UNSTABLE <federico1> mw: should we link packages from individual repos into the master G:Unstable? <mw> the new branch will have gnome 2.22 which continue to be fed into factory, whereas :UNSTABLE will continue to have the latest and awesomest <captain_magnus> mw: Will G:U follow Factory (or the other way around)? <mw> federico1: good question, not sure <mw> captain_magnus: i want factory to follow G:U <mw> captain_magnus: it follows that nobody should be mucking with our packages directly in factory -- any changes will need to come from G:U (or its branch) <mw> captain_magnus: packages from G:U will just be synced automatically <captain_magnus> mw: Sounds great... Will enable people to be involved... <rodrigo> mw: as you said on the list, we can make the BS to reject changes directly into factory, right? <mw> rodrigo: currently, factory is synced periodically from STABLE internally, so only internal people can change it... <mw> rodrigo: so i guess it'll be that submissions to STABLE will be rejected unless they're sourced from G:U <rodrigo> ok <federico1> [side question - do we have a glossary so that newbies can learn about "factory" vs "gnome:stable" vs "gnome:unstable", etc.?] <captain_magnus> federico1: That's an AI for you :-) <jpr> federico1: http://en.opensuse.org/GNOME/Software_Repositories <federico1> AI for me - start a glossary with Factory, G:S, G:U, etc <captain_magnus> federico1: No, I take that back.. Please don't! <captain_magnus> federico1: We need you to do coding, performance things etc... Leave the glossary to someone else <captain_magnus> jpr: We should add Glossary to Tasks <jpr> mw: how would you branch exactly? I presume what you are trying to achieve is 2.23.x being available while 11.0 is finalize <mw> captain_magnus: yes, more people can be involved this way. currently, we get some patches and suggestions, and those will continue to be welcome, but i want more people involved and getting their hands dirty, figuratively speaking, too <mw> jpr: i'm not entirely sure. i think the thing to do will be to stop G:U submissions for a short time, create a new repo, copy G:U to the new repo, and then open both up again <jpr> wouldn't process wise we always want to sync the same repo to factory internally? <jpr> and that model would make it G:U sometimes <jpr> but not other times right? <rodrigo> mw: if we want people to be involved also on old distro releases, it might be good to create those branches (GNOME:openSUSE11, etc) to help supporting that <mw> true <mw> jpr: so are you suggesting an intermediate "feeder" repo for the actual syncing? <jpr> i think what i'm suggesting is G:S as is <jpr> and a GNOME:Factory that is always synced to STABLE internally <jpr> and possibly links from G:U <jpr> or G:U links from G:F <jpr> that might be a lot of work though <mw> jpr: it might be :) captain_magnus takes on the tasks to whip up a glossary for GNOME... We can expand that later for openSUSE in general <mw> jpr: also, ongoing unstable gnome packaging could stall like that <jpr> how so? <jpr> G:U would always be available? <jpr> s/?// <mw> if it has the same contents as G:F then between gnome 22.0 and opensuse 11.0 it won't be updated <jpr> it could link there <jpr> to reduce work <jpr> it wouldn't have to though <mw> jpr: well, my question is the following: between 2.22.0 and 11.0, where will fixes for 2.22.0 be done? <jpr> G:F <jpr> you can unlink the necessary packages <mw> ok, and post 11.0? <jpr> or G:F can link to G:S <hpj> it's starting to sound to me like the real problem is the existence of Factory :) <jpr> no where :-) <mw> we'll still have the occasional security fix <jpr> yah <jpr> G:S i guess <mw> ok, and when 11.1 comes out <mw> where will gnome bugs in 11.0 be fixed? <captain_magnus> Looks like the discussion should go on for the "GNOME:STABLE merge status (mw)" task later (on ML, IRC...)?.... <jpr> mw: internally only <mw> jpr: why? :) <jpr> actually <jpr> well <jpr> because people using 11.0 and tracking G:S <jpr> should get updates from there <jpr> it wouldn't be 11.0 specific in that case <jpr> it would be G:S specific <jpr> captain_magnus: ok <jpr> mw: should we cap it off and go back to ML? <mw> jpr: yes <jpr> ok <jpr> low on time (again!) <mw> anyway, assuming we can arrive at a consensus, i'll be moving some packages around in a week <jpr> :-) <jpr> mw, rodrigo,mtgordon: can we punt till next week? <jpr> and move right to Q&A? <mw> fine with me <mtgordon> fine

<jpr> ok Q&A :-) <captain_magnus> jpr: There should always be 2 hour for these meetings... If we finish it off earlier, cool, time for a beer, if not, 2 bad... :-) <jpr> MBoman What, if any, plans do the GNOME team have for openSUSE 11.0 (ie, new features etc that does not come from the community)? <rodrigo> jpr: yes, fine, I need to do my baggage :) <jpr> A: all our features should be out in the open <jpr> nothing terribly specific atm <mw> oh crap, i need to pack too, to see what other items of clothes i need to wash <jpr> other than a few things like bluetooth <jpr> compiz <jpr> gnome 2.22 <jpr> etc <captain_magnus> jpr: So nothing was put on you from management? <mw> will we be using banter instead of pidgin by then? <jpr> captain_magnus: not yet anyhow :-) <jpr> calvin: want to take that question? <AlbertoP> is the yast-gtk team connectec with gnome team? <AlbertoP> connected* <jpr> sort of <jpr> it was written by a GSoC student and michael meeks <captain_magnus> AlbertoP: They all work for Novell ;-) <jpr> btimothy: is doing some bug fixing right now <jpr> Q: MBoman I think we decided to put http://en.opensuse.org/GNOME/Tasks on the agenda so that it can be cleaned up, point fingers at people who have not finished :-) <btimothy> :) <jpr> ah <calvin> jpr, mw: no, I don't want that question... it's one I'd like to know <jpr> yes <AlbertoP> well, get prepared to receive a list of bugreports for the package selector, considering it's impossible to receive an answer in a more friendly and fast way <jpr> we hsould have that on the agenda <jpr> AI: put task list review on the agenda <calvin> jpr: I think collab is a question we are trying to figure out still <AlbertoP> is it possible to lock a package? taboo a package? change architecture to a package? <jpr> AlbertoP: you saw the test packages btimothy sent out? <jpr> ah <AlbertoP> yes <jpr> ok, those things aren't done <AlbertoP> I saw them <btimothy> I need to get this other bug fixed and resend out a newer package <jpr> other questions? <AlbertoP> ok...thanks, at least I don't have to write 3 reports :) btimothy is not sure that the yast2-gtk package manager ought to be the way we charge forward <btimothy> but we can fix the most annoying bugs in there at least <AlbertoP> no, just asked these n times on #yast and never got a word as an answer ^^ <captain_magnus> btimothy: What would you suggest? <btimothy> not sure we ought to get into that right now during the mtg. <captain_magnus> AlbertoP: YaST is a very broad subject... Not a single module within... <jpr> LAST CALL FOR QUESTIONS <captain_magnus> btimothy: Ok, wait for 2 seconds and then we can talk :-) <AlbertoP> captain_magnus, and "I don't know" is also an answer <btimothy> heh <captain_magnus> jpr: Yes, have one <captain_magnus> Bah! <jpr> Thanks all! <jpr> will post for next week <jpr> need a little work to make this flow better