From Wiki [en] OpenMandriva
< QA
Revision as of 20:52, 27 June 2013 by Rxu (Talk | contribs) (fix time and place)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

QA meeting

Time & Place

Place: #openmandriva-qa @ Date/Time: Tuesday 2013-06-27, 17:00 UTC

Time zone Local time UTC offset
CEST Thursday 2013-06-27 19:00 UTC+2
EDT Thursday 2013-06-27 13:00 UTC-4


1. Release Procedures (incl. Pre-Release Testing & Approval), QA Testing Standards
2. Issues with the past alpha ISO
3. Cooker Standards & Enforcement
4. Bugzilla Management (incl. Bug Assignment)
5. Last Words




Jun 27 13:07:13 <colin___>	Fire away
Jun 27 13:07:24 <Xu_R>	colin___: Yeah. We'll have to work that out.
Jun 27 13:07:56 <Xu_R>	I'll be modifying the Etherpad with our decisions and discussions, so that'll serve as our official summary.
Jun 27 13:08:13 <Xu_R>	Let's start with Release Procedures. How should we go about releasing an ISO?
Jun 27 13:08:23 <Xu_R>	What procedures will Cooker need to go through with regards to QA?
Jun 27 13:08:59 <ben79_>	Seems like some testing should be done with ISO's before public release.
Jun 27 13:09:30 <colin___>	I have produced a doc that I think you have all seen is that too much to do? 
Jun 27 13:09:34 <ben79_>	Even if it's just 4-6 people a lot could be corrected before release, as we currently see.
Jun 27 13:09:57 <christanner>	I think that Colin's doc is fine for initial testing
Jun 27 13:10:09 <Xu_R>	I think that the doc is fine as well
Jun 27 13:10:21 *	Pulfer ( has joined #openmandriva-qa
Jun 27 13:10:54 <Xu_R>	We can follow that for this release - althoguht he installation uses the traditional installer, right?
Jun 27 13:11:22 <Xu_R>	Shouldn't be much different for a live CD.
Jun 27 13:11:26 <colin___>	How do persuade cookers not to release before we have tested sending out uninstallable iso's relly is a no no
Jun 27 13:11:28 <ben79_>	Agree on Colin's doc.
Jun 27 13:12:07 <Xu_R>	Yeah, I did not like this last alpha. Even though something got sent out, it was very much not installable without manual effort.
Jun 27 13:12:42 <colin___>	Good point about installer
Jun 27 13:13:09 <Xu_R>	That can be easily remedied, I imagine.
Jun 27 13:13:27 <colin___>	It's so important that people have a favourable first impression
Jun 27 13:13:35 <christanner>	Agreed
Jun 27 13:14:15 <ben79_>	Perhaps OpenMandriva council should do releases after QA has approved?
Jun 27 13:14:34 <ben79_>	Yes 1st impression is important.
Jun 27 13:14:52 <ben79_>	We've had plenty of negative publicity.
Jun 27 13:14:57 <colin___>	I shall revise as best I can for live installer should we test both?
Jun 27 13:15:06 <Xu_R>	IMHO I don't like the Council interfering with distribution releases. I think the association should stay separate from the distribution.
Jun 27 13:15:32 <Xu_R>	colin___: Yeah, let's have both, in case we bring the old one back.
Jun 27 13:16:26 <christanner>	Somebody has to take ultimate responsibility for releases. I  believe that Council has to approve the final release at least.
Jun 27 13:17:27 <Xu_R>	I dislike that notion, namely because it may bring politics into the release.
Jun 27 13:17:47 <christanner>	Robert, I see your point
Jun 27 13:18:12 <ben79_>	Then there will need to be some agreed on 'official' release program. IF not council then whom or what group? Us?
Jun 27 13:18:22 <ben79_>	Or TC?
Jun 27 13:18:52 <colin___>	Chris is right but that's a really difficult thing given the current structure. Ultimately in the real world it should be QA who has the final say and perhaps the Council should rubber stamp.
Jun 27 13:18:56 <Xu_R>	I would think us, honestly.
Jun 27 13:19:15 <colin___>	I can't though how we can get agreement on this
Jun 27 13:19:22 <colin___>	see though
Jun 27 13:19:56 <Xu_R>	mm.. it's going to be a bit complicated to get parties to agree.
Jun 27 13:20:40 <ben79_>	Well in a lot of organizations QA has final work before product ships. Speaking from experience in printing industry as well as other Linux distros.
Jun 27 13:20:53 <colin___>	This is why I think standards are the only way forward. We've seen on cooker what happens when there are no rules 
Jun 27 13:21:05 <ben79_>	work not work, duh, need coffee
Jun 27 13:21:24 <ben79_>	word not work, really need coffee
Jun 27 13:21:43 <Xu_R>	So who do we agree should get the final word on releases?
Jun 27 13:21:55 <ben79_>	QA-team
Jun 27 13:21:57 <Xu_R>	Or should we discuss this another day?
Jun 27 13:22:15 <colin___>	For me QA the decision must be impartial
Jun 27 13:22:36 <ben79_>	No we should propose something on this now.
Jun 27 13:22:37 <christanner>	I agree with QA having the final say.
Jun 27 13:22:40 *	arisel ( has joined #openmandriva-qa
Jun 27 13:22:51 <colin___>	Welcome arisel
Jun 27 13:22:51 <Xu_R>	I think QA as well
Jun 27 13:22:54 <Xu_R>	Oh, hi arisel!
Jun 27 13:23:09 <ben79_>	Hi arisel.
Jun 27 13:23:16 <christanner>	Hi arisel
Jun 27 13:23:17 <ben79_>	Hi Pulfer
Jun 27 13:23:29 <arisel>	sorry for beeing late. Troubles at work and omw back home.
Jun 27 13:23:34 <colin___>	You have arrived at a crucial moment
Jun 27 13:23:42 <Xu_R>	arisel: oh, hope everything is ok :/
Jun 27 13:24:01 <Xu_R>	arisel: We're currently discussiong release procedures, and debating who has the final word for a release (go/nogo)
Jun 27 13:24:14 <Xu_R>	s/discussiong/discussing/
Jun 27 13:24:34 <Pulfer>	ben79_: Hi :-)
Jun 27 13:24:58 <Xu_R>	Pulfer: you too, your opinion as well would be helpful
Jun 27 13:25:36 <arisel>	Think it should be unpossible without a go from tc. For qa this might aldo be the case, dont know.
Jun 27 13:25:53 <colin___>	Robert do Pulfer and Arisel have the etherpad?
Jun 27 13:26:01 <arisel>	S/un/im
Jun 27 13:26:11 <Xu_R>	Pulfer, arisel:
Jun 27 13:26:27 <Pulfer>	Xu_R: IMHO, QA should approve the release, then TC should approve it too. After the release is approved by both QA & TC, it can be considered ready
Jun 27 13:26:50 <christanner>	I agree with Pulfer.
Jun 27 13:27:04 <Xu_R>	I can agree with that - QA before TC
Jun 27 13:27:12 <ben79_>	Yes, agree
Jun 27 13:27:12 <Xu_R>	or vice versa
Jun 27 13:27:12 <arisel>	will be able to read in 7mon. Putty on symbian isnt the way to read it now :)
Jun 27 13:27:18 <Xu_R>	as long as we both can approve
Jun 27 13:27:23 <Pulfer>	Xu_R: In Rosa we also have release manager who has the final word after QA and TC
Jun 27 13:27:32 <Xu_R>	arisel: oof. symbian. :|
Jun 27 13:27:39 <colin___>	That sounds good to me I would welcome tc's involvement it would encourage dialogue between cooker and qa
Jun 27 13:28:04 <Xu_R>	Pulfer: I'd like a release manager as well, but we're stretched for people, so I think just QA and TC for now :)
Jun 27 13:28:28 <Pulfer>	Xu_R: Yep
Jun 27 13:28:30 <christanner>	Do we have a release manager for the current release?
Jun 27 13:28:55 <Xu_R>	christanner: no, sadly. I think QA and TC have to work together while we don't have a release manager.
Jun 27 13:28:58 <Pulfer>	christanner: proyvind or mdawkins were for some time
Jun 27 13:29:35 <Pulfer>	But I guess we don't really have real RM
Jun 27 13:29:42 <Xu_R>	I wonder if anyone could take over on it? bero, maybe?
Jun 27 13:30:20 <Pulfer>	RM should be one of lead developers, so bero is the best for that
Jun 27 13:30:47 <Pulfer>	I cannot be RM because I'm focused on Rosa more than on OpenMandriva
Jun 27 13:30:57 <Pulfer>	While being RM requires full focus
Jun 27 13:31:10 <colin___>	At the risk of being controversial could we ask one of the council. I think it would be a bad idea if we asked acooker dev to do it. We don't want the same things to happen again
Jun 27 13:31:43 <christanner>	I think that TC should appoint the RM.
Jun 27 13:31:50 <Pulfer>	Surely
Jun 27 13:32:15 <colin___>	Can we define the function of the release manager
Jun 27 13:32:55 <colin___>	Is he a coordinator?
Jun 27 13:32:59 <Pulfer>	Yes
Jun 27 13:33:23 <arisel>	colin___: asking council to provide a release manager might be a fail..
Jun 27 13:33:27 <Pulfer>	QA <-> devs <-> non-tech members
Jun 27 13:33:44 <Xu_R>	Release Manager should definitely coordinate all aspects of the release
Jun 27 13:34:15 <colin___>	Then he doesn't have to be a dev he can be someone who is charged implementing a pre-agreed plan.
Jun 27 13:34:45 <Pulfer>	colin___: IMHO, RM should know system internals really well
Jun 27 13:34:56 <christanner>	I agree with Colin, but it would help if he knows something about the system.
Jun 27 13:35:06 <arisel>	colin___: but without enough knowledge when sth is fixed on a technical basis it won't be enough to just follow a plan.
Jun 27 13:35:16 <colin___>	What this means in practice is that the plan is agreed by devs and qa and is implemented impartially by a third party
Jun 27 13:35:34 <Xu_R>	colin___: I'm fine with him not being a dev, but he has to know the process well
Jun 27 13:36:03 <arisel>	btw... where's bero? out of connectivity?
Jun 27 13:36:23 <Xu_R>	arisel: I think so. He was going to FiSL...
Jun 27 13:36:33 <christanner>	The RM's main job is to make sure that things get done, and thus he needs to know who is doing what.
Jun 27 13:36:34 <colin___>	Ok Xu_R is the process documented 
Jun 27 13:37:21 <Xu_R>	colin___: no, it's not. that's something that does need to be documented...
Jun 27 13:38:15 <Xu_R>	and given these past few unstructured alphas, it might be good to get documentation on it
Jun 27 13:38:29 <colin___>	Ok question who among the attendees has the experience to produce an outline doc. Bullet points only
Jun 27 13:38:30 <arisel>	Hmm.. think you are to close to an ideal world-approach.
Jun 27 13:39:04 <Xu_R>	arisel: close?
Jun 27 13:39:31 <colin___>	We want to be the best distro out there so the ideal world is what we must strive for!!
Jun 27 13:39:53 <Pulfer>	Yep :-)
Jun 27 13:40:39 <Xu_R>	Haha, yeah, but let's account for anything that might come up
Jun 27 13:40:41 *	arisel expects that the release manager will have to be able to fix at least some things on short notice himself. In a perfect world he would not have to do that. But as we're not overflown with devs someone has to be able to decide what is important and what not. For that some technical knowledge is crucial. If we follow a perfect world scheme we will not release.
Jun 27 13:41:14 <Pulfer>	Indeed
Jun 27 13:41:18 <Xu_R>	+1
Jun 27 13:41:22 <colin___>	Agreed we can only work towards it 
Jun 27 13:41:27 <christanner>	Yes
Jun 27 13:41:37 <arisel>	ok :)
Jun 27 13:42:10 <Xu_R>	So - who will decide the Release Manager?
Jun 27 13:42:21 <colin___>	Pulfer, Arisel have you seen the release plan I published?
Jun 27 13:42:38 <Pulfer>	colin___: I guess I missed it
Jun 27 13:42:49 <christanner>	TC should decide the RM.
Jun 27 13:43:04 <ben79_>	TC
Jun 27 13:43:08 <colin___>	Robert you have the link to hand could you post
Jun 27 13:43:13 <Xu_R>	It's an ISO testing process -
Jun 27 13:43:22 <arisel>	maybe we should start with a "do's and don'ts"-list like "we have to fix artwork", "we have to fix pulseaudio-configuration under kde", "we've to fix Bug X", "we will not fix Bug Y, cause it's minor", "we will not never rebuild anything else..", ...
Jun 27 13:43:23 <Xu_R>	so TC should decide the RM?
Jun 27 13:43:43 <Xu_R>	Yeah, priorities.
Jun 27 13:43:51 <colin___>	But it also prioritises what it is important to have functional
Jun 27 13:43:58 <arisel>	"
Jun 27 13:44:07 <arisel>	remove that line ;)
Jun 27 13:44:14 <arisel>	()wrong paste)
Jun 27 13:44:27 <arisel>	colin___: true.
Jun 27 13:45:00 <Xu_R>	Ok, so we can close the issue of Release Manager and leave that to TC then.
Jun 27 13:45:19 <christanner>	good luck to them.
Jun 27 13:45:48 <Xu_R>	Besides the testing process that colin___ has provided, are there any other aspects that we should prioritise testing right now?
Jun 27 13:45:51 <arisel>	colin___: think the release plan is nice. There will be some things which will be unfulfilled (nobody is able to translate the license, and it's just sth i made up from the old one), but we can try to get close.
Jun 27 13:46:08 <arisel>	s/release plan/testing iso installs
Jun 27 13:46:12 <Xu_R>	arisel, you mentioned artwork, pulseaudio?
Jun 27 13:46:33 <Xu_R>	Also branding, etc...
Jun 27 13:46:38 <Xu_R>	e.g. things we should look for
Jun 27 13:47:36 <arisel>	Xu_R: they just served me as examples. But I'm sure we still have a pulseaudio-Bug for users using a graphics card with hdmi audio beeing unable to configure pulseaudio by the means of the kde tools to use another audio output on another card (eg, normal soundcard).
Jun 27 13:48:34 <arisel>	Xu_R: concerning artwork/branding: rugyada works great on this, but providing her with a list of everything you miss is always a great idea.
Jun 27 13:49:03 <colin___>	The release plan is there as a public document for all to edit if any one wants to add something then please do
Jun 27 13:49:45 <Xu_R>	arisel: ok. cooker should also let us know of anything that should prioritize our testing
Jun 27 13:50:26 <colin___>	+1 to this full cooperation between QA and cooker is what we need
Jun 27 13:50:41 <christanner>	+1
Jun 27 13:51:45 <Xu_R>	Ok. I think I documented all this on the Etherpad
Jun 27 13:51:54 <Xu_R>	please check, add whatever I've missed
Jun 27 13:52:03 <Xu_R>	and we'll move on then
Jun 27 13:52:47 <colin___>	Looks good to me
Jun 27 13:53:09 <Xu_R>	[2] Issues with the past alpha ISO
Jun 27 13:53:10 <Pulfer>	I guess I have to go now, 5 AM is too late even for me
Jun 27 13:53:30 <arisel>	Pulfer: good night and thank you for beeing here!
Jun 27 13:53:37 <Xu_R>	Pulfer: oof, go sleep then :) night! thanks!
Jun 27 13:53:38 <colin___>	You need sleep thanks for coming Pulfer 
Jun 27 13:53:40 <Pulfer>	If there will be voting, let arisel have my voice there :-)
Jun 27 13:53:41 <christanner>	Good night
Jun 27 13:53:46 <Pulfer>	Thanx, folks :-)
Jun 27 13:53:49 *	Pulfer has quit (Quit: KVIrc 4.2.0 Equilibrium
Jun 27 13:54:06 <Xu_R>	Ok, so [2] Issues with the past alpha ISO
Jun 27 13:54:25 <Xu_R>	We can tie this in also with the bugs we've received in Bugzilla as well
Jun 27 13:54:30 <Xu_R>	Any comments here?
Jun 27 13:54:49 <colin___>	Interesting I was under the impression that vbox was the first port of call for testing
Jun 27 13:54:50 <arisel>	just provided one for vbox..
Jun 27 13:55:44 <arisel>	i don't know.. you should say that :) I'm using qemu locally due to some other issues, but I haven't been the one who tested the latest isos before uploading
Jun 27 13:56:42 <Xu_R>	Hmm. :/
Jun 27 13:57:04 <Xu_R>	There was a call about what hardware we each had earlier, and a number of us have real hardware to test it on :)
Jun 27 13:57:46 <Xu_R>	if we have an issue in vbox, maybe ask others to test on real hardware before reporting as bug?
Jun 27 13:57:48 <colin___>	There is an issue of hardware here from a qa standpoint virtual box is very convenient as you can do as I do and have bothe 32 bit and 64bit distros running sumulataenously on the same machine.
Jun 27 13:57:48 <christanner>	but apparently there is a problem with NVIDIA cards which leaves me out for the time being
Jun 27 13:58:06 <arisel>	no, i think testing with vbox is totally fine. I'm just sometimes having troubles to reproduce bugs.
Jun 27 13:58:52 <colin___>	chris but you can still use VBox
Jun 27 13:59:14 <christanner>	Yes, I can still use VBOX and do.
Jun 27 13:59:25 <arisel>	so my question to that more is like: how about focussing on issues first who happen to also exist on real hardware? Or should we focus on vbox-troubles instead, since you can't test if we don't do it that way round?
Jun 27 14:00:04 <arisel>	btw: there's a mini qemu-guide on the wiki on how to build your own iso and run it in qemu ;)
Jun 27 14:00:14 <Xu_R>	arisel: I think let's try real hardwawre first
Jun 27 14:00:37 <Xu_R>	I'll try to use qemu to test the latest releases as well
Jun 27 14:00:55 <colin___>	I would see the release process having two stages here we set up everything so it definately works in a popular emulator. This means the casual tester can try out the distro and get a result
Jun 27 14:00:58 <arisel>	Xu_R: i totally could live with the alternative, I'm just asking, so please do decide without any ideas of doing "us devs" a favor :)
Jun 27 14:02:19 <colin___>	The second stage before release is that we test on all the hardware available to QA
Jun 27 14:02:42 <christanner>	Colin: Sounds good.
Jun 27 14:02:43 <ben79_>	Think I'll give qemu a try. Till now I've only tested on real hardware.
Jun 27 14:02:46 <arisel>	colin___: do you have sth like a "testing guide" like "how to set up your test environment"?
Jun 27 14:03:02 <arisel>	colin___: if you could provide that it would be easier for the devs to reproduce the error.
Jun 27 14:03:18 <Xu_R>	arisel: I think it's better if we don't, because there are many environments for our users...
Jun 27 14:03:21 <arisel>	s/error/bugs
Jun 27 14:03:29 <colin___>	I don't but I could certainly produce one that is a very good idea
Jun 27 14:04:28 <arisel>	Xu_R: i think you are right, bt if we do a two-stage approach I'm fine with it. So nobody will keep us from continue to test on real HW as well as inside qemu, but having sth where it's easy for me to reproduce bugs would be welcome.
Jun 27 14:04:53 <Xu_R>	Ok
Jun 27 14:05:02 <Xu_R>	two stage approach then?
Jun 27 14:05:54 <christanner>	I have to go. Other things to do today.
Jun 27 14:05:58 <colin___>	I think this would work for vbox/qemu providing we make sure that the info goes in the relase notes.
Jun 27 14:06:20 <colin___>	Two stage yes
Jun 27 14:06:24 *	christanner has quit (Remote host closed the connection)
Jun 27 14:06:31 <colin___>	see you chris
Jun 27 14:06:51 <Xu_R>	so first stage is perfect environment, second stage is non-perfect environment
Jun 27 14:06:52 <arisel>	as in "focus on a common emulator/vbox/qemu, but also accepting HW related issues" and after that "focus on trying to install on real HW as far as possible"
Jun 27 14:07:12 <arisel>	Xu_R: Yepp.
Jun 27 14:07:15 <Xu_R>	Ok
Jun 27 14:07:24 <colin___>	Yes that sound good
Jun 27 14:07:30 <ben79_>	Ok
Jun 27 14:08:00 <Xu_R>	Ok, noted
Jun 27 14:08:40 <Xu_R>	ok, let's see...
Jun 27 14:08:59 <Xu_R>	Cooker Standards?
Jun 27 14:09:22 <colin___>	I guess this is my baby
Jun 27 14:09:34 <Xu_R>	Yeah.
Jun 27 14:10:20 <colin___>	I propose that we should have standards for the production of software used in the distribution.
Jun 27 14:10:32 <Xu_R>	define standards...
Jun 27 14:12:31 <arisel>	colin___: i totally agree. I'm wondering on who we get to these standards, though. There are some which are "common knowledge" in the circle of cooker devs, and some which are not agreed there, and a lot of standards are dealing with actually "using the software" which most devs don't really do for 95% of the software they package or build....
Jun 27 14:12:43 <arisel>	s/who we get/how we get
Jun 27 14:12:46 <colin___>	A standard is process or procedure that all partipants in an arena argree to work to. A standard is always subject to revision and must be reviewed by all parities involved in a structured manner
Jun 27 14:14:19 <arisel>	colin___: do you have ideas on how to get to some standards? I might have some on "here to document" :)
Jun 27 14:14:33 <arisel>	s/"here/"where
Jun 27 14:14:50 *	arisel <-- defunct typing processor somewhere between brain and fingers..
Jun 27 14:15:00 <colin___>	Our first aim should be to standardise the packaging procedure. The original Mandriva wiki had very clear guuidlines on this.
Jun 27 14:16:42 <colin___>	I have extracted some of these and asked Matt Dawkins to help by amendingt them in line with current cooker practice. He has taken up the challenge and has indicated to me that he will be consulting with all the devs on this
Jun 27 14:17:02 <arisel>	colin___: fine :)
Jun 27 14:17:05 <arisel>	colin___:
Jun 27 14:17:32 <arisel>	colin___: this should be the place to document them :)
Jun 27 14:18:50 <colin___>	it is in it's infancy I will send you a link later and if you are happy for it to go on the wiki init current state we will do so
Jun 27 14:19:49 <colin___>	There are a number of standards guides on the old mandriva wiki which if published would probably help you to get new packagers and devs.
Jun 27 14:20:19 <arisel>	colin___: th wiki page is just sth i extracted and started some months ago, but mdawkins didn't continue it by then. If he now does I'm happy.
Jun 27 14:20:49 <arisel>	colin___: old mandriva has some, as well as rosa, and i already took a look at fedoras and suse's..
Jun 27 14:21:16 <colin___>	Ok that's good he needs encouraging!!
Jun 27 14:21:21 <arisel>	colin___: due to the different build process and us getting wiser than before we can't just take the old ones.
Jun 27 14:21:36 <arisel>	*g*
Jun 27 14:22:24 <colin___>	I realise that that is why they have to be "filtered" by a cooker devs but they are a start even if they only provide the subject headers
Jun 27 14:23:25 <arisel>	my friend just asked if all of us would be wearing our penguin-shaped meeting hats :)
Jun 27 14:23:50 <arisel>	colin___: I'll talk with mdawkins about that.
Jun 27 14:23:54 <colin___>	Well I've got my flippers on!!
Jun 27 14:24:36 <ben79_>	I thought geeks always wore an AFDB.
Jun 27 14:25:22 <colin___>	One omportant this before we close this. Could the TC generate a list of standards that the think would contribute to the smooth running fo the distro
Jun 27 14:26:01 <arisel>	colin___: I could ask for this. I'm unsure on how specific the outcome will be, but I've an idea on where to aim.
Jun 27 14:26:16 <arisel>	colin___: so I'll add that to the discussion next tuesday.
Jun 27 14:26:22 <colin___>	see what you can do
Jun 27 14:26:24 <arisel>	ok
Jun 27 14:26:49 <Xu_R>	Ok
Jun 27 14:26:57 <Xu_R>	that's all for Cooker, then?
Jun 27 14:27:05 <arisel>	ben79_: By experience i can say that I'm happy if geeks wear stuff at all, but personally I find bankers to be worse.
Jun 27 14:27:15 <colin___>	yes
Jun 27 14:27:30 <colin___>	was that bwankers
Jun 27 14:28:10 <colin___>	I have about 15mins before I have to go to another meeting
Jun 27 14:28:26 <arisel>	(bank employees)
Jun 27 14:28:31 <Xu_R>	Ok, we're done discussing Cooker.
Jun 27 14:28:47 <Xu_R>	QA Testing Standards we've pretty much covered in Release Procedures
Jun 27 14:28:59 <colin___>	yes
Jun 27 14:29:06 <Xu_R>	Branding is more TC, tbh, but QA should keep a look out on any unbranded parts
Jun 27 14:29:27 <Xu_R>	Bugzilla! Uh. The volume of bugs, any ones we should be particularly alerted to?
Jun 27 14:29:38 <colin___>	Should we file bugs against this or just flag cooker
Jun 27 14:29:56 <arisel>	just one point: I could provide you with a smaller iso which boots into kdm and where you can select icewm as window manager. So if that is helpful i can try to get bero or me to regulary build one of those..
Jun 27 14:30:04 <arisel>	or you could build one yourself.
Jun 27 14:30:37 <arisel>	(sorry this was for the topic we jumped over)
Jun 27 14:31:03 <colin___>	Point us to the tools we can do that stuff can't we team?
Jun 27 14:31:10 <Xu_R>	arisel: noted
Jun 27 14:31:39 <Xu_R>	colin___: file bugs against Cooker, yeah, I usually prefix with [branding] or something like that
Jun 27 14:32:00 <arisel>	colin___: ok, will explain the process to Xu_R. Most of it is documented, but still needs editing of one script. think I'll make that configurable, though. Then it should be easy.
Jun 27 14:32:28 <Xu_R>	arisel: It's essentially iso-build-tools and modifying the script, yes?
Jun 27 14:32:35 <arisel>	colin___: +1 for filing branding bugs. I'm fine with any place of filing them.
Jun 27 14:32:38 <colin___>	ok will do we relly should remove the Moondrake terminal screen you get if you don't boot directly into X
Jun 27 14:33:17 <arisel>	Xu_R: yes. the list you want to use is omdv_small_but_stuffed.lst, and you have to change that inside the "build" script.
Jun 27 14:33:48 <Xu_R>	arisel: that's fine, ok
Jun 27 14:34:18 <arisel>	Xu_R: btw. the package uninstall-bug also was iside the iso-build-tools, so be sure that you fixed that before building an iso.
Jun 27 14:34:44 <Xu_R>	arisel: I just clone from the latest iso-build-tools before doing anything else
Jun 27 14:35:31 <arisel>	ok
Jun 27 14:35:50 <Xu_R>	ok. Last issue is proprietary software policy
Jun 27 14:35:58 <arisel>	so sorry.. flawed your agenda. where are we?
Jun 27 14:36:01 <arisel>	*g*
Jun 27 14:36:01 *	Xu_R thinks that should be left up to TC, but ok
Jun 27 14:36:17 <Xu_R>	arisel: nah, it's ok. as long as it's all documented what we did :P
Jun 27 14:36:48 <colin___>	I only want to ask about Adobe Reader and Google Chrome
Jun 27 14:37:05 <Xu_R>	arisel: ^
Jun 27 14:37:22 <colin___>	I assume the prorietry graphics drivers will be supported
Jun 27 14:37:40 <arisel>	colin___: i expect that someone will fix the downloader pkgs or sth like that.
Jun 27 14:37:59 <arisel>	colin___: concerning adobe reader and chrome I'm unsure.
Jun 27 14:38:08 <colin___>	please what is sth?
Jun 27 14:38:39 <arisel>	colin___: do you know about what the licenses of adobe reader or chrome allow us to do?
Jun 27 14:39:29 <arisel>	colin___: maybe have them included as driver/binary blob.
Jun 27 14:39:30 <colin___>	I don't but certainly Mandriva always included Adobe Reader. Chrome is really needed if anyone wants YouTube
Jun 27 14:40:29 <arisel>	colin___: mandriva also included opera, but afaik there has been some deal on this.
Jun 27 14:40:54 <colin___>	I have no more time must go. Thank you everyone for a good and productive meeting we move forward. Bye
Jun 27 14:41:00 <arisel>	colin___: we have a non-free repository where we could include stuff. 
Jun 27 14:41:04 <arisel>	colin___: bye!
Jun 27 14:41:24 <arisel>	We just need to know what we are allowed to include and we need someone who does the work :)
Jun 27 14:41:33 *	bero (~bero@arklinux/developer/bero) has joined #openmandriva-qa
Jun 27 14:41:37 <arisel>	yay!
Jun 27 14:41:41 <bero>	Hi
Jun 27 14:41:47 <arisel>	bero: *g* just in time to get the end of it :)
Jun 27 14:41:57 <Xu_R>	hi bero
Jun 27 14:42:06 <Xu_R>	Arrived a bit too late :/ We're at the end of the meeting :(
Jun 27 14:42:07 <bero>	Sorry, couldn't make it earlier, had to go to Bern to pick up travel documents
Jun 27 14:42:16 <bero>	I thought I'd be home a lot earlier
Jun 27 14:42:18 <arisel>	Xu_R: *g* you should provide bero with a log :)
Jun 27 14:42:39 <arisel>	bero: I also have been late, but not as much. Pulfer has been here in the start, i think.
Jun 27 14:42:40 <Xu_R>	arisel: I will :) I'll put it up on the wiki.
Jun 27 14:42:52 <Xu_R>	[end of meeting]