13:07:11 <ennael> #startmeeting 13:07:11 <Inigo_Montoya`> Meeting started Thu May 31 13:07:11 2012 UTC. The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:07:11 <Inigo_Montoya`> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:07:16 <ennael> hi all thanks for attending 13:07:49 <ennael> I've proposed this meeting as I wanted to speak with you all about QA team and organization 13:07:58 <ennael> as it's a very big concern for council also 13:08:18 <ennael> #chair coincoin Stormi MrsB 13:08:18 <Inigo_Montoya`> Current chairs: MrsB Stormi coincoin ennael 13:08:25 <ennael> #topic QA team organization 13:08:34 <ennael> (you can speak I only eat babies) 13:09:06 <ennael> outch they are all dead 13:09:08 <Stormi> well, you probably want to introduce the topic 13:09:12 <ennael> yep 13:09:24 <ennael> so I will try to be as short as possible 13:09:44 <ennael> some facts we saw these last months/weeks: 13:09:59 <ennael> - very few people in QA team, it needs to grow up really 13:10:13 <ennael> - QA is not considered as "sexy" as being packagers 13:10:32 <ennael> - few people and busy people as we had hardly testers for isos tests 13:10:45 <ennael> - very few people for meetings 13:11:15 <ennael> - some conflicts that happened for sure because of a lack of communication (I will not speak about who and where :) ) 13:11:40 <ennael> so basically it seems current team needs to improve organization and make his work known and advertise it 13:11:52 <ennael> we have for now coincoin and Stormi as team leaders 13:12:09 <ennael> who are quite busy at least for isos tests 13:12:24 <coincoin> and we were not really here next weeks... I apologize 13:12:37 <Stormi> s/next/previous/ 13:12:44 <coincoin> thx 13:12:50 <ennael> what I saw during all release is the great work of MrsB managing all the todo list 13:13:07 <ennael> and what I really liked in her work is also the way she managed people 13:13:20 <ennael> it was rather efficient despite lack of volunteers 13:13:25 * MrsB blushes 13:13:39 <coincoin> +1 13:13:53 <ennael> imho a team leader is not always a technical guru and managing requires other qualities 13:14:17 <ennael> so I'd like to propose MrsB as team leader with existing one or in place or whatever... 13:14:30 <ennael> it's not usual process but I think we must find solutions 13:14:35 <ennael> wdyt ? 13:14:46 <DavidWHodgins> Sounds fine to me. 13:14:49 <MrsB> I'm happy to do so if others are ok with it 13:15:16 <Stormi> Well, I thought of her already, but thought she wasn't interested in it as she didn't candidate in last elections 13:15:37 <Stormi> I'm ok provided we re-do the elections 13:15:38 <ennael> she was too shy :) 13:15:59 <Stormi> because we can't just change team leaders in a meeting 13:16:00 <MrsB> There were already candidates and I'm not really ambitious, if you see what I mean 13:16:03 <ennael> ok but this needs to be done quickly so that QA team can work properly 13:16:16 <coincoin> I entirely agree with you about MrsB and I can leave my place OR see if we can work togheter to rise the team and lead it better than now 13:16:23 <ennael> so who can manage this election ? 13:16:43 <MrsB> yes, election would be best 13:16:46 <coincoin> I can like for previous election if needed 13:16:54 <coincoin> by mail of epoll 13:17:06 <ennael> or ? 13:17:08 <coincoin> or 13:17:15 <coincoin> sorry, to much french fries at noon... 13:17:15 <ennael> epoll is a good friend of coincoin :) 13:17:21 <ennael> ok 13:17:24 <ennael> deadline ? 13:17:37 <coincoin> before next Monday meeting? 13:17:40 <ennael> great 13:17:43 <ennael> everybody ok ? 13:17:47 <Stormi> ok 13:17:48 <coincoin> ok 13:17:51 <DavidWHodgins> ok 13:18:04 <MrsB> I'll be away this weekend, leaving tonight, so don't have time to print election fliers :D 13:18:10 <coincoin> :) 13:18:18 <ennael> #action coincoin will organize new election before next council meeting 13:18:35 <Stormi> MrsB: maybe send a mail to explain your candidacy like we did last time 13:18:52 <Stormi> if you have time 13:18:52 <ennael> yep sounds sensible 13:18:52 <MrsB> yes, i'll do that after the meeting 13:18:54 <coincoin> Stormi: sure, just after this meeting, it will be good 13:19:07 <ennael> second point is about general organization 13:19:30 <ennael> I spoke quickly with coincoin but maybe we should wonder if irc meeting are needed very often 13:19:41 <ennael> it seems QA people are not always active 13:19:50 <MrsB> I'd like to have them more regularly 13:19:52 <ennael> stay around, leave and come back 13:20:09 <ennael> so there is something to find about this 13:20:11 <MrsB> I think what we've missed in the team is the 'team' so far 13:20:29 <MrsB> iso testing seemed to bring everyone together 13:21:00 <MrsB> I'm sure we could agree a time and day for a meeting 13:21:02 <ennael> yep because it needed team work 13:21:30 <coincoin> MrsB: it was already done but only 2 3 ppl when doing a meeting... so we stopped 13:21:36 <ennael> ok so I would advise to work on that part next week so that a solution can be found quickly 13:21:59 <ennael> and maybe contact all people who did some tests on isos 13:22:03 <MrsB> yep, so some emails to qa-discuss 13:22:17 <djennings> fwiw: It would help if there was a reminder email shortly before a meet started. This is the first one I have remembered to attend 13:22:19 <ennael> they may be interested in a more permanent contribution to QA 13:22:53 <coincoin> djennings: we can do this if needed yes 13:22:53 <MrsB> I've been twisting people's arms :D 13:23:00 <ennael> :) 13:23:05 <ennael> and finally 13:23:08 <Stormi> yes reminder is always needed 13:23:13 <ennael> about isos tests, 13:23:26 <ennael> we really need some strong process and docs to help on this 13:23:41 <ennael> coincoin did provide some but maybe hard to use on wiki by multiple users 13:24:01 <MrsB> It isn't only that, the info for validation needs looking at too 13:24:03 <ennael> imagination is needed there :) 13:24:11 <ennael> yep 13:24:12 <MrsB> I started a tips and tricks page to help for that 13:24:32 <ennael> I let you work on this :p can give a hand if needed at some times 13:24:50 <MrsB> I think the existing pages are valuable but need rewritign and expanding 13:25:02 <ennael> I have 2 other topics 13:25:10 <coincoin> I had idea for a new "report" system but lack of time... I think we will have to discuss about it again (was done in a 2011 meeting IIRC) 13:25:22 <ennael> then I'll let you going on meeting 13:25:41 <ennael> #topic Mageia 3 release planning 13:26:22 * ennael looking for the dates :p 13:26:53 <ennael> Alpha 1 04/09/2012 13:26:53 <ennael> Alpha 2 04/10/2012 13:26:53 <ennael> Alpha 3 06/11/2012 13:26:53 <ennael> Beta 1 12/12/2012 13:26:53 <ennael> Version freeze 02/01/2013 13:26:56 <ennael> Beta 2 11/01/2013 13:26:58 <ennael> Beta 3 12/02/2013 13:27:01 <ennael> Release freeze 21/02/2013 13:27:03 <ennael> RC 05/03/2013 13:27:06 <ennael> Final 20/03/2013 13:27:16 <ennael> it's not yet complete as we are missing freeze dates for i18n and artwork 13:27:22 <ennael> it will be then published 13:27:52 <MrsB> we can add those on one of our pages too 13:27:53 <ennael> so isos marathon is due for spring time :) 13:28:02 <ennael> it will be added on first page of wiki 13:28:06 <ennael> should not be long 13:28:19 <ennael> questions on planning ? 13:28:47 <ennael> (they all ran away...) 13:28:47 <MrsB> i don't know about others but I felt the final stages of release were rushed.. 13:28:52 <DavidWHodgins> Too many iso images. I'd like to see a pair of live dvds instead of so many cds. 13:28:58 <MrsB> i put a note about it on the post mortem 13:29:03 <ennael> DavidWHodgins: we will discuss it soon 13:29:08 <ennael> but indeed too many of them 13:29:15 <MrsB> yes lots 13:29:23 <ennael> MrsB: the only reason is that bug fixing started very late 13:29:35 <ennael> it's our job (packagers team) to improve this 13:29:45 <ennael> some of the bugs were opened for a long time 13:29:52 <coincoin> yes, why not less CD images and DVD of ~ 900Mo/1Go with more languages? 13:30:00 <MrsB> yeah, here were a number which stayed from betas etc 13:30:06 <ennael> yep 13:31:22 <ennael> anything else on that topic ? 13:31:34 <MrsB> nope 13:32:10 <DavidWHodgins> Instead of wiki, something that can be worked on while offline. 13:32:15 <djennings> Yes why not make the Dual CD a dual DVD. 13:32:52 <DavidWHodgins> If the live cds become live dvds, it would be nice to still have the dual cd for people with low download limits 13:33:06 <ennael> decision about number of isos will be discussed all together 13:33:17 <ennael> as some peple needs CD format 13:33:26 <ennael> band it will not be solved today :) 13:33:56 <coincoin> CD is good for poor bandwith 13:34:00 <MrsB> dave you mean the check box sheet? 13:34:20 <ennael> it's not only poor it's also about paying bandwidth 13:34:20 <djennings> The dual CD consumed a lot of testing time because it was so space constrained. A single CD would be easier if you want to keep size down 13:34:46 <DavidWHodgins> MrsB: Yes 13:35:01 <MrsB> we could design a pdf maybe 13:35:12 <Stormi> a pdf for collaboratif work ? :) 13:35:27 <MrsB> no, the pad for that 13:35:28 <ennael> ok keep all this for coming discussion :) 13:35:41 <ennael> can we switch to next topic ? 13:35:49 <coincoin> why not a bluray image with all the packages? :� 13:35:51 * coincoin runs 13:35:51 <DavidWHodgins> MrsB: I'm thinking straight ascii text file. You mount a partition containing it, edit it while running the install, then upload it. 13:36:16 <ennael> ok :) 13:36:16 <MrsB> we'll hold a meeting :D 13:36:18 <coincoin> #action QA have to brainstorm on ISO numbers to make a proposal 13:36:29 <ennael> #topic new isos for Mageia 2 13:36:49 <ennael> ok as I know you have nearly nothing to do we will have new isos to test in coming days 13:36:54 <ennael> :) 13:37:03 <MrsB> lol 13:37:28 <ennael> so have you all followed what happened about design ? 13:37:32 <MrsB> This is to do with the artwork thing? 13:37:38 <ennael> yes 13:37:56 <djennings> no plz explain 13:38:01 <ennael> ok 13:38:03 <DavidWHodgins> I haven't followed artwork. 13:38:10 <ennael> was on -discuss 13:38:11 <coincoin> #info http://blog.mageia.org/en/2012/05/31/background-credits/ 13:38:13 <[mbot> [ We are replacing Mageia 2 background image | Mageia Blog (English) ] 13:38:38 <ennael> the backrgound we have is in fact an existing one modified without authorization 13:38:48 <ennael> and license did not allow to use it 13:39:08 <DavidWHodgins> Ouch! 13:39:35 <ennael> rda contacted the author (the original one) and after discussion he is ok to let us use his work 13:39:46 <ennael> so rather good conclusion 13:39:58 <MrsB> It could have worked out quite badly, we're lucky he has been willing to do that 13:40:00 <ennael> we posted on blog about this http://blog.mageia.org/en/2012/05/31/background-credits/ 13:40:02 <[mbot> [ We are replacing Mageia 2 background image | Mageia Blog (English) ] 13:40:15 <ennael> but still we have a modified version of his work 13:40:32 <ennael> so we are updating all packages including piece of this design 13:40:44 <ennael> and we will rebuild isos with proper images 13:40:53 <MrsB> Are we going to use his original now? 13:40:57 <ennael> that's the minimum we could do in such case 13:41:00 <ennael> yep 13:41:02 <MrsB> ok 13:41:05 <ennael> work is in progress 13:41:09 <ennael> nearly done 13:41:22 <ennael> so first we need to push as a priority these packages 13:41:38 <ennael> avoid pushing all other updates until it's done 13:41:43 <MrsB> ok 13:41:49 <ennael> then we will rebuild isos 13:41:55 <ennael> all is ready on build server 13:42:07 <MrsB> when do you expect the updates to be ready? 13:42:26 <ennael> I have already some done but it should be all ready in 1/2h 13:42:56 <ennael> I would like to ask an exception for updates process so that I do not have to submit a bug/package 13:43:01 <ennael> as time is quite short 13:43:04 <ennael> if you are ok 13:43:23 <MrsB> as long as we know which packages to check 13:43:32 <ennael> yep will mail the list on qa-discuss 13:43:37 <MrsB> ok 13:43:40 <DavidWHodgins> ok 13:44:05 <ennael> then when all are offially uploaded we can start build 13:44:12 <MrsB> If they are ready quickly I can do it before we leave 13:44:18 <ennael> so very little difference 13:44:31 <ennael> that's also why I ask not to push other updates 13:44:53 <ennael> questions ? 13:45:01 <DavidWHodgins> None here. 13:45:07 <MrsB> none from me 13:45:14 <MrsB> everyone else ok with this? 13:45:37 <DavidWHodgins> Oh. Same iso file names on bcd? 13:45:53 <ennael> I'm wondering on that point... 13:47:09 <ennael> speaking here 13:47:14 <ennael> so we will keep same name 13:47:25 <ennael> and add a README file on mirrors 13:48:04 <MrsB> When are you hoping to begin testing the iso's? 13:48:38 <ennael> well if packages can be validated in coming 2h we can have new isos before 21h 13:48:51 <ennael> 19hutc 13:48:53 <ennael> sorry 13:49:04 <ennael> maybe before 13:49:08 <djennings> Will having the same name affect torrent trackers? 13:49:47 <ennael> they will have to be rebuilt 13:49:52 <ennael> as it uses isos content 13:51:19 <MrsB> I won't be available for these, won't be back until Monday afternoon 13:51:39 <ennael> ok other people can help :) 13:51:55 <ennael> ok I guess it's all for me, I let you for the end of this meeting 13:51:57 <DavidWHodgins> As usual, for now I can only test i586. 13:52:00 <ennael> and back to packages 13:52:16 <ennael> thanks for your time 13:52:24 <MrsB> thankyou :) 13:53:37 <MrsB> Is there anything else to discuss? 13:54:28 <harms__> Would it make sense to organise a kind of workshop 13:54:59 <Stormi> MrsB: the topics I sent to qa-discuss if we want 13:55:01 <harms__> (a time-slot on IRC) dedicated to QA nebies 13:55:51 <MrsB> harms__: thats a good idea. I was helping zvonimir yesterday, he completed his first validation. 13:56:43 <harms__> I saw - and learned. I see 2 issues: (a) better undestand 13:56:59 <harms__> how to work in QA 13:57:08 <MrsB> we can maybe arrange another meeting next week and try to get as many of the new members to come and ask them what they need. 13:57:18 <harms__> and (b) talk about how to work 13:57:29 <MrsB> You're absolutely right 13:57:43 <MrsB> We need to remove as many abrrier as we can 13:57:47 <MrsB> barriers* 13:58:42 <MrsB> Can we do the ISO testign this weekend, and hold the leadership election and then arrange a meeting again next week? 13:59:12 <harms__> great. (1st how to work should read: what you let yourself in for) 13:59:23 <MrsB> :D 13:59:39 <Stormi> well ennael said for coming monday, but if she can wait one week I think it's better 14:00:32 <harms__> Maybe a formal meeting for newbies is not necessary - just advertise 14:00:37 <harms__> and set the time 14:00:37 <MrsB> monday 4th or the following one? 14:01:31 <MrsB> We can that harms__ sure 14:01:49 <Stormi> MrsB: I don't know, 4th I guess 14:02:03 <harms__> fine for me 14:02:21 <Stormi> but my opinion is that we are not in a hurry, a one week difference will not kill QA 14:02:23 <harms__> maybe an occasion to hook some more 14:02:28 <MrsB> harms__: After the weekend I'll write to qa-discuss. I'm really short on time today :\ 14:02:45 <MrsB> Stormi: you're right of course 14:02:59 <MrsB> do you want to go through your topics? 14:03:25 <coincoin> can we talk about backports? 14:03:33 <coincoin> #topic Mageia backports 14:03:59 <coincoin> so as you know we would like to open backports for 1 and 2 14:04:22 <Stormi> (or maybe just Mageia 2) 14:04:37 <coincoin> the idea was already discussed in QA meeting and for now, packagers/dev need to know if QA ppl is ready to validate backports 14:04:39 <DavidWHodgins> I'd like to see backports still go through same process, but only testing basic functuality. 14:04:58 <Stormi> I agree 14:05:18 <coincoin> as Stormi proposed in the past, QA can't test everything and perhaps we could explain our POV and say "we only test X kind of packages" 14:05:21 <Stormi> a everytime someone asked for a backport, turn them into testers 14:05:21 <coincoin> wdyt? 14:05:42 <DavidWHodgins> Agreed. 14:05:43 <coincoin> QA need to test all packages for you? 14:06:01 <Stormi> that's the backport policy 14:06:07 <DavidWHodgins> At lease ensure they install cleanly and run. 14:06:08 <MrsB> The way I see it we have already had backports with mdv packages being added to mga1. I don't see any reason really not to. It would be good if we say the requester should help with testing . 14:06:09 <Stormi> no untested backport 14:06:34 <MrsB> they would be owest possible priority, but they already are 14:06:38 <MrsB> lowest* 14:06:40 <Stormi> yes 14:06:58 <coincoin> so, QA will test ALL backports but packager will have to help? 14:07:13 <coincoin> packager and/or requester 14:07:19 <MrsB> We can strongly urge them to if they want their backport quickly 14:07:52 <Stormi> the way I would put it is: we validate backports. We warn that we can't validate a whole lot at once, so either the packager finds testers, or the requester 14:08:03 <coincoin> #info QA team agrees on testing ALL backports if requester/packager helps 14:08:10 * JohnR has arrived, bloody timezones! 14:08:15 <DavidWHodgins> Not much difference then firefox testing. 14:08:16 <JohnR> Sorry I'm late 14:08:18 <MrsB> morning JohnR 14:08:23 <DavidWHodgins> HiYa. 14:08:25 <coincoin> hello JohnR 14:08:35 <Stormi> and everytime someone tests a package I'd like to propose him/her to subscribe to madb to get notifications when new updates or backports for this package are submitted 14:08:49 <coincoin> DavidWHodgins: not much difference but backport will give a lot of new packages to test 14:08:53 <DavidWHodgins> Good idea. 14:08:57 <Stormi> with, if I manage it, a link to the bug report 14:09:22 <DavidWHodgins> Any timeframe for bugizlla 4? 14:09:39 <Stormi> which means I must work harder on madb and still give less time in QA with the risk of having ennael see me as a bad deputy leader :/ 14:10:00 <Stormi> but maybe in one week I won't be anymore 14:10:41 <Stormi> so ok for backports 14:10:56 <ennael> Stormi: hey I did not say antyhing like this :) hopefully everyone here has private life 14:11:05 <coincoin> Stormi: you can take time to madb, no soucy 14:11:16 <coincoin> Stormi: and you have time now than 2 is out 14:11:19 <Stormi> s/bad/not efficient enough given time constraints/ :) 14:11:24 <ennael> :) 14:11:39 <coincoin> we have all to reorganize things now that rush is quite over 14:11:52 <coincoin> to be ready for next storm :) 14:12:04 <coincoin> storm != Stormi 14:12:09 <coincoin> :� 14:12:13 <Stormi> speaking of which, next topic : parallel updates? 14:12:18 <MrsB> yes 14:12:37 <coincoin> so for backport? Ok for what we said? 14:12:43 <Stormi> yes 14:12:46 <DavidWHodgins> ok here. 14:12:46 <MrsB> yes 14:12:53 <coincoin> #action QA will inform -dev on next packager meeting 14:13:01 <coincoin> thank, Stormi, go ahead :) 14:13:19 <ennael> (also woule be nice to have one of you in meetings to help working together) 14:13:33 * ennael shuts her mouth now 14:13:44 <MrsB> in packager meeting? 14:13:49 <DavidWHodgins> I always forget to look at the clock, and meetings are over by time I join. 14:14:06 <coincoin> I'm almost always there but not always talking 14:14:22 <Stormi> I'm usually in 2 packager meeting out of 3, but not always talking like coincoin 14:14:37 <MrsB> what night is packagers, is it tuesday? 14:14:42 <Stormi> wednesday 14:14:52 <Stormi> and council monday 14:15:06 <MrsB> I can try and be there 14:15:24 <Stormi> ok, so 14:15:31 <MrsB> do the topic thing 14:15:33 <Stormi> #topic parallel updates to mga 1 and 2 14:15:48 <Stormi> I'll speak first because I must go fetch the kids 14:16:15 <Stormi> we need one bug report per release for update candidates 14:16:30 <MrsB> i strongly agree 14:16:31 <Stormi> whereas packagers usually need only one bug report and cover all releases at once 14:16:38 <Stormi> so we need to find how to fill the gap 14:16:59 <Stormi> I see 2 solutions 14:17:03 <DavidWHodgins> I'm ok with one, as long as they understand both will be held till both have been tested. 14:17:26 <Stormi> 1) they create 2 bug reports 14:18:13 <Stormi> when they started working on one bug report only (the "original" bug report when there's a reporter), they must create a second one and set release accordingly 14:18:37 <Stormi> 2) they create only one bug report and either triage team or we create the second bug report and put everybody in cc 14:18:50 <Stormi> mageia 1 blocks mageia 2 14:19:10 <Stormi> hmm 14:19:10 <MrsB> I don't see any reason we should have to act as secretaries for packagers :\ 14:19:11 <Stormi> no 14:19:16 <Stormi> mageia 2 blocks mageia 1 14:19:36 <Stormi> well, either they fit into our processes or we fit into theirs 14:19:47 <Stormi> being part of both I can see both point of views 14:20:04 <MrsB> What is the benefit to a packager of creating one bug report? 14:20:21 <DavidWHodgins> Less email, all comments in one place. 14:20:28 <Stormi> they go back quickly to the next package 14:20:30 <MrsB> more confusion though too 14:20:41 <MrsB> I think stormi hit the nail on the head 14:20:56 <MrsB> It save a packager a few seconds 14:20:57 <DavidWHodgins> Which can also happen with multiple reports. Easy to put the wrong comment in the wrong report. 14:21:15 <Stormi> MrsB: the same as it saves us if we must create the second report 14:21:23 <Stormi> or triage 14:21:31 <Stormi> or an automated something :) 14:21:46 <Stormi> ok I must go, see you in a few minutes 14:21:47 <MrsB> an automated something would be nice but I don't think it will happen 14:21:49 <MrsB> ok 14:22:16 <MrsB> One report is confusing enough at times when there are multiple packages and srpms's being tested 14:22:24 <MrsB> on two arch's 14:22:33 <Stormi> and we must think of what we will do if we have 3 releases to maintain 14:23:51 <MrsB> It's like writing notes, if you have two things to write notes about they are better on a new piece of paper 14:24:31 <MrsB> 1 report is ok until there is a problem with something, then it would fall apart 14:24:40 <MrsB> imho of ocurse 14:25:15 <MrsB> dave you remember the php one which ended up in confusion 14:25:53 <DavidWHodgins> Yes. That was mainly due to the delays causing new versions to show up while testing was already in progress. 14:26:15 <DavidWHodgins> And waiting for packages that needed to be rebuilt holding up testing. 14:26:19 <MrsB> can you imagine trying to do that across 2 or 3 releases on one bug 14:27:02 <MrsB> it could be 3 if we release an LTS 14:27:13 <DavidWHodgins> The main thing I learned from that one, is that we need better lists of which packages need to be rebuilt for what, and hold testing till they are all available. 14:28:04 <MrsB> I used that as an example though. It would be impossible to keep track and would lead to mistakes 14:28:36 <MrsB> also sysadmin currently close the report once they have done the pushing 14:28:39 <DavidWHodgins> True. But how many times have we seen "Oops, wrong bug" 14:28:56 <JohnR> Am I correct in understanding that some. if not all, of these problems have workarounds in upcoming bugzilla update? 14:29:09 <MrsB> It's better to have an Oops wrong bug though than an Oops wrong push 14:29:51 <MrsB> not really JohnR. It's more to do with clarity on the bug report 14:30:02 <JohnR> MrsB: ok 14:30:03 <MrsB> K.I.S.S. 14:31:00 <DavidWHodgins> I don't think multiple reports will always be simpler. Maybe only for things that need lots of packages rebuilt? 14:31:11 <harms__> Are the 1-bug 2-bug approaches exclusive - would it be possible 14:31:12 <[mbot> Bug https://bugs.mageia.org/show_bug.cgi?id=2 enhancement, Normal, ---, dmorganec, RESOLVED FIXED, test xmlrpc to see if it works to create a bug 14:31:20 <MrsB> I think we would soon run into trouble trying to use one report. If not those of us who have been doing it for a while then new people becoming involved. 14:31:35 <harms__> to start with one report and branch if the need comes? 14:32:09 <DavidWHodgins> harms__: I'd be ok with that. 14:32:35 <JohnR> harms_: And the parent is blocked by the child ? That could work ? 14:32:51 <MrsB> How would we decide if the need had arisen and what would we end up with? 14:33:18 <harms__> decision of the guy how does the work ? 14:33:19 <JohnR> That's what I'm asking as well? 14:33:36 <DavidWHodgins> JohnR: 2 should always block 1, as it would affect upgrading. 14:34:10 <JohnR> yes, that makes sense,however we've still to persuade packager too? 14:34:40 <MrsB> Isn't a .mga2.rpm always seen as newer than a .mga1.rpm? 14:34:59 <DavidWHodgins> Right now, seems like most packagers want one report. Let's give it a try, and if problems develope, review later. 14:35:06 <JohnR> MrsB: that's my understanding 14:35:29 <leuhmanu> MrsB: only if the part before the mga is the same 14:36:08 <JohnR> ahh 14:36:35 <Stormi> back 14:36:41 <MrsB> I feel strongly we will run into trouble this way 14:36:51 <MrsB> wb 14:38:00 <MrsB> Stormi it's been suggested we try one BR and branch it if necessary and review the system later 14:38:19 <leuhmanu> rpmvercmp.rb drakx-installer-stage2-14.24-1.mga3 drakx-installer-stage2-14.25-1.mga2 14:38:22 <leuhmanu> drakx-installer-stage2-14.25-1.mga2 14:38:22 <Stormi> why not, packagers will be happy 14:38:51 <MrsB> if that is the consensus, then we'll go with it 14:38:52 <Stormi> but then maybe with one condition 14:39:03 <Stormi> we push mga1 and mga2 at the same time if there's only one bug 14:39:14 <Stormi> if the packager wants a faster process for mga2, 2 bugs 14:39:24 <Stormi> mga1 being always dependent on mga2 14:39:32 <MrsB> that seems sensible 14:39:35 <DavidWHodgins> Agreed. Once bug report get's validated, qa is done with it. 14:39:44 <coincoin> yep 14:39:55 <MrsB> so, at what point do we apply the validated_update keyword? 14:40:09 <Stormi> when all 4 parts have been tested 14:40:13 <MrsB> or do we need another keyword 14:40:16 <DavidWHodgins> When testing is done on both arches and both versions. 14:40:36 <MrsB> shall I add an action then? 14:40:44 <Stormi> and maybe we need a naming convention or a keyword to identify what releases the bugs target 14:41:03 <Stormi> until bugzilla allows to select sevearl 14:41:06 <MrsB> so it's obvious from the title you mean? 14:41:19 <Stormi> yes, if it's obvious from the title, it's obvious in the mails 14:41:27 <MrsB> dave? 14:41:37 <leuhmanu> feel free to add what you want in the whiteborad also 14:41:48 <DavidWHodgins> Maybe automate having the release added to the subject? 14:42:17 <MrsB> how would that happen? 14:42:36 <Stormi> DavidWHodgins: it can't work with 2 releases in the bug, can it? 14:43:06 <DavidWHodgins> I'm thinking about bug reports that only affect one release. 14:43:08 <Stormi> whatever the solution we must be able to have a "Mageia 1 update candidates" report 14:43:19 <Stormi> and mageia 2, etc. 14:43:35 <Stormi> via keyword, title or whiteboard 14:43:40 <MrsB> statistics you mean Stormi? 14:43:48 <DavidWHodgins> Not all bug reports will affect both releases. 14:44:07 <Stormi> yes, that's why we need to know for a specific bug report what releases it affects 14:44:13 <Stormi> so that we can count them 14:44:14 <MrsB> not all but most so far :D 14:44:36 <DavidWHodgins> So far, most updates have been security updates. 14:44:36 <Stormi> we need stats such as number of updates to mga1 since it was released 14:45:11 <MrsB> It becomes difficult then 14:45:35 <MrsB> what's a reliable way to do that, maybe leuhmanu can suggest something 14:45:42 <leuhmanu> Stormi: srpm in the repo no ? 14:45:57 <leuhmanu> since we keep all updates 14:46:07 <Stormi> leuhmanu: until we decide to wipe them 14:46:18 <leuhmanu> for now it was 'keep them' 14:46:19 <Stormi> updates advisories otherwise 14:46:27 <DavidWHodgins> Count of messages in updates-announce 14:46:44 <Stormi> but still at a given time it can be interesting to know the number of open update candidates affecting a given version 14:46:46 <leuhmanu> or with strict search on the bugzilla 14:47:23 <MrsB> It strikes me the implications of using one bug report are much more significant for QA than they are for packagers 14:47:38 <Stormi> if packagers put a keyword per mageia release, or format the title to contain [mga1], [mga2], etc., then it works 14:48:20 <MrsB> what about when we branch a bug report 14:48:26 <MrsB> it will break that system 14:48:32 <coincoin> carefull not to ask for something to "hard" to use for dev/packager or they won't obey... 14:48:53 <MrsB> perhaps we won't either :P 14:49:20 <Stormi> otherwise we wait for bugzila 4 14:49:36 <DavidWHodgins> QA's job is making sure the rules are followed. :-) 14:49:57 <MrsB> You remember the battles we had with advisories tho 14:50:18 <MrsB> how far off is bugzilla 4? 14:50:23 <DavidWHodgins> Oh yes. Often we wrote them. 14:50:29 <Stormi> MrsB: it depends on the sysadmins 14:50:36 <leuhmanu> yes coincoin you know nothing about adbisory and rpmdrake ? 14:51:20 <MrsB> for statistical purposes it would be better to wait for bugzilla 4 to use 1 BR 14:51:36 <MrsB> (and headache purposes) 14:52:07 <MrsB> Can we summarise and see where we are then.. 14:52:19 <MrsB> I'll try to 14:52:52 <MrsB> We're not against trialing one BR per update, on the condition that mga1 and mga2 are pushed at the same time 14:53:21 <MrsB> We can't see how we can do so reliably with the current bugzilla and retain our statistics 14:53:32 <coincoin> dmorgan: ping? do you have ETA for bugzilla 4? 14:54:45 <MrsB> If necessary one BR would be branched for clarity into one for each release, and one would block the other 14:54:45 <MrsB> anything I missed? 14:54:58 <DavidWHodgins> I think that covers it. 14:55:32 <MrsB> The implications of using one BR are more significant for QA than it would be to a packager 14:58:31 <leuhmanu> hum 14:58:46 <MrsB> lol 14:59:21 <leuhmanu> hope what will work 14:59:33 <MrsB> ummm is there a way to see what the bot got? 14:59:50 <MrsB> I'll just repeat them 15:00:09 <MrsB> #info meetbot disappeared so repeating the infos 15:00:12 <DavidWHodgins> Missed the part about splitting if needed. 15:00:15 <MrsB> #info QA is not against trialling one bug report per update, on the condition that mga1 and mga2 are pushed at the same time 15:01:04 <MrsB> #info If necessary one bug report would be branched for clarity into one for each release, and one would block the other 15:01:04 <MrsB> #info We can't see how we can do so reliably with the current bugzilla and retain our statistics 15:01:17 <MrsB> #info It is clear that the implications of using one bug report are more significant for QA than the benefit would be to a packager 15:01:23 <MrsB> ok? 15:01:43 <DavidWHodgins> Ok here. 15:01:54 <JohnR> ok here 15:01:54 <leuhmanu> ( [mbot also have log if needed ) 15:01:54 <MrsB> is there anything else to add on this? 15:02:15 <MrsB> stormi? 15:02:17 <DavidWHodgins> I think that's it. 15:03:28 <Stormi> ok for this topic 15:03:29 <MrsB> I guess we need to email dev ML about this 15:03:44 <Stormi> [16:58] <Stormi> next steps would be sending our position to mageia-dev (with detailed process) + having packagers accept it during next packager meeting, or ask to amend it if they have good arguments 15:03:46 <Stormi> :) 15:05:02 <MrsB> Did we agree to use one BR or wait until bugzilla 4? 15:05:02 <DavidWHodgins> One BR, split if needed for clarity. 15:05:12 <MrsB> #info We will trial with existing bugzilla and review later 15:05:51 * MrsB lost that one :( 15:05:51 <DavidWHodgins> MrsB: Lol 15:05:51 <MrsB> Are there any other topics? 15:05:51 <Stormi> there could be but maybe it's enough for today 15:06:13 <DavidWHodgins> Agreed. 15:06:19 <MrsB> shall we end for today then? Anybody else anything to add? 15:06:22 <coincoin> Agreed too 15:07:47 <DavidWHodgins> Watch the qa-discuss for the iso availability? 15:07:48 <JohnR> ok here 15:07:48 <Stormi> packages are available for tests 15:07:48 <coincoin> so, can we close the meeting or any other remarks? 15:07:48 <MrsB> #action Everyone please watch qa-discuss for info on new ISO's which will need testing later today 15:07:50 <MrsB> #endmeeting