19:07:33 <ennael> #startmeeting
19:07:33 <Inigo_Montoya`> Meeting started Wed Aug 24 19:07:33 2011 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:07:33 <Inigo_Montoya`> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:07:33 <erzulie> [ MeetBot - Debian Wiki ]
19:08:07 <ennael> #chair misc
19:08:07 <Inigo_Montoya`> Current chairs: ennael misc
19:08:15 <ennael> hi all
19:08:19 <rindolf> ennael: hi.
19:08:35 <DavidWHodgins> Hi all.  Can we resolve whether added requires on an update should be copied to updates testing, or mgaapplet changed to use auto-update
19:09:15 <shadow95> ennael: Hi
19:09:27 <ennael> DavidWHodgins: can we add it at the end?
19:09:34 <DavidWHodgins> Sure.
19:09:38 <ennael> ok :)
19:09:52 <ennael> so back on meetings after vacations
19:10:17 <ennael> hope you had all some rest as we have a huuuuuuuge todo list :)
19:10:59 <ennael> (ok now they are all dead :) )
19:11:17 <ennael> #topic Backports policy to be finalized
19:11:28 <ennael> let start with a burning topic
19:11:43 <spturtle> is there a proposal on the wiki?
19:12:07 <ennael> not really as lots of discussions happened on ML
19:12:20 <ennael> we took some time on our side with misc to read again all this
19:12:55 <spturtle> so any new ideas?
19:13:02 <ennael> not really
19:13:23 <ennael> whatever the decision is it will not satisfy everyone
19:14:36 <ennael> so
19:14:49 <ennael> we have on one side what we would like to do
19:15:02 <ennael> compared to on the other side our ressources
19:15:34 <ennael> besides this, either we go on proposing backports as "packages you install at your own risks"
19:15:51 <ennael> or we propose something officially maintained following official policy
19:16:24 <ennael> the thing is for now Mageia needs to show it's a solid distro that people can rely on
19:16:54 <ennael> so we really think backports should be seen as non risky packages otherwise it's a mess
19:17:21 <ennael> on ressources side as we have already spoken about, we do have already a huge todo list
19:17:33 <ennael> we will speak later about security updates and triage
19:17:37 <Remmy> But following that reasoning, one might ask what the difference is between backports and updates?
19:18:03 <ennael> updates: you do change version just bug fixes and security
19:18:08 <ennael> backports are new versions
19:18:25 <ennael> everybody does not want to have the brand new version
19:18:32 <dlucio_android> isnt it possible to place "secure" backports in update repo? and "self risk" in backport repo?
19:18:43 <ennael> outch
19:18:58 <spturtle> dlucio_android: not an issue! some updates will be version updates regardless
19:19:01 <ennael> meaning you have several versions for one package in same depo ?
19:19:29 <ennael> so besides all this, as you know we are late in security updates and triage as said before
19:19:48 <ennael> and we have a nice list of packages without any maintainer
19:19:49 <Remmy> I've seen several requests for newer version being filed in bugzilla but am unclear if they are "wait for mga2" or "new package request for backports"
19:20:19 <ennael> so what we do propose for now is a reasonable solution
19:20:50 <ennael> meaning we focus backports on packages that do not have dependancies
19:21:03 <ennael> basically what misc started to explain sooner
19:21:13 <ennael> we do work like this in coming 6 months
19:21:31 <andre999> good idea
19:21:36 <ennael> then we can have a review on all this and see how it goes about ressources
19:22:07 <ennael> and maybe think again about backports policy
19:22:14 <leuhmanu> is package missing also a backport ?
19:22:20 <ennael> ?
19:22:38 <andre999> not if in mdv 2010.1
19:22:52 <ennael> oh ok :)
19:22:52 <leuhmanu> if the rpm is in cauldron but not mageia 1
19:23:04 <spturtle> so procedure is: a) check that the package is not used by other packages in release/updates  and b) just upload to backports
19:23:18 <ennael> yep
19:23:31 <ennael> so we have a reasonable scope for backports
19:23:42 <ennael> and we can also improve rest of todo list
19:23:55 <spturtle> but also add in svn I guess? forgot about that one
19:23:57 <ennael> kind of half/half proposal
19:23:57 <DavidWHodgins> Will it go directly to backports, or to backports testing?
19:24:16 <ennael> DavidWHodgins: I would suggest testing first
19:24:35 <ennael> as part of quality policy for backports
19:24:36 <dlucio_android> just wonderig if someone can do a procedure to know if a package is candidate for backporting, maybe a urpmq command
19:24:40 <Remmy> So, for thunderbird and firefox, new releases go to backports as long as the current one still receives security updates, but a new release will go into updates once support for the older version has stopped and a new release fixing security things is released?
19:24:50 <ennael> dlucio_android: why not yes
19:25:36 <ennael> Remmy: unfortunatelly yes FF has such a specific release policy now...
19:26:05 <spturtle> Remmy: I think such specific questions cannot be answered from a generic policy, this up to the firefox maintainer(s) and updates team (which doesn't really exist)
19:26:16 <andre999> all mozilla = ff tb + seamonkey
19:26:49 * spturtle hides behind the iceape
19:26:54 <AL13N> ok, i agree
19:27:03 <ennael> back to proposal, does it look ok ?
19:27:16 <andre999> yes :)
19:27:21 <AL13N> is there anything that needs to be done on BS or svn to make it work?
19:27:25 <AL13N> ie: where to commit from?
19:27:26 <Remmy> So, in practise this would mean that libs and such don't go to backports, but stand alone apps do. Sounds good to me.
19:27:47 <ennael> yep
19:28:01 <ennael> so what we need now is to write this down in wiki
19:28:09 <ennael> and make it official
19:28:37 <ennael> maybe a blog post to explain it as part of quality policy for Mageia
19:29:19 <andre999> with a clause that exceptions that go to updates to be decided by updates team
19:29:28 <ennael> yep
19:29:33 <ennael> secteam will decide this
19:29:41 <AL13N> oh Q!
19:29:42 <andre999> I could do that :)
19:29:50 <AL13N> do the backports also need an Announce text?
19:29:57 <AL13N> ie: for rpmdrake?
19:30:01 <ennael> ?
19:30:12 <AL13N> like updates do
19:30:30 <ennael> sorry I don't understand
19:30:34 <andre999> like "this package is officially supported" ?
19:30:38 <AL13N> no
19:30:54 <AL13N> for updates, policy says, we need to provide an announce text
19:31:01 <AL13N> to be used in descriptions
19:31:19 <AL13N> for rpmdrake: like: "this update fixes blablabla..."
19:31:45 <AL13N> since it's a backport i would think this sort of text is not needed... but i don't know, since we have qatesting now
19:31:55 <andre999> well backports won't be fixing anything, necessarily
19:32:05 <leuhmanu> advisory ?
19:32:09 <AL13N> ah yes
19:32:10 <ennael> ah
19:32:17 <ennael> don't think so
19:32:20 <AL13N> sorry i was not clear enough
19:32:30 <Remmy> I think the changelog is enough
19:32:38 <AL13N> k, just checking
19:33:18 <spturtle> a backport will fix *something* or it won't be uploaded (:
19:33:28 <AL13N> btw: do we need a backports svn tree? or do we submit from cauldron?
19:33:29 <ennael> ?
19:33:50 <ennael> so
19:34:12 <ennael> #action announce final backport policy on ML and blog and explain our choice
19:34:39 <ennael> #action finalize backport policy in wiki and explain scope
19:34:51 <spturtle> it would be nice to have a list of backports on the website, but not really needed
19:34:59 <ennael> a list ?
19:35:15 <spturtle> maybe Stormi has that already?
19:35:34 <andre999> rpmdrake gives a list
19:35:43 <andre999> (sort by repo)
19:35:56 <spturtle> well let's not wast time on this, sorry to bring it up
19:36:16 <ennael> no pb we can speak about this on ML
19:36:23 <ennael> anything to add on this ?
19:37:44 <rindolf> ennael: guess not.
19:37:54 <ennael> ok
19:38:18 <ennael> #topic Packagers charter to improve organization
19:38:29 <ennael> is charter clear enough for everyone ?
19:38:38 <rindolf> ennael: where is the charter?
19:38:48 <ennael> ?
19:39:06 <rindolf> ennael: where can I find it?
19:39:23 <ennael> it does not exist yet
19:39:29 <rindolf> ennael: ah, OK.
19:39:42 <andre999> the word "charter" is good
19:39:52 <ennael> we have a code of conduct for general behaviour in Mageia
19:40:42 <ennael> but regarding what we saw in Mandriva and what we see also in Mageia, we have to manage some conflicts (maybe not that strong but it can be) between packagers
19:41:07 <ennael> especially about people committing/submitting on a package already maintained
19:41:18 <ennael> don't know if I'm clear enough
19:41:23 <AL13N> funda?
19:41:25 <rindolf> ennael: were there any clashes so far?
19:41:36 <ennael> AL13N: no need to give some names here
19:41:42 <ennael> that is not the point
19:41:49 <ennael> rindolf: we have some indeed
19:41:52 <andre999> there have been a few clashes
19:41:54 <bkor> ennael: shouldn't a new version update be ok? (e.g. 1.2.3 -> 1.2.4)
19:42:13 <ennael> ?
19:42:30 * spturtle adjusts bkor's time machine
19:42:31 <bkor> you said people committing on a package already maintained
19:42:35 <Remmy> I think if a package has a maintainer, then a patch should be sent to the maintainer instead of committed directly. If the maintainer doesn't respond in x days, one can go ahead and commit it
19:42:58 <AL13N> i agree
19:43:09 <andre999> sounds good
19:43:10 <Remmy> And security team can always do a new package without waiting for x days.
19:43:10 <ennael> I would like to hear also packagers :)
19:43:18 <grenoya> good for me
19:43:30 <shadow95> good for me too
19:43:39 <misc> hi
19:43:43 <ennael> patch or a mail proposing to do the work for packager
19:43:49 <ennael> if he is ok
19:43:52 <bkor> spturtle: not talking about backports
19:44:00 <misc> well, what if a packager is in vacation ?
19:44:08 <dlucio_android> ot maybe let them commit, but dont submit
19:44:18 <spturtle> Remmy: that will only work (more or less) when we support maintainer groups (multiple maintainers for each package)
19:44:19 <andre999> ennael: that is good too
19:44:32 <ennael> dlucio_android: pb is when commits are done without even pinging maintainer
19:44:39 <Remmy> misc: We will forbid that :)
19:44:43 <AL13N> misc: how long are packagers in vacation? if it's too long, how can we tell the difference, i mean, if it's a fix, we shouldn't wait too long
19:45:17 <dlucio_android> annael, i mean if its possible to ban submit for non-maintainers
19:45:18 <andre999> misc: if on vacation, and packager notifies list, maybe commits on hold for his packages ?
19:45:34 <AL13N> maybe if the maintainer does not react, it could need a second opinion?
19:45:34 <ennael> we spoke with misc about it
19:45:43 <ennael> our point is to avoid repression :)
19:45:47 <dlucio_android> and when a commit posted, an email to maintainer should be delivered
19:45:49 <AL13N> like any other packager to agree
19:45:55 <misc> well, what I propose is that every people who has idea decide of a date, and make a common proposal
19:46:03 <bkor> what about when you notice that e.g. gnome-shell is updated to a newer micro version? could you as a packager just update the cauldron one? or always wait for the maintainer?
19:46:27 <spturtle> ennael: the trouble with not talking about specific cases (good) is that we don't really know what you want to fix ):
19:46:37 <misc> bkor: in fact, that depend on the maintainer some do not care about their package be updated ( for example, i do not care at all )
19:46:57 <spturtle> bkor: IMHO if you do any version update you tell everyone you are co-maintainer of that package
19:46:58 <Remmy> misc: I guess it is different when you have 5 packages instead of 500
19:47:02 <AL13N> if there are multiple maintainer, it could be done like this
19:47:25 <Remmy> Is it possible to have more than one maintainer per package?
19:47:34 <AL13N> not yet
19:47:37 <ennael> we have some "teams"
19:47:51 <ennael> for example KDE even if it's not group as maintainer
19:48:14 <spturtle> ennael: that's something else
19:48:18 <AL13N> i mean, if maintainer does not care about updates, than the other person who wants to, could become maintainer, thus solving the issue
19:48:27 <dlucio_android> ennael: is it possible to change some policy, in order to state that if you claim for mainteinership, you shall be available somehow?
19:48:46 <andre999> we need multiple maintainers
19:48:53 <bkor> I'm interested in helping out with keeping the GNOME packages up to date, but just to help out with the boring work.. so not a Mageia packager atm
19:49:18 <AL13N> bkor: join the gnome team?
19:49:29 <ennael> spturtle: no it's not
19:49:37 <misc> dlucio_android: so you would be volunteer to answer to answer on what delay ?
19:49:43 <ennael> as group maintainance is just not implemented yet
19:49:49 <bkor> AL13N: if it is ok that I'd never do more than just basic version upgrades, then I'd like to join
19:50:10 <dlucio_android> 2-3 is a rasonable delay misc
19:50:23 <ennael> bkor: so you could be part of a kind of GNOME team
19:50:26 <AL13N> bkor: imho basic version upgrades is still packaging, but likely you could be an eternal novice packager :-)
19:50:52 <misc> dlucio_android: 2-3h, that sound good indeed
19:50:59 <AL13N> lol
19:51:05 <andre999> :)
19:51:07 <Remmy> Wild idea, also to help with triaging... what if we have package@packages.mageia.org that goes to the maintainer(s) if set, or the last committer if no maintainer. And a db showing who are in those groups?
19:51:12 <AL13N> maybe if you go on vacation, you can find a replacement?
19:51:36 <misc> anyway, the meeting is not here to brainstorm, who is volunteer to collect idea ?
19:51:43 <andre999> maybe 2-3 days, but 2wks extra if notify of vacation
19:51:58 <ennael> meaning what we should expect from a packager
19:52:09 <ennael> and what if some other are not following baisc line
19:52:11 <ennael> basic
19:52:18 <dlucio_android> brb
19:52:20 <andre999> I would, but my last collect of info was totally ignored
19:52:23 <ennael> (hoping it will not happen too often)
19:52:24 <Remmy> I think being the maintainer of a package gives one both rights and obligations
19:52:37 <ennael> Remmy: that's the point here
19:52:44 <misc> andre999: ?
19:52:51 <Remmy> I like to state the obvious :)
19:52:55 <ennael> but as we don't want to spend hours un meeting we can list this after
19:52:57 <ennael> :)
19:53:08 <ennael> s/un/in/
19:53:41 <andre999> misc: delay before other's can commit
19:53:56 <misc> andre999: no, the last collect of info
19:54:13 <Remmy> andre999: I think misc is asking about the "my last collect of info was totally ignored" part
19:54:24 <Remmy> (sorry)
19:54:25 <andre999> misc: about how to determine ressources
19:55:01 <andre999> misc: actually one response saying we didn't have enough
19:55:20 <misc> andre999: mhh, i tought we missed the answer
19:55:34 <misc> andre999: but this time, you see that everybody has something to say :)
19:55:50 <andre999> true - big change :)
19:56:16 <AL13N> andre999: if you ask on ML, i will promise to respond
19:56:33 <andre999> ok - will do it again
19:56:34 <AL13N> andre999: (be careful what you wish for)
19:59:05 <misc> ok so something to add ?
19:59:31 <andre999> so should we review this next meeting ?
19:59:44 <Remmy> Let's discuss on ML and decide next meeting
19:59:52 <misc> better, yes
19:59:57 <shadow95> sound good
20:01:22 <dlucio> back
20:01:23 <misc> #agreed discuss of the topic on ml and see next week for progress
20:01:33 <misc> so next topic ?
20:01:40 <AL13N> k
20:02:03 <andre999> ok
20:02:09 <misc> ennael: ?
20:02:13 <ennael> yep
20:02:24 <ennael> #topic mentoring review
20:02:31 <ennael> andre999: your turn :)
20:02:32 <dlucio> i will write in ML my poposal
20:02:55 <andre999> there is one person in the apprentice in waiting list
20:03:13 <andre999> I emailed him to see if he still needed a mentor, no response
20:03:28 <andre999> so I imagine he is on vacation
20:03:30 <dlucio> andre, remember me? jejej :P
20:03:45 <andre999> yes :)
20:04:21 <andre999> since so many packagers have been on vacation, I put looking for nes apprentices on hold
20:04:34 <Remmy> Looks like he has a useful skillset
20:04:50 <andre999> time to search new apprentices now
20:05:17 <ennael> sure
20:05:26 <andre999> I modified the mentoring + apprentices table to accommodate move to mediawiki
20:05:38 <Remmy> andre999: Would it be useful to contact the old "interested" people and see if they still want to help out and be mentored?
20:06:10 <andre999> good idea - I thought of that - will do
20:06:38 <misc> well, I am slightly concerned by the fact that I do not see that much apprentices become maintainer :/
20:06:48 <dlucio> andree999: i've 1 padawan but he is too bussy for taking classes so virtually i'm free
20:08:03 <andre999> also I added a section at the end of the wiki for our new wiki (I forget the name) - a guide for conversion to mediawiki
20:08:30 <andre999> web:wiki
20:08:38 * AL13N is the eternal padawan ... or so it seems
20:08:45 <andre999> a documentation of the changes
20:09:01 <grenoya> maybe we should move up the mentoring part on the packager page, so that newbi don't see the big packager table before
20:09:30 <grenoya> because some have filled the big table and not run into the mentoring process
20:09:37 <andre999> misc: on that note, I should become maintainer soon
20:09:55 <Remmy> misc: Aye... but I feel a lot of that is still the result of few mentors being available till July... that probably didn't help the ones who were interested much
20:09:58 <andre999> (so easy to be distracted by other things)
20:11:09 <andre999> grenoya: maybe a conspicuous link at the beginning of the packager page
20:11:11 <Remmy> And that is not just for packaging... there were so many people enthused last year when Mageia was launched, and not that many 'new' people still with us now.
20:11:29 <grenoya> andre999: not just a link
20:12:09 <andre999> I had an idea - link the wiki pages to a database for the tables, so that the info is only entered once
20:12:15 <grenoya> we said to pepoel : do subscrib on the wiki, they find a big table, they put their name but not read every thing
20:12:32 <andre999> that is, all info entered in the main packager table
20:12:52 <Remmy> I think it's a good idea to actively approach the MIA people from that page
20:13:00 <Remmy> even if only 10% respond, that's still something
20:13:11 <andre999> for waiting to be apprentice table, enter only pseudo + comment -- other info pops up from data base
20:13:12 <Remmy> And those who don't respond, take them off
20:13:23 <andre999> same thing for mentoring table
20:14:07 <andre999> Remmy: I've also thought of going through packager table for apprentices
20:14:30 <andre999> I've loaded that table on my computer (in spreadsheet)
20:14:39 <grenoya> andre999: your proposition seems to my a big work of implementation
20:15:03 <andre999> misc: in would be useful if I had a list of all official packagers
20:15:13 <misc> andre999: well, I can give the pseudo
20:15:26 <misc> andre999: but privacy policy say that we do not disclose email to 3rd party
20:15:28 <andre999> perfect :)
20:15:37 <andre999> all I need :)
20:16:30 <misc> technically, i think you can get it if you are packager, using a ldap client
20:16:59 <misc> #action misc send list of packagers login to andre999
20:17:05 <Remmy> I don't get enough spam, only from badoo.
20:17:14 <andre999> grenoya: don't know how much work, but it would (a) makes maintaining tables  easier (b) makes it easier for people to enter data
20:17:36 <andre999> misc: another reason to become official packager :)
20:18:31 <ennael> ok anything else to add ?
20:18:47 <andre999> that's about all -- any questions ?
20:19:21 <ennael> ok they are dead, let switch :)
20:19:26 <ennael> #topic Triage team proposals
20:19:29 <andre999> ok :)
20:19:38 <ennael> ok
20:20:01 <ennael> as you may have seen leuhmanu mailed -dev about proposals to improve triage work in Mageia
20:20:28 <ennael> he kindly accepted to start triage team management to organize work
20:20:36 <ennael> and be representative for council meetings
20:20:45 <ennael> many thanks to him
20:20:53 <ennael> he will be helped in this by Remmy
20:21:12 <ennael> triage is another biiiiiig task but essential for Mageia
20:21:31 <ennael> so triage team will be part of packagers meetings
20:22:00 <ennael> we plan to communicate on triage work as something as important as packaging for a distro
20:22:34 <ennael> leuhmanu: can you just summarize proposals and what you have in mind ?
20:24:31 <leuhmanu> yes sorry
20:24:31 <sander85> we still need some database to connect maintainers with bugzilla accounts, so bugs could be assigned to maintainers.. currently i may see a bug and i even know who is the maintainer by nick, but i can't assign it as i don't know bugzilla's user
20:25:13 <ennael> I asked dmorgan about this
20:25:19 <ennael> he may have a look in coming days
20:25:25 <ennael> as he setup bugzilla at start
20:25:42 <misc> well, the problem is the same, if we say we don't disclose email to 3rd partie, then we should not
20:26:02 <misc> now, I think we could have some kind of script to add people in cc of bug, based on maintainer db
20:26:13 <misc> no need to ask to people to do by hand what could be done by a script
20:26:13 <Remmy> sander85: Agreed. Though, trying to assign something to a nick or a partial email address often does result in bugzilla offering the right solution
20:26:15 <ennael> yep
20:26:31 <andre999> I thought bugzilla used Mageia identity ?
20:26:39 <leuhmanu> for some id it's work
20:26:50 <misc> andre999: it does, but I am not sure if it doesn't use email internally
20:26:53 <ennael> dlucio: can you send your mail to -dev ?
20:27:07 <andre999> ok I understand now
20:27:18 <misc> but if it was as simple as saying "bug assigned to foo", it would have been tested, no ?
20:27:35 <sander85> which brings me to next question, do all packagers have account at bugzilla at all?
20:27:52 <leuhmanu> sander85: normally yes
20:27:59 <misc> sander85: they should, as they are in cc of the bug to open their account :)
20:28:11 <sander85> ok
20:28:21 <misc> ( but autocreation of acount could also be scripted, I gave a try to it before osing harddrive)
20:28:56 <ennael> maintainer account without bugzilla one is just non sense omho
20:28:58 <ennael> imho
20:30:19 <Remmy> I like most of the suggestions made on the list. Perhaps a regular email to -dev on bug status and the Junior jobs will help.
20:30:20 <leuhmanu> there're a few months I added a person who had an account Identy but had never been on the bugzilla
20:30:43 <andre999> ennael: agree totally - it should be integrated
20:31:00 <Remmy> And the bug week or day idea is good too if we announce it well in advance and get both bugsquad members, qa, and devs in on it
20:31:14 <ennael> yep
20:31:42 <misc> leuhmanu: who ?
20:31:58 <leuhmanu> ofaurax
20:32:05 <DavidWHodgins> I have to go.  I'll bring up the topic of mgaapplet and updates with new requires on the ml later. bye.
20:32:08 <leuhmanu> (add on cc)
20:32:48 <misc> leuhmanu: but he is not a maintainer :)
20:32:59 <misc> ( but yes, we could also sync ldap -> bugzilla )
20:33:31 <Remmy> Are there any objections to more aggressive assigning of bugs to last committers? I was happy to see that most of the responses were positive towards the idea.
20:33:34 <leuhmanu> but maintainer are also user no ?
20:34:33 <bkor> Remmy: only thing to watch out for that it should be known that multiple people can fix the bug
20:34:33 <leuhmanu> Remmy: for cauldron bug that is easier yes :)
20:34:44 <bkor> so not just the assignee in bugzilla
20:35:23 <leuhmanu> that why propose some groups
20:35:29 <leuhmanu> + I
20:35:34 <Remmy> bkor: Ya, I want to see less "bugsquad"  as assignee. In case of doubt, we can also Cc some others on the reports.
20:35:37 <misc> Remmy: go for it
20:35:44 <AL13N> maybe check mgarepo log for last committers and add all on CC?
20:36:21 <andre999> sending alerts to potential fixers before assigning ?
20:36:46 <bkor> and for assignee, I'd ideally would see $PACKAGE@mageia.bugs dummy accounts as assignees; then syncing maintainers db with being cc'ed on those dummy bugzilla accounts
20:36:47 <andre999> of course, add on CC
20:37:20 <andre999> bkor: good idea
20:37:22 <spturtle> bkor: assignee should always be a person IMHO, so someone's responsible for the bug
20:37:41 <spturtle> otherwise "someone else will take care of that bug"
20:37:52 <sander85> yeah, somewhat true..
20:37:53 <bkor> spturtle: works 2 ways
20:38:17 <bkor> if you see someone as assignee, I/various wouldn't touch the bug, because there is an assignee
20:38:20 <AL13N> spturtle: but if we ever get multiple maintainers, that could be usefull
20:38:24 <Remmy> Well, if a group does nothing or a person does nothing... does that make a big difference?  With a group, people might be thinking "someone else will fix it", on the other hand, a group also means more people will get to see the bug.
20:38:32 <bkor> if there is a dummy one, it seems ok to take it
20:38:36 <andre999> true - better assigned to a real person
20:38:47 <misc> bkor: the problem is to create the account in bugzilla automatically
20:38:49 <spturtle> it is easy to add a group as CC so they see the bug
20:39:02 <AL13N> spturtle: that's a good iea
20:39:05 <andre999> CC will accomplish the same thing - potential fixers notified
20:39:27 <misc> ( and the problem is the obscurity , we do not know who is in charge of the bug too )
20:39:28 <AL13N> maybe no assigning to other people then? and the dev has to assign himself isntead?
20:39:45 <AL13N> if he takes it, at least he's in charge of it?
20:40:08 <spturtle> are we talking about maintdb vs bugzilla?
20:40:21 <AL13N> i thought we're talking about bugzilla
20:40:48 <andre999> AL13N: that way, if it is assigned, the person has (in theory) accepted and is working on it
20:41:01 <spturtle> well if there's a reasonable candidate for assigning the bug to, better do it
20:41:45 <spturtle> that person can re-assign it if he/she doesn't want to own that bug
20:41:49 <Remmy> I think we should assign where we can... hoping no one gets upset at being assigned a bug they feel is not theirs, but then they can just put it back to bugsquad
20:41:51 <andre999> but what happens if we assign it to a "reasonable candidate" who ignores it ?
20:42:14 <AL13N> Remmy: what if that person is on vacation for 2 months
20:42:18 <AL13N> it's assigned...
20:42:19 <misc> andre999: then, he ignore
20:42:22 <andre999> exactly
20:42:31 <misc> andre999: the bug is not fixed, that's bad, but we cannot fix everything
20:42:36 <Remmy> andre999: I created a "stale bug search" in bugzilla for bugs older than 90 days with no action
20:42:48 <bkor> maybe status? NEW=ok to reassign, ASSI=don't reassign
20:42:54 <andre999> misc: true, I'm thinking of more urgent bugs
20:43:16 <andre999> for most bugs that's probably ok
20:43:16 <AL13N> if they are urgent chances are higher that other people jump on it?
20:43:30 <Stormi> hi, sorry for not being able to attend
20:43:36 <andre999> hopefully - but not garanteed
20:43:47 <andre999> welcome :)
20:44:01 <Remmy> I think here too we can assume a "post if you have a fix / work on it" thing and "go ahead if no response from assignee in x days"
20:44:28 <andre999> we could ask for confirmation on assignment
20:44:32 <misc> andre999: in fact, it could be worst, what if no one find a solution
20:44:46 <Remmy> People who go on vacation for 2 months... well, they shouldn't :)    If you can afford to take that long off, you can afford to hire someone to look after your bugs ;-)
20:44:59 <andre999> if a person doesn't assign it to him/her self
20:45:41 <andre999> misc: it would be nice to have a magic wand :)
20:45:41 <misc> Remmy: and for people busy ?
20:46:03 <Remmy> misc: We'll give you some slack :)
20:46:46 <Remmy> I think bugsquad team can monitor overall follow ups on bug reports and ping and prod where needed.
20:46:52 <andre999> I think that confirmation in x days if bug assigned by someone else
20:47:20 <leuhmanu> an extension can maybe do that
20:47:27 <andre999> then flagged as no response but remains assigned for another x days
20:47:39 <andre999> then unassigned
20:48:12 <AL13N> less than 15min left, is there other topic?
20:48:13 <andre999> (reassigned to bugsquad)
20:48:30 <AL13N> (ie: secteam review?)
20:49:09 <ennael> somebody to summarize this for -dev ML ?
20:50:36 <Remmy> leuhmanu: Shall we take that upon us?
20:51:15 <leuhmanu> yep
20:51:23 <ennael> ok
20:51:42 <ennael> about secteam, looks like stewb is not around
20:52:44 <AL13N> ok, i think someone asked about mgaaplet vs copy-to-updates ?
20:52:57 <andre999> he had to leave
20:53:19 <andre999> (he's in Canada too)
20:56:04 <misc> so next topic ?
20:56:18 <shadow95> ok
20:57:42 <misc> I think it was the last topic
20:57:50 <ennael> yep
20:58:03 <misc> regarding the mgaapplet vs copy-to-update ?
20:58:19 <andre999> he had to leave
20:58:59 <misc> yes, but we know the problem too :)
20:59:05 <andre999> he said he would discuss on ml
20:59:19 <andre999> (he's at utc-5 like me)
20:59:41 <misc> well, we already discussed
20:59:42 <AL13N> personally i'm against copy-to-updates
21:00:15 <leuhmanu> this bug https://bugs.mageia.org/show_bug.cgi?id=2317 ?
21:00:16 <AL13N> but the real fix is quite hard, so...
21:00:16 <erzulie> [ Bug 2317 - --update option should behave like --search-media <list of the update media> ]
21:03:20 <misc> leuhmanu: yes
21:07:08 * misc notice th mail was sent to -sysadm without mention of the already opened bug
21:09:21 <AL13N> so, no solution?
21:09:28 <AL13N> or will we talk about this later?
21:09:53 <andre999> I have to think about it before any feedback
21:09:58 <AL13N> if not, then maybe endmeeting?
21:10:43 <misc> ennael: ?
21:10:51 <andre999> ok
21:11:09 <ennael> yep already quite late
21:11:40 <andre999> only 17h here :)
21:11:53 <rindolf> It's 00:11 here.
21:11:58 <misc> ok so thanks for coming
21:12:02 <misc> see you next time
21:12:05 <misc> #endmeeting