19:11:03 <ennael> #startmeeting
19:11:03 <Inigo_Montoya> Meeting started Wed Jun 27 19:11:03 2012 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:11:03 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:11:04 <erzulie> [ MeetBot - Debian Wiki ]
19:11:30 <ennael> MrsB: around ?
19:11:48 <MrsB> yep I'm here
19:11:52 <ennael> #chair boklm tmb
19:11:52 <Inigo_Montoya> Current chairs: boklm ennael tmb
19:11:54 <ennael> ok
19:11:59 <ennael> #topic pending security updates
19:12:45 <ennael> MrsB: your turn
19:12:48 <MrsB> oh lol ok
19:13:17 <MrsB> As you all are probably aware QA are really struggling to keep on top of things at the momen
19:13:18 <MrsB> t
19:13:44 <MrsB> since the release of Mageia 2 most updates are for both releases
19:14:08 <MrsB> we have to test them on two architectures and two releases before they can be validated
19:14:19 <MrsB> it all takes time
19:14:33 <MrsB> we are very short of people in QA
19:14:45 <MrsB> I know most already know this
19:15:26 <wally_> how big our QA team is currently?
19:15:27 <MrsB> Our list if slowly growing longer at the moment meaning if we are not careful and don't do something then we will be fallign behind
19:16:00 <ennael> last year we asked also packagers to give a hand on updates
19:16:06 <MrsB> There are fewer than 10 active members really
19:16:08 <ennael> at least to mak this list decrease
19:16:14 <ennael> make
19:16:31 <ennael> what do you need exactly ? tests ? packaging ? devs ?
19:16:39 <MrsB> We have been concentrating on and prioritising security updates
19:16:58 <MrsB> We need people. We need your help essentially
19:17:11 <AL13N> for testing packages?
19:17:27 <MrsB> Anne had the idea to ask you if you can help to test our update candidates
19:17:40 <ennael> so testing then :)
19:17:53 <ennael> can you give a link to the pending updates ?
19:17:58 <AL13N> can we have a list for reference?
19:18:00 <MrsB> She suggested security updates but to be honest any update testing would be very helpful and allow us to concentrate where we are most needed
19:18:14 <MrsB> The list is here: https://bugs.mageia.org/buglist.cgi?quicksearch=%40qa-bugs+-kw%3Avali
19:18:16 <erzulie> [ Bug List ]
19:18:29 <MrsB> If you forget it it is always in the topic in #mageia-qa
19:18:41 <AL13N> hmm, big list already
19:18:54 <ennael> 51 bugs
19:19:00 <MrsB> We have a process to follow which is now well dcoumented here : https://wiki.mageia.org/en/QA_process_for_validating_updates
19:19:01 <erzulie> [ QA process for validating updates - Mageia wiki ]
19:19:25 <MrsB> The list is now longer than it has ever been, even when it was mostly just Dave H and myself doing it for mageia 1
19:19:39 <ennael> ok
19:20:02 <ennael> #info QA team is asking for help on pending updates to finalize tests - 51 bugs pending for now
19:20:05 <MrsB> It is slowly growing longer rather than shorter so we really do need help :)
19:20:41 <ennael> #action ennael will send a mail on -dev to ask for help also
19:20:52 <MrsB> Could you add the links too please ennael
19:21:21 <AL13N> except for asking here, is there some kind of idea we can try for longer term?
19:21:52 <ennael> #link https://bugs.mageia.org/buglist.cgi?quicksearch=%40qa-bugs+-kw%3Avali
19:21:54 <erzulie> [ Bug List ]
19:22:05 <sander85> we need more people, hard to do something about it
19:22:09 <tmb> should we do a QA "bug-squash" days / weekend like we have done for "normal bugs"
19:22:33 <ennael> maybe organize such day once a month
19:22:58 <anaselli> and maybe point some bugs during the meeting, as we do int he final rush of our release...
19:23:14 <MrsB> That would certainly help but I'd ask that if any of you have a spare few minutes or an hour or two to consider doing some QA
19:23:24 <sander85> lets close cauldron if the list gets longer than 30 bugs ;P
19:23:45 <MrsB> If there is anything you are not sure of or if you need som eguidance then please don't hesitate to ask, either in #mageia-qa or on qa-discuss ML
19:23:57 <ennael> ok
19:24:11 <MrsB> thankyou :)
19:24:23 <anaselli> and what about a reminder on -dev mailng list also?
19:24:31 <ennael> see action above
19:24:46 * anaselli hides
19:24:57 <ennael> MrsB: and do not hesitate to ping here when needed :)
19:25:04 <MrsB> will do, thanks
19:25:10 <tmb> MrsB: yep, the "QA Bug-squash day(s)" was to get current list shorter faster...
19:25:28 <MrsB> yeah, it will certainly help to shorten the list
19:25:31 <AL13N> how much time does validating a bug take?
19:25:31 <pterjan> maybe display a link to the list of packages needing to be tested somewhere
19:25:41 <pterjan> like the top of http://pkgsubmit.mageia.org/
19:25:42 <erzulie> [ Mageia build system status ]
19:25:51 <pterjan> Al13N: it depends a lot
19:25:53 <MrsB> It's always in the topic in #mageia-qa pterjan
19:25:55 <ennael> yep good idea
19:26:02 <MrsB> oh yeah, that would help :)
19:26:05 <ennael> MrsB: pêople do not connect to every chan
19:26:07 <ennael> s
19:26:09 <pterjan> MrsB: but only qa people are there :)
19:26:18 <MrsB> I'm not a dev :P
19:26:19 <AL13N> pkgsubmit is a good idea
19:26:20 <ennael> pterjan: can you add this link ?
19:26:23 <tmb> but generally we need more people in QA
19:26:26 <pterjan> ennael: I can
19:26:29 <MrsB> yep, desperately
19:26:32 <ennael> pterjan: can you do it ? :)
19:26:44 <pterjan> yes, I can
19:26:46 <pterjan> :P
19:26:47 <boklm> and will you do it ? :)
19:26:47 <MrsB> please link to the procedure aswell if possible
19:26:50 <ennael> raaa
19:26:51 <tmb> so current QA can have days off too for "normal life"
19:26:52 * ennael slaps pterjan
19:26:53 <AL13N> it would even be better if it was a list of sorts
19:27:02 <MrsB> instead of 10 hour days :\
19:27:09 <ennael> MrsB: met see together how we can get more people
19:27:22 <ennael> I guess looking for in -discuss and forums
19:27:41 <ennael> I'm quite sure people do not know they can help in QA
19:27:43 <MrsB> I'll send an email to discuss ml
19:27:48 <AL13N> "ask them if they want to test the latest & newest stuff", that sounds sexy
19:27:49 <ennael> without being a guru :)
19:28:07 <AL13N> forums sounds like a good idea too
19:28:08 <MrsB> Thats on our team page AL13N :)
19:28:16 <AL13N> :)
19:28:30 <MrsB> it's not really sexy, I think that is half the problem
19:28:33 <ennael> #action look for more people mailing -discuss and asking on forums
19:28:49 <ennael> MrsB: see with forums team
19:28:57 <MrsB> we're only noticed when we mess up
19:29:06 <ennael> MrsB: you can ping doktor5000_
19:29:14 <MrsB> yes, good idea, I'll do that too
19:29:14 <sander85> should we mess up more often then?
19:29:26 <DavidWHodgins> Lol
19:29:38 * tmb thinks of using the backports carrot
19:29:44 <ennael> tmb: agree
19:29:46 <doktor5000_> MrsB: got the message, no need to ping me :)
19:29:48 <ennael> no QA no backports
19:29:53 <MrsB> thanks Florian
19:30:18 <ennael> anything else on that topic ?
19:30:21 <anaselli> tmb: you've already done in your mail no? :D
19:30:22 <Luigi12_work_> yes
19:30:37 * Luigi12_work_ also needs some packaging help from packagers to push some needed security updates
19:30:47 * doktor5000_ got the impression during mga1 updates testing that qa needs to validate cadidate updates themselves, so sometime i stopped posting my own test results ... :/
19:30:53 <doktor5000_> MrsB: ^^^^
19:31:05 <MrsB> yes, you can't validate your own updates
19:31:05 <Luigi12_work_> I don't have a bugzilla quick link handy, but searching for component Security that's not assigned to qa-bugs would get it
19:31:08 <DavidWHodgins> ennael: Some qa on backports.  Install cleanly, and program runs.
19:31:13 <sander85> doktor5000_: you can't validate your own package
19:31:29 <sander85> doktor5000_: but you can test other packages
19:31:30 <ennael> not all at the same time please :)
19:31:37 <MrsB> I'd better add that to our procedure page :D
19:32:24 <AL13N> perhaps we could ask/force every person who submits to validate one package before allowed submission time :-)
19:32:41 * AL13N hides
19:32:53 <MrsB> It is also helpful if when sending updates for validation if packagers can add a way to test on the bug report.
19:32:54 <sander85> you can't track that
19:33:02 <sander85> and then we won't get packages :D
19:33:07 <ennael> #info help needed to finalize some security updates
19:33:12 <ennael> #link https://www.mageia.org/pipermail/mageia-dev/2012-June/016919.html
19:33:14 <AL13N> but also no updates to validate :-)
19:34:13 <Luigi12_work_> thanks ennael.  guillomovitch has helped with three of the specific ones I linked in that mail, but there are a bunch of others that haven't been packaged yet as they need help from maintainers.
19:34:51 <ennael> Luigi12_work_: please mail -dev about them
19:34:59 <Luigi12_work_> ennael: ok, will do
19:35:00 <ennael> in new thread
19:35:03 <Luigi12_work_> yep
19:35:10 <ennael> ok next topic now
19:35:22 <ennael> #topic Mageia 3 features
19:35:32 <MrsB> thankyou for that
19:35:47 <ennael> as a reminder
19:35:51 <ennael> #link https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html
19:36:26 <ennael> so before we start on it
19:37:04 <ennael> the features which were accepted were not accpeted because people are part of council or board
19:37:12 <guillomovitch> too bad
19:37:16 <ennael> or because they offer some beer to boklm :)
19:37:22 <guillomovitch> I dismiss immediatly :)
19:37:25 <ennael> :p
19:37:38 <ennael> but because mainly all items were fully filled
19:37:42 <ennael> especially resources
19:38:04 <ennael> so the second list about pending features need to be completed
19:38:10 <sebsebseb> forgot about this meeting
19:38:22 <ennael> and the main point is usually about resources
19:38:23 <AL13N> what exactly needs in resources? only names? or descriptions?
19:38:28 <ennael> names
19:38:39 <ennael> resources are people who are going to work on it
19:38:54 <AL13N> so "packager" is invalid
19:39:01 <AL13N> also "<foo> maintainer"
19:39:05 <sander85> yep
19:39:05 <ennael> sure
19:39:12 <ennael> did you ask foo ?
19:40:07 <pterjan> MrsB: http://pkgsubmit.mageia.org/
19:40:10 <erzulie> [ Mageia build system status ]
19:40:47 <MrsB> thats great pterjan thanks!
19:41:07 <ennael> so please have a look on this second list
19:41:28 <ennael> is it all clear about how it works ?
19:41:35 <Luigi12_work_> no
19:41:41 <AL13N> i made some modifications on the second list when it was mailed, and i replied in thread, how will i know it's sufficient now?
19:41:58 <ennael> just ask on -dev :)
19:42:08 <ennael> you are a big guy :)
19:42:55 <rindolf> Hi all, sorry I'm late.
19:43:00 <ennael> Luigi12_work_: what is not clear ?
19:43:15 <Luigi12_work_> same as what AL13N asked
19:43:32 <AL13N> ennael: well, i did, i replied on the original email
19:43:39 * Luigi12_work_ did too
19:43:39 <AL13N> i had no response
19:43:42 <ennael> AL13N: then we are late :)
19:44:07 <ennael> will have a look after meeting
19:44:34 <AL13N> https://wiki.mageia.org/en/FeatureMageia3_Review
19:44:35 <ennael> mainly 4 criteria : planning, explanations, resources, contingency
19:44:35 <erzulie> [ FeatureMageia3 Review - Mageia wiki ]
19:45:35 <ennael> question ? comment ?
19:45:52 <anaselli> well i'm afraid to ask :)
19:46:08 <ennael> well you may die burnt but try
19:46:09 <anaselli> UiAbstraction4mcc contact anaselli... are you sure?
19:46:11 <ennael> we never know :)
19:46:41 <boklm> anaselli: you need to contact Steven Tucker to see how to merge with his feature
19:47:04 <boklm> before both features are doing the same thing
19:47:42 <anaselli> ennael: but we really want to switch from perl to libYui?
19:48:06 <boklm> it's not "switching from perl"
19:48:07 <anaselli> boklm: i understand that
19:48:30 <boklm> but details about implementation of ui abstraction can still be discussed
19:48:48 <anaselli> well that is what i understood... in a first sight on mailing list...
19:49:00 <boklm> I think libYui can be used from perl
19:49:26 <anaselli> and that was what i'm afraid of :D
19:49:41 <boklm> afraid of what ?
19:49:55 <anaselli> but better not to talk about only a feature... maybe mailing list is better
19:50:24 <ennael> anaselli: can you mail about this ?
19:50:39 <ennael> maybe none of these proposals will be chosen at the end :)
19:50:41 <anaselli> about UiAbstraction4mcc you mean?
19:50:46 <ennael> still it needs to be discussed
19:51:07 <anaselli> ok i will rise a new discussion on it then
19:51:13 <ennael> thanks
19:51:22 <AL13N> is it better to make a new thread?
19:51:29 <AL13N> for these discussions?
19:51:33 <ennael> one thread / feature
19:51:37 <AL13N> ok
19:51:41 <anaselli> not really, just add a new comment AL13N i believe it's ok :)
19:51:57 <ennael> anything else on features ?
19:52:00 <anaselli> ah ok anyway
19:52:07 <AL13N> no, that's it for me
19:52:20 <AL13N> i do want some more resources for my features though, but yeah
19:52:33 <ennael> then ask people directly :)
19:52:39 <AL13N> will do
19:52:42 <ennael> ok let see 3rd topic
19:52:52 <ennael> the never-ended-one
19:53:00 * AL13N phears
19:53:03 <ennael> #topic Backports
19:53:06 <anaselli> AL13N: ask to QA :)
19:53:07 <sander85> /o\
19:53:11 * Luigi12_work_ punts
19:53:15 <anaselli> they have a lot of resources :p
19:53:16 <ennael> tmb: your turn ! :)
19:53:23 * tmb runs...
19:53:26 <ennael> :)
19:53:28 <tmb> :)
19:53:29 <AL13N> :)
19:53:32 <Luigi12_work_> yay meeting over
19:53:33 <ennael> one thing
19:53:44 <ennael> we need to finalize things tonight
19:54:02 <ennael> this is getting just ridiculous and like a running gag :)
19:54:03 * anaselli caught tmb running then :D
19:54:16 <ennael> tmb: your turn :)
19:54:48 <tmb> so most of you have read _all_ of the threads ...
19:54:50 <tmb> :)
19:55:09 <Stormi> I stopped reading my own thread at some point :)
19:55:37 <tmb> I think we are mostly in agreement of need for backports and what it is
19:55:48 <pterjan> backports have been open forever until recently and no one opened any, why are we still talking about it /o\
19:55:56 <sander85> mostly :P
19:56:02 <pterjan> (just because no one tried to upload any?)
19:56:31 <Luigi12_work_> we don't need no stinking backports :o)
19:56:56 <tmb> #link https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html
19:57:15 <AL13N> tmb: if we're mostly in agreement, what is the issue then?
19:57:41 <sander85> what "supported" means? :P
19:57:56 <tmb> the things that is missing are what level of support we mean by "supported"
19:57:56 <sander85> actually who propsed it?
19:58:03 <sander85> who wanted supported backports?
19:58:18 <AL13N> i don't remember that long ago
19:58:36 <Stormi> me for sure
19:58:37 <DavidWHodgins> sander85: I do, but only to the point of installing cleanly and basic running.
19:59:02 <sander85> DavidWHodgins: that's "tested" not "supported"
19:59:07 <AL13N> i'm ok with just installing and running tests, but we can't call that supported
19:59:12 <sander85> DavidWHodgins: i also want them to be tested
19:59:17 <AL13N> i'm even ok with sec updates
19:59:20 <sander85> but don't care about the supported part
19:59:25 <sander85> they are backports
19:59:30 <Luigi12_work_> "supported" also means the packager is running it, knows it works, watches upstream, and makes bugfix and security updates for it when needed
19:59:45 <spturtle> supported simply means if something is reported as broken it will get looked at and maybe fixed
19:59:46 <pterjan> "makes bugfix and security updates for it when needed" is the mandatory part in my opinion
19:59:46 <DavidWHodgins> Ok.  Tested then.
19:59:58 <AL13N> in any case, i'm not gonna advise newbies to use backports though, this tested is for me not enough
20:00:21 <tmb> Well, basically the idea of supported backports is that im mdv times we told people that they are on their own if they use any backports, and we wanted to provide better service than that
20:00:28 <Luigi12_work_> and they shouldn't have to be told when security updates are needed.  If the packager won't keep track it of themself, they shouldn't push it to backports.
20:00:29 <sander85> yes, backports are not for noobs anyway
20:00:32 <AL13N> tmb: i agree with that
20:00:36 <sander85> as they can break upgrades
20:01:24 <sander85> does anyone know how debian does backports?
20:01:30 <sander85> do they support them? or how?
20:01:51 <andre999> I think that all backport packages should be tagged as backports - in the file name
20:02:01 <tmb> we cant do anything about people installing from 3rdparty repos, but since it's our own repos we want better support
20:02:12 * AL13N agrees
20:02:16 * MrsB does too
20:02:17 * Stormi too
20:02:18 * anaselli agrees
20:02:27 <andre999> agree
20:03:06 <sander85> i think it's good enough support if they are tested and run
20:03:15 <tmb> meaning we want at least some level of testing/validation that if someone installs anything from backports it's known to work.
20:03:17 <sander85> for me backports are all about cherry-picking
20:03:24 <AL13N> sander85: i think that's fine, but let's call it "tested"
20:03:50 <MrsB> what do we call our updates?
20:03:51 <sander85> yes, i'm ok with "tested by QA"
20:03:52 <tmb> and if you hit a bug or a security issue in backports, it will be fixed
20:03:52 <andre999> but the packager should commit to provide security and bug fixes as well
20:03:56 <Stormi> ok, and if someone reports a bug no one fixes it ?
20:04:06 <Stormi> tmb answered
20:04:22 <Stormi> that's the difference between "tested" and "supported"
20:04:26 <anaselli> we wil work on it
20:04:30 <AL13N> the packager is responsible for it, but what if the packager disappears for that?
20:04:36 <sander85> bugs will be provided with new backport (if it's possible)
20:04:50 <sander85> and the new version still compiles on older release
20:05:05 <andre999> AL13N: what if the packager disappears for an ordinary package ?
20:05:12 <sander85> that's why i didn't want to allow backporting from current cauldron to mga1
20:05:15 <anaselli> AL13N: as for an update... if someone goes...
20:05:26 <sander85> it's quite a lot time between those two versions
20:05:39 <Luigi12_work_> sander85: I agree, I don't think it should open for mga1
20:05:57 <AL13N> i don't care either way
20:06:03 * pterjan neither
20:06:04 <andre999> sander85: but backports are leaf packages - which should be easier to support
20:06:14 <AL13N> i was planning on backporting mine for mga1 too, but if it's not, than it's not
20:06:25 <pterjan> I don't see a problem with opening it
20:06:38 <pterjan> I expect fewer people to backport to mageia 1
20:06:45 <AL13N> as tmb said, we should just agree to open now and review policy in 6 months
20:06:45 <andre999> true
20:06:56 <andre999> good idea
20:07:09 <anaselli> AL13N: if something has to be reviewed of course :)
20:07:09 <AL13N> who agrees?
20:07:12 <tmb> so the things that still need to be decide:
20:07:13 <tmb> https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html
20:07:49 <tmb> I meant: Do we support backporting package with higher version than package in the following next mageia release has ?
20:07:59 <DavidWHodgins> I vote yes.
20:08:01 <sander85> i would say no
20:08:05 * boklm agrees about backporting bigger version to mga1 than mga2 release
20:08:08 <MrsB> yes for me
20:08:20 <Luigi12_work_> I don't think you can reasonably disallow that
20:08:23 <AL13N> i don't care either way
20:08:38 <pterjan> I vote yes, provided next point
20:08:38 <DavidWHodgins> Just include warning that it may break upgrading.
20:08:43 <Stormi> yes too, but would be a good feature to detect upgrade problems before performing the upgrade
20:08:54 <sander85> i see PR problems where mageia can't be upgraded because some noobs messed up their upgrade with backports
20:08:55 <boklm> pterjan: which point ?
20:09:04 <DavidWHodgins> Too late to change the iso images.
20:09:10 <pterjan> If one want to backport a package to mga1, does it mean
20:09:10 <pterjan> it must be backported to mga2 in order to preserve
20:09:10 <pterjan> upgrade path (unless already in mga2, depending on
20:09:10 <pterjan> question 1)?
20:09:13 <pterjan> boklm: ^
20:09:20 <MrsB> Stormi: good point
20:09:54 <DavidWHodgins> mgaapplet would have to be changed to allow selecting backports during upgrade.
20:09:56 <andre999> I would add that for the 2 points near the end, that we say that a backport to mga1 should have requires that will be available if the user updates to mga2
20:09:59 <pterjan> it does not need to be in the mga2 release,  but at least in backports
20:10:18 <boklm> ok
20:10:38 <AL13N> the same version is sufficient, right?
20:10:41 <pterjan> yes
20:10:47 <AL13N> fine for me
20:10:50 <MrsB> unless mga2 > mga1 regardless
20:10:58 <AL13N> most backports will just put cauldron to 1 & 2
20:10:59 <sander85> if it's in backports it will still break upgrade
20:11:02 <Stormi> ok with pterjan
20:11:02 <pterjan> just don't backport cauldron > mga1 without backporting to mga2 too
20:11:14 <Stormi> sander85: until we take them into account... on day
20:11:16 <pterjan> sander85: that's another point that needs to be fixed
20:11:16 <Stormi> one
20:11:37 <sander85> i don't see how this can be fixed.. it won't be easy
20:11:47 <AL13N> remembrance of previous enabled repos, to be preserved after upgrade is something that needs fixing anyway
20:11:48 <boklm> only advanced users should use backports, and upgrade
20:12:00 <pterjan> sander85: as AL13N said
20:12:10 <AL13N> sander85: it won't be foolproof, but in most cases it should work
20:12:17 <tmb> remember that backports is also mostly leaf packages so a core upgrade should work pretty good.
20:12:18 <AL13N> there's tagging in the media.cfg
20:12:38 <anaselli> DavidWHodgins: why should we remove backports during upgrade in mgaapplet? but anyway we already remove tainted and non free...
20:12:49 <AL13N> except, someone will have to do the work of fixing that one (and bug 2317)
20:12:58 <sander85> it will be more work for QA tho'
20:13:14 <pterjan> anaselli: not really removed, all media get removed and new ones added, keeping defaults currently
20:13:16 <AL13N> sander85: backport packager is responsible for QA
20:13:18 <sander85> they have to check that backports are available in mgaN+1 too
20:13:26 <anaselli> tmb: agree, and we should be sure also that an old lib dependency can work
20:13:31 <DavidWHodgins> anaselli: I'm saying if Mageia 1 has backports enabled, the upgrade should keep it enabled.
20:13:40 <pterjan> yes
20:13:51 <pterjan> I guess there is a bug open for that
20:14:04 <MrsB> its more than just being 'enabled' though
20:14:05 <anaselli> DavidWHodgins: ops i understood the right contrary :)
20:14:18 <MrsB> its if there are packages installed from it, not if it's enabled
20:14:40 <DavidWHodgins> MrsB: True.  Cherry picking makes it more complicated.
20:14:41 <AL13N> hmm, that is more difficult, indeed
20:14:54 <anaselli> tmb: i mean the case discussed in mailing list libfoo.so.1 and libfoo.so.2, it's covered by our policy
20:14:57 <MrsB> thats what breaks the upgrade after all
20:15:08 <Stormi> still, we can at least detect packages that come from no activated media and warn
20:15:19 <andre999> it shouldn't be necessary for backports to be enabled for backport upgrades
20:15:27 <MrsB> thats one simple way stormi yeah
20:15:33 <andre999> otherwise many users will miss the upgrades
20:15:56 <tmb> anasselli: well, libification policy  protects older libs as we dont remove needed libs on endusers systems
20:16:20 <anaselli> Cherry picking is not having bp enabled MrsB, so in that case is just as if we installed a package by ourself during upgrade
20:16:33 <sander85> tmb: with task-obsolete we now are doing it :/
20:16:53 <tmb> well, then people are abusing task-obsolete
20:17:06 <Luigi12_work_> that's true in general
20:17:18 <DavidWHodgins> Doesn't it have to be done, in cases where files move between packages?
20:17:23 <anaselli> tmb: so yes in that case we can have a running system even if we cannot upgrade a package that is not on next release
20:18:03 <AL13N> what if we just make it so that the upgrade works, even if there's backported version installed, we just warn the user (because there's a chance those backported versions are removed) ???
20:18:21 <DavidWHodgins> urpmi cascade errors.
20:18:44 <AL13N> in case of conflict, the backported package is removed? <---- that should be ok
20:19:03 <AL13N> (and user is warned)
20:19:16 <MrsB> so we're back to detecting installed backports before doing the upgrade
20:19:17 <sander85> that's extra work
20:19:28 <AL13N> no, i mean during upgrade
20:19:29 <sander85> don't think anyone is going to do it on mga1
20:19:40 <Stormi> taking users into account is always extra work sander85
20:19:48 <Stormi> you think like a developer
20:19:52 <andre999> :)
20:20:06 * boklm would say backports are not recommended for normal users who plan to do an upgrade, or at their own risk
20:20:19 <anaselli> AL13N: they are leaf, so there should not be conflicts, but sometimes during upgrade some official packages are removed anyway... (most devel for instance)
20:20:29 <sander85> AL13N: well, if we enable backports for mga1 then upgrade to mga2 is already broken :P
20:20:46 <sander85> isos are built, no way to add this warning part
20:20:51 <andre999> sander85: why ?
20:20:52 <DavidWHodgins> Agreed.  Include a warning when announcing opening of backports.
20:21:10 <sander85> andre999: wanna rebuild isos?
20:21:13 <tmb> actually urpmi/rpmdrake does ask the question "<package x> have to be removed in order to install <package y>, do you want to continue"
20:21:16 <boklm> people who don't want any problem upgrading should avoid backports, or be ready to fix a few small problems during upgrade
20:21:29 <andre999> we could have a warning every time a backport is installed
20:21:29 <MrsB> or big ones
20:21:34 <anaselli> boklm: CLI installation is more reliable than the graphics one... but normal user does not use it :)
20:21:34 * AL13N agrees with boklm
20:21:46 <Stormi> ok, but to be really user friendly, this message should be visible not far from where people install backports
20:21:57 <anaselli> boklm: more for upgrade
20:22:00 <Stormi> a warning message when activating the media in urpmi-edit-media would be more visible
20:22:13 <Stormi> than a blog post read by maybe 1000 people
20:22:24 * MrsB agrees
20:22:26 <AL13N> i'm ok for warning message
20:22:32 <anaselli> Stormi: why no warning if you enable nonfree...
20:22:38 <Stormi> we could
20:23:06 <tmb> yes, the tools need to be updated to inform user of the enbling extea repos
20:23:12 <anaselli> people does not read messages, ates dialog popups and hit ok
20:23:26 <Stormi> anaselli: but then we can say "not our fault, we told ya"
20:23:38 <Stormi> I often deal with users, this is a good card to have
20:23:40 <tmb> iirc tv has this somewhat done in a testing branch
20:23:46 <sander85> anaselli: we'll label the button "kO" ;P
20:23:52 <anaselli> but if we say we support it... it's a nonsense
20:24:10 <Stormi> I see it as temporary
20:24:15 <Stormi> until we are able to upgrade them
20:24:25 <Stormi> one step after the other
20:24:28 <AL13N> SUMMATION
20:24:28 <AL13N> - we agree on backports to be opened now and supported
20:24:28 <AL13N> - we want to open up backports for mga1 too, but we'll put in warnings if media is selected to warn about upgrade
20:24:28 <AL13N> - if due to backports upgrade fail, user can fix that (we could also give warnings here)
20:24:28 <AL13N> - bug 2317 should be fixed ASAP preferably before opening backports
20:24:31 <AL13N> who agrees?
20:24:39 <andre999> agree
20:24:47 <MrsB> -preferably
20:24:49 <sander85> we didn't agree on supported part
20:24:53 <sander85> did we? :P
20:24:59 <DavidWHodgins> Tested, not supported.
20:25:00 <AL13N> tested?
20:25:03 <AL13N> bad wording
20:25:06 <AL13N> ok
20:25:07 <andre999> it depends what you mean by supported
20:25:07 <sander85> yes, tested
20:25:16 <Stormi> DavidWHodgins: tested means we don't fix bugs
20:25:18 <sander85> tested is safe
20:25:24 <AL13N> but we need to do something, or we'll talk until midnight
20:25:34 <Stormi> policy says supported
20:25:36 <tmb> supported means security update and bugfixes.
20:25:50 <MrsB> we can explain on the policy
20:25:50 <Stormi> and everybody had time to speak up when we wrote it
20:25:51 <anaselli> and we can't say no there i believe...
20:25:59 <sander85> well, we can force in policy to provide new backport with bugs fixed
20:26:02 <sander85> if possible
20:26:12 <Stormi> that's the policy already
20:26:13 <sander85> but we should not say we have supported backports
20:26:23 <Stormi> supported but relying on upstream as much as possible
20:26:28 <Stormi> not patching everything
20:26:28 <sander85> we have no tools to support theb that way currently
20:26:32 <AL13N> SUMMATION(v2):
20:26:32 <AL13N> - we agree on backports to be opened now and tested (but security updates are done and bugs are fixed)
20:26:32 <AL13N> - we want to open up backports for mga1 too, but we'll put in warnings if media is selected to warn about upgrade
20:26:32 <AL13N> - if due to backports upgrade fail, user can fix that (we could also give warnings here)
20:26:32 <AL13N> - bug 2317 should be fixed ASAP preferably before opening backports
20:26:43 <sander85> this would mean backports repo should be marked as updates repo
20:26:47 <MrsB> minus 'ASAP preferably'
20:26:48 <sander85> then they are supported
20:26:48 <AL13N> is this better?
20:27:21 <DavidWHodgins> Ok with me.
20:27:32 <AL13N> SUMMATION(v3):
20:27:33 <AL13N> - we agree on backports to be opened now and tested (but security updates are done and bugs are fixed)
20:27:33 <AL13N> - we want to open up backports for mga1 too, but we'll put in warnings if media is selected to warn about upgrade
20:27:33 <AL13N> - if due to backports upgrade fail, user can fix that (we could also give warnings here)
20:27:33 <AL13N> - bug 2317 should be fixed before opening backports
20:27:34 <sander85> ok, what about warnings for mga1?
20:27:36 <MrsB> :)
20:27:53 <Stormi> so you rewored supported into tested (but security updates are done and bugs are fixed)
20:27:54 <tmb> sander85: no. backports is not updates repo..
20:27:56 <sander85> those warnings need developing + translating.. who's gonna do that? :)
20:27:56 <Stormi> which is the same
20:28:05 <Stormi> if it helps people feel better...
20:28:11 <AL13N> yes
20:28:11 <sander85> tmb: that's what i'm saying
20:28:35 <sander85> tmb: currently there is no way to support backports with automatic updates
20:28:36 <Stormi> sander85: you're supposing that supported === update repo
20:28:41 <AL13N> we can still update mga1 rpmdrake to show warnings?
20:29:02 <leuhmanu> btw: there will be advisory for backport like updates ?
20:29:02 <Stormi> help working on the backport update applet and your problem disappears
20:29:32 <sander85> AL13N: you can update it but you need translations too
20:29:46 <leuhmanu> (and mga1 and mga2 should not have new feature (like these warning..))
20:29:53 <anaselli> leuhmanu: imo yes, so packagers will think twise before backporting and backporting :)
20:31:11 <boklm> so, everybody agree about opening backports, supported with security updates and bugfix ?
20:31:21 <anaselli> tmb: are you saying we should develop a new applet for backports really? could not we just (becase we want it) enable bp as update?
20:31:30 <anaselli> boklm: yes
20:31:32 <AL13N> SUMMATION(v4):
20:31:32 <AL13N> - we agree on backports to be opened now and tested (but security updates are done and bugs are fixed)
20:31:32 <AL13N> - we want to open up backports for mga1 too, but we'll put in warnings if media is selected to warn about upgrade (mga1 is updated to show warnings too + translations)
20:31:32 <AL13N> - if due to backports upgrade fail, user can fix that (we could also give warnings here)
20:31:32 <AL13N> - bug 2317 should be fixed before opening backports
20:31:32 <AL13N> - some kind of applet takes care of updates for backports
20:31:56 <boklm> AL13N: better to do one at a time
20:31:57 <anaselli> AL13N: i don't lile last :(
20:32:21 <AL13N> ok, let's do a quick agreement point by point
20:32:34 <boklm> so does someone disagree about opening backports, supported with security updates and bugfix ?
20:32:37 <tmb> anaselli: well, enduser can flag it as an update media and the update applet will obey it, but we wont do it by default
20:32:42 <AL13N> anaselli: user can mark it as updates, but it'll be problematic
20:32:57 <anaselli> we don't want normal user enable it by default, but we are going to get the expert user confused by more applet :)
20:33:04 <boklm> can you wait until we agree with first point ?
20:33:14 <ennael> please guys
20:33:16 * MrsB agrees
20:33:18 * AL13N agrees with point 1
20:33:19 <DavidWHodgins> I agree with first point.
20:33:26 <andre999> tmb: once we have fixed the tools, i think backports should be update media
20:33:31 <ennael> andre999: please
20:33:44 <Stormi> AGREES
20:33:45 <Stormi> oops
20:33:49 * malo agrees with point 1
20:33:57 <sander85> i agree
20:33:57 <andre999> agree
20:33:59 <anaselli> ok for 1
20:33:59 * tmb agrees with point 1
20:34:05 <boklm> #agreed backports will be opened, supported with security updates and bugfix
20:34:05 * ennael agrees
20:34:12 * sebsebseb agrees for backports to be opended (and isn't on the packaging team)
20:34:12 <AL13N> ok, - we want to open up backports for mga1 too, but we'll put in warnings if media is selected to warn about upgrade (mga1 is updated to show warnings too + translations)
20:34:29 <DavidWHodgins> Agree with second point.
20:34:33 <Stormi> agreed but I don't see why the warning concerns only mga1
20:34:37 <Stormi> same pb with mga2
20:34:48 <AL13N> Stormi: there's "too"
20:34:49 <sander85> can't agree (don't know who's going to do it :))
20:34:54 <anaselli> AL13N: i've already enabled.... so what kind of warning shouldi expected?
20:35:05 <Stormi> AL13N: ok, that's the but I thought was related to mga1
20:35:12 <Stormi> the "but"
20:35:15 <andre999> agree point2, also for mga2
20:35:17 <AL13N> please, let's not get too complicated in details here
20:35:35 <sander85> well, details are needed at such points :)
20:35:35 <rindolf> Agree.
20:35:44 <AL13N> if in general you agree with the idea, let's go with this, the implementation will need to be discussed anyway
20:35:45 <ennael> agree on 2
20:35:45 <Stormi> AL13N: I meant this could be 2 separate points
20:35:47 <anaselli> i think no warning needed, imo
20:35:50 <sander85> we can agree to do whatever, but if we don't have people to work on it
20:36:01 <Stormi> although I agree with both
20:36:04 <ennael> sander85: this is not the point here
20:36:37 <sander85> lets say most agree, so next point
20:36:46 <AL13N> - if due to backports upgrade fail, user can fix that (we could also give warnings here)
20:36:49 <tmb> yes, I agree and we need the tools to inform people on the media selection
20:36:54 <malo> Warning can say that there is a new stable version (mga2) that might fit better than backports on 1, no?
20:37:23 <sander85> i don't understand that point
20:37:47 <sander85> user can fix that or user must fix that manually?
20:37:51 <sander85> which one is it?
20:38:07 <DavidWHodgins> Must fix manually, I think.
20:38:18 <AL13N> this is about upgrade failure due to package not being in core/release of next version
20:38:25 <AL13N> or lower in version at least
20:38:40 <AL13N> since there's no way to fix this even with backports enabled, we'll have to do it this way
20:38:59 <DavidWHodgins> Agreed.
20:39:01 <boklm> so 2nd point: opening backports for mageia 1 too, but users should be aware that it can potentialy create problems when upgrading, and may need to fix some problems manually
20:39:10 <boklm> who agrees with opening backports for mageia 1 ?
20:39:18 * AL13N agrees
20:39:21 <DavidWHodgins> I Agree.
20:39:24 <andre999> agree
20:39:29 * Stormi agrees
20:39:30 * MrsB does
20:39:31 * tmb agree
20:39:34 <ennael> agree
20:39:44 <anaselli> AL13N: you mean upgrade fails for that package only
20:39:49 <anaselli> if so yes
20:39:49 <AL13N> yes
20:39:50 <boklm> #agreed opening backports for mageia 1 too, but users should be aware that it can potentialy create problems when upgrading, and may need to fix some problems manually
20:39:51 <anaselli> agree
20:40:01 <Stormi> boklm: no more warning?
20:40:15 <sebsebseb> !me agree's
20:40:15 <Muet_d_hiver> sebsebseb: Error: "me" is not a valid command.
20:40:20 * sebsebseb agree's
20:40:28 <anaselli> we can add on release note also
20:40:31 <anaselli> notes
20:41:04 <boklm> Stormi: some warnings can be added, to be seen with rpmdrake developers
20:41:04 <sander85> so, next point?
20:41:04 <AL13N> who agrees with displaying warning on rpmdrake when enabling the backports?
20:41:11 <Stormi> ok
20:41:12 <AL13N> ok
20:41:13 <sebsebseb> sounds good to me
20:41:20 <andre999> ok
20:41:21 <tmb> ok
20:41:24 <MrsB> ok
20:41:26 <ennael> ok
20:41:26 <DavidWHodgins> Yes, provided checkbox to say don't show me again.
20:41:30 <sander85> yeah, warning should be there
20:41:37 <AL13N> ok
20:41:41 <AL13N> so next point: - bug 2317 should be fixed before opening backports
20:41:49 <MrsB> definitely!
20:41:53 <andre999> agree
20:41:55 <sander85> i don't think that's important
20:41:56 <sebsebseb> probably, I don't  know what that is though
20:41:57 <sander85> but
20:41:58 <Luigi12_work> non-negotiable
20:42:01 <DavidWHodgins> Yes.
20:42:09 <sander85> QA won't process any backports before it is :D
20:42:16 <MrsB> :)
20:42:29 <MrsB> or necessarily any updates ;)
20:42:31 <Stormi> #agreed warning displayed when someone activates a backport media in drakrpm-edit-media, with checkbox to tell "don't warn anymore"
20:42:35 <anaselli> so we provide them as update :p MrsB
20:42:47 <Luigi12_work> anaselli: hehe :o)
20:43:21 <boklm> Stormi: question is wether it should be done before opening backports, or can be done later
20:43:23 <anaselli> ok then
20:43:43 * AL13N thinks QA will shoot us to death if we don't fix before
20:43:49 <Stormi> boklm: that was a late "agreed" from previous point
20:43:54 <AL13N> and see first topic of this meeting
20:43:57 <DavidWHodgins> Should be done before qa validates any backports.
20:44:00 <boklm> Stormi: yes, I'm talking about the warning
20:44:09 <anaselli> next point?
20:44:12 <Stormi> boklm: oh, yes can be later
20:44:16 <boklm> whether warning should be added in rpmdrake before opening backports
20:44:19 <sander85> it doesn't stop opening backports
20:44:27 <AL13N> - some kind of applet takes care of updates for backports
20:44:32 <leuhmanu> Stormi: you are not chairs so the command don't work
20:44:34 <sander85> but QA won't validate any backport
20:44:37 <Stormi> boklm: given developers availability it will be afterwards
20:44:40 <Stormi> I guess
20:44:44 <boklm> ok
20:44:55 <andre999> ok
20:45:15 <anaselli> what are we voting for now? :/
20:45:23 <AL13N> nothing yet
20:45:29 <Luigi12_work> so does the applet only upgrade backported packages you have installed, or all packags you have installed for which backports are available?
20:45:34 <Stormi> anaselli: 2*3+1=7
20:45:36 <AL13N> can someone chair do the agreed?
20:45:37 <anaselli> ah ok i was not that confused then :)
20:45:40 <andre999> anaselli: warning in rpmdrake
20:45:41 <boklm> I don't think we need to vote for "some kind of applet takes care of updates for backports", we just need someone to do it
20:45:51 <AL13N> ok so
20:45:56 <AL13N> in general we agree
20:46:03 <AL13N> now we need to find the resources for all things to be done
20:46:06 <anaselli> nop
20:46:16 <MrsB> This won't have gone i minutes either .. <Stormi> #agreed warning displayed when someone activates a backport media in drakrpm-edit-media, with checkbox to tell "don't warn anymore"
20:46:19 <anaselli> i don't, but i leave you decide on it :)
20:46:47 <AL13N> who can mail to -dev detailing all the needed things to be done for backports to be working?
20:46:51 <Stormi> anaselli: that's because you don't want to provide updates notifications for cherry-picked backports?
20:47:00 <boklm> #info it is planned to add a warking when activating a backport media in drakrpm-edit-media, with checkbox to tell "don't warn anymore"
20:47:13 <anaselli> Stormi: i don't want another applet for bp...
20:47:32 <anaselli> i just prefer to enable bp as update by myself
20:47:40 <boklm> it's not necessarily another applet
20:47:45 <Stormi> indeed
20:47:46 <AL13N> indeed
20:47:54 <Stormi> anaselli: so if it's configurable you're ok with it
20:47:57 <andre999> true
20:47:57 <AL13N> depends on how easy it is to add it
20:47:57 <sander85> anaselli: you can do that already if you want to
20:48:33 <DavidWHodgins> Just need some way people who cherry pick can find out there is an updated backport, for something they've cherry picked.
20:48:53 <AL13N> ok, so, who volunteers to mail -dev ML with all the stuff that needs to be done so that backports can be opened? and to find the resources for it?
20:49:12 <sander85> AL13N: you proposed :)
20:49:14 <anaselli> if you cherry pick, you cannot know what other things are in bp without enabling it again ;)
20:49:18 <sander85> you can search for people :P
20:49:35 <AL13N> sander85: i can do it, but you'll have to live with the consequences if i fail to do it right
20:49:39 <Stormi> anaselli: unless something updates the backport media silently for you and searches it
20:49:45 <andre999> DavidWHodgins: easy way is treat bp like updates, except only to bp
20:49:53 <boklm> #info work is needed to add support for automatic updates of installed backports
20:49:54 <AL13N> tmb: would it be possible for you do detail this? if not, i'll do it
20:50:34 <anaselli> Stormi: same as other media, if they're not enabled you can't see what they have
20:50:37 <DavidWHodgins> What about a seperate mailing list for backports being pushed?
20:50:46 <boklm> DavidWHodgins: for backport announces ?
20:50:48 <Stormi> anaselli: you can with --search-media
20:50:59 <DavidWHodgins> boklm: Yes.
20:50:59 <Stormi> I use it to install update candidates
20:51:09 <boklm> DavidWHodgins: yes, it can be useful
20:51:13 <anaselli> Stormi:  that is not a gui command :)
20:51:18 <Luigi12_work> those will be really short mails.  "xmoto 1.3.0 is available."
20:51:23 <MrsB> its a great idea Dave I think
20:51:38 <Stormi> anaselli: I mean, technically, we can search unactive media
20:51:49 <anaselli> ok
20:51:55 <Stormi> rpmdrake even installs backports from unactive backport media
20:51:58 <andre999> Stormi: exactly
20:52:13 <MrsB> depcheck searched inactive media
20:52:18 <MrsB> -d+s
20:52:28 <anaselli> have we finished?
20:52:29 <boklm> #info mailing list will be created for backports announces
20:52:41 <AL13N> ok
20:52:56 <AL13N> i'll send email to -dev detailing all the necessary work and requesting people to do it
20:52:58 <anaselli> i need to feed my fish and change his water :)
20:53:00 <sebsebseb> DavidWHodgins: yep  I think a seperate mailing list   is a good idea as well,  I remember after Mageia 2 version freeze for example,  and how that went on the dev mailing list, because even so people wanted to push quite a lot of stuff
20:53:07 <AL13N> but please someone correct me if i make a mistake
20:53:24 <Stormi> QA will provide updated backport validation procedure in the following days
20:53:36 <Stormi> there's one already, we just need to look into the details
20:53:42 <boklm> #info QA will provide updated backport validation procedure in the following days
20:54:01 <anaselli> boklm: similar to update?
20:54:04 <Stormi> yes
20:54:23 <DavidWHodgins> Will older versions be kept in backports?
20:54:43 <anaselli> one only repo
20:54:55 <MrsB> will requires be strict?
20:54:57 <sander85> DavidWHodgins: yeah
20:55:06 <sander85> i think they should stay like updates
20:55:12 <Stormi> MrsB: policy says they should
20:55:17 <MrsB> ok :)
20:55:18 <sander85> if one doesn't work you can downgrade
20:55:43 <leuhmanu> sander85: backport should work
20:55:48 <DavidWHodgins> I don't think that works currently, with rpmdrake
20:55:58 * boklm thinks it can be nice to have previous versions still available
20:56:00 <sander85> leuhmanu: QA will do basic testing ;)
20:56:00 <DavidWHodgins> Doesn't it always select latest version?
20:56:12 <anaselli> and you can't downgrade from an update or am i wrong?
20:56:13 <leuhmanu> DavidWHodgins: in mga2 yes
20:56:16 <leuhmanu> not in mga1
20:56:25 <MrsB> Is it silly to have meta packages for backport packages?
20:56:36 <boklm> MrsB: meta packages ?
20:56:44 <sander85> MrsB: ??!
20:56:50 <AL13N> it sounds silly to me
20:56:51 <MrsB> like task-gimp2.8
20:56:56 <anaselli> like task-kde? :p
20:57:03 <Stormi> task-kde if someone is fool enough to backport it
20:57:06 <boklm> MrsB: what would be the use ?
20:57:17 <MrsB> it would make them easy to install
20:57:17 <anaselli> mikala: LOL :D
20:57:21 <Stormi> task-kde must have strict requires to other KDE components
20:57:30 <Stormi> to pull needed deps
20:57:40 <Stormi> otherwise backports are a pain to install, I remember mdv KDE backports
20:57:47 <MrsB> it might be silly, it's just an idea
20:58:00 <Stormi> policy says "strict requires" so I think this is part of it
20:58:07 <sander85> kde is not a leaf package :)
20:58:15 <andre999> It could be useful for some multipackage game
20:58:17 <boklm> only leaf packages are backported, so I don't think we should have full kde backports
20:58:25 * Stormi thinks he's the only one to read the policy
20:58:27 <anaselli> well if you think to qt... yes :D
20:58:37 * MrsB didn't :\\
20:58:39 <Stormi> policy allows groups of packages tightly linked together
20:58:51 <Stormi> provided we can support, QA them, etc.
20:58:59 <Stormi> so at first let's do only leaf
20:59:04 <sander85> kde is more that just a group :P
20:59:07 <boklm> I don't think it applies to KDE
20:59:15 <andre999> leaf packages or leaf groups of related packages
20:59:15 <anaselli> ii believe we reached an agreement, will be back after
20:59:20 <tmb> but KDE/GNOME/other DE is not allowed for backports
20:59:21 <Stormi> nothing prevents from backporting KDE in policy, as long as quality is there
20:59:29 <Stormi> IIRC
20:59:46 * anaselli was joking talking about kde :)
20:59:46 <Stormi> but it's not realistic with our ressources
20:59:48 <sander85> mikala will prevent it :D
20:59:51 <sander85> by policy :D
20:59:59 <AL13N> ok so
21:00:02 <AL13N> on topic
21:00:06 <AL13N> is this meeting over?
21:00:20 <ennael> wait
21:00:21 <sander85> what about bug 2317?
21:00:24 * AL13N will send email with details regarding implementation details
21:00:31 <AL13N> sander85: afaik it was agreed
21:00:50 <ennael> boklm, tmb : did we list all points on list ?
21:00:52 <AL13N> the email will list the details of what needs to be done, and ask for people who want to do the work
21:00:53 <sander85> how can we help QA out of their misery?
21:00:57 <andre999> sander85: it was agreed before opening backports
21:01:05 <ennael> please
21:01:37 <sander85> it was agreed before backports, but how do we fix it?
21:01:46 <Luigi12_work> tbd
21:01:48 <sander85> or who is going to fix it?
21:01:53 <ennael> boklm, tmb : don't die now !
21:01:56 <leuhmanu> fix what ?
21:02:24 * MrsB hides
21:02:27 <sander85> leuhmanu: fix 2317
21:02:28 <boklm> I don't know if it was decided if bug 2317 should be fixed before opening backports
21:02:28 <tmb> ennael: well, my both questions was answered and agreed on
21:02:30 <andre999> 2317
21:02:54 <AL13N> boklm: well, if QA team states it will not process backports until it's fixed, that sounds like an agreement to me
21:03:05 <DavidWHodgins> bug 2317 must be fixed before qa will validate any backports.
21:03:26 <Luigi12_work> there were no objections
21:03:32 <AL13N> indeed
21:03:46 <boklm> ok
21:03:52 <MrsB> Yay \o/
21:03:53 <ennael> ok so mayve we will backports next year :)
21:03:57 <ennael> have
21:04:01 <DavidWHodgins> Lol
21:04:06 <AL13N> heh, well, i hope it's alot sooner
21:04:08 <ennael> so can we close meeting now ?
21:04:10 <Luigi12_work> yes
21:04:13 <Stormi> ok
21:04:14 <boklm> ok
21:04:16 <AL13N> ennael: i'll send email
21:04:22 <AL13N> regarding details to be implemented
21:04:25 <andre999> we should tag each backport file name as backport
21:04:26 <AL13N> and ask for resources
21:04:30 <ennael> oh and the guy who will mail again about backport on -dev will be burnt
21:04:36 <AL13N> oops
21:04:40 <AL13N> er
21:04:41 <ennael> :)
21:04:44 <AL13N> does this count?
21:04:47 <Luigi12_work> ennael has the matches ready
21:04:51 <Stormi> or reply to mails about backports :)
21:04:53 <sander85> hmm, but 2317 - what is the solution?
21:04:59 <Luigi12_work> sander85: tbd
21:05:00 <ennael> thanks guys
21:05:06 <ennael> #endmeeting