19:37:49 <ennael> #startmeeting
19:37:49 <Inigo_Montoya> Meeting started Wed Dec  1 19:37:49 2010 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:37:49 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:37:54 <ennael> thanks misc
19:37:59 <ennael> as you may have seen some mageia teams are already starting
19:38:04 <ennael> at least creating ML, check who is still around
19:38:19 <ennael> and try to start with internal organization, policies...
19:38:21 <misc> #meetingname Packagers
19:38:21 <Inigo_Montoya> The meeting name has been set to 'packagers'
19:38:42 <ennael> ahmad78 will manage triage one and dams for QA
19:38:49 <ennael> so we have to start with packagers
19:39:28 <ennael> I listed some topics we have to think about before starting
19:39:47 <ennael> if you want to add some just feel free
19:39:57 <ahmad78> (I didn't even know there was a meeting)
19:40:07 <ennael> are you in founders ML ?
19:40:28 <misc> s/ml/alias/
19:40:30 <misc> and no
19:40:33 <ennael> arf
19:40:41 <ennael> ahmad78
19:40:44 <ennael> sorry ahmad78
19:40:47 <ahmad78> np
19:40:48 <ahmad78> go on
19:40:54 <ennael> #topic Integration of packagers (who should have full packager account to start with)
19:41:11 <ennael> misc underlined this point as we were speaking yesterday
19:41:27 <ennael> so we have to decide about kind of policy to start with list available on wiki
19:42:10 <ennael> we have old mdv maintainers
19:42:18 <ennael> some from blogdrake
19:42:24 <ennael> some very new one
19:42:32 <ennael> some trainee from mdv...
19:42:54 <misc> some from various projects similar to mandrake too
19:43:00 <ennael> yep
19:43:05 <ahmad78> anyone who wasn't a packager in mdv will need mentoring (varying degrees depending on how much experience each one has)
19:43:21 <ahmad78> some will just need to get familiar with the tools and the BS
19:43:33 <misc> yup
19:44:00 <ennael> t_m_b: any comment on that ?
19:44:23 <t_m_b> nope, I agree with ahmad78
19:44:26 <ennael> misc: it means we will have to mentor lots of people at first
19:44:26 <Anssi> me too
19:44:33 <misc> ennael: yup
19:44:44 <misc> this mean that we will need lot of mentor :)
19:44:59 <misc> we can say "people who have a account have to mentor someone" ?
19:45:43 <ennael> so just need to extract names from wiki list
19:45:44 <ahmad78> (can I give up my account now and be triage only for say two months?)
19:46:16 <ennael> ahmad78: no need to give up if you have one
19:46:27 <ennael> your focus is on triage as it's starting
19:46:32 <ennael> is that is ?
19:46:36 <ennael> it
19:46:42 <misc> ennael: well, i think he want to avoid being a mentor :)
19:46:42 <boklm> misc: maybe some people don't want to do mentoring, or are too busy at the moment
19:46:43 <ahmad78> ennael: no, just I dread mentoring anyone
19:46:56 <ennael> ah :)
19:47:02 * misc note that ennael also has a packaging account /o\
19:47:09 <ahmad78> I think "group" mentoring would be good
19:47:15 <ennael> misc: I can't hear you :)
19:47:23 <ennael> ahmad78: group ?
19:47:30 <misc> session of 3 people
19:47:55 <ahmad78> divide them up based on "brand new", "knows how to package a bit", "expert just needs to know his way around the tools, BS, spec style"
19:48:01 <ahmad78> misc: yes
19:48:40 <ennael> maybe we could write down kind of training program to check everything is done
19:48:41 <misc> mhh, yes,
19:48:49 <misc> ennael: ie ?
19:49:28 <ennael> kind of list of things to be learnt by new packager
19:49:37 <ennael> or maybe we have it already on mdv wiki
19:49:49 <boklm> maybe we can add mentor name in ldap account, and send all his commits to his mentor
19:50:07 <misc> yup, that would be a good idea
19:50:13 <ennael> just trying to make life easier for mentors
19:50:20 <ahmad78> boklm: you mean s/mentor/apprentice/ ?
19:50:24 <misc> ennael: dr_st may have such document
19:50:35 <ennael> misc: I can check
19:50:46 <ahmad78> (I mean s///, not s///g :)
19:50:47 <boklm> ahmad78: send apprentice's commits to his mentor
19:51:57 <ennael> #info anyone who wasn't a packager in mdv will need mentoring (varying degrees depending on how much experience each one has)
19:52:15 <ennael> #action extract mdv maintainers in wiki list to propose being mentor
19:52:24 <ennael> (except ahmad78 :) )
19:52:28 <misc> ( and ennael )
19:52:33 <ennael> bah
19:52:59 <ennael> #action setup group mentoring (to be defined -see with Dr ST)
19:53:23 <ennael> #action send apprentice's commits to his mentor
19:53:45 <misc> if we start to do different training to different people, how should we handle priority ?
19:53:56 <ennael> what if some packagers are coming from other projects say "we are experienced packagers" N
19:53:59 <ennael> ?
19:54:20 <misc> i guess we can count them as "people who need to have minimal training"
19:54:23 <ennael> misc: use priority as explained in RPMs import order ?
19:54:36 <ennael> misc: ok just we will have such comment
19:55:21 <dmorgan> ennael: i think they have to be mentored too, if the mentor think they are OK so the training part will be shorter
19:55:23 <misc> ennael: no, should we start to train people who need minimal work, or those that requires more work ?
19:55:44 <misc> I would favor the one that can be operational quite fast
19:55:48 <ennael> that's an idea indeed
19:56:28 <t_m_b> minimal work needed first, to spread the workload... they can even start mentoring at some point...
19:56:56 <ennael> #action focus mentoring on people who need minimal training
19:57:09 <misc> now, a real good question is : what for people who will be in 6 months say "I a a ex mandriva packager, I did not see the wiki"
19:57:11 <ennael> ok this has to be define as we don't know everybody
19:57:49 <Anssi> for a second I thought of a help mailinglist for newbie packaging questions, but that might be too excessive
19:58:10 <misc> Anssi: we had that at AUFML, this worked well
19:58:20 <misc> and I think that could be a good idea, yes
19:58:31 <ennael> so mentors should at least register to it
19:58:46 <ennael> or is it different process ?
19:58:57 <boklm> maybe we should check that people have minial knowledge of rpm before giving apprentice accounts
19:59:29 <misc> boklm: ie requires them to at least send 1 patch or take 1 package ?
19:59:39 <boklm> misc: yes
19:59:44 <t_m_b> with an ml we would get a "shared mentoring" too if some mentor is unreachable at some times
19:59:48 <Anssi> misc: but I wonder if it is needed.. apprentices will have mentors anyway, and they can just ask them instead..
19:59:57 <Anssi> but t_m_b's point is good
20:00:11 <ennael> yep
20:00:39 <maat|alt> boing
20:00:41 <ennael> #action create ML for beginners packagers to help them
20:00:43 <rtp> with archive, they may even find an answer to their question before asking :)
20:01:36 <ennael> ok
20:01:52 <ennael> about ML what do we need?
20:02:01 <ennael> kind of maintainers@ one ?
20:02:12 <ennael> or -dev is enough
20:02:14 <boklm> I don't know if we need a maintainers one
20:02:44 <misc> well, what would be the topic we will discuss ?
20:02:45 <dmorgan> we can test with only -dev and see if this is enough
20:02:59 <dmorgan> after some thinking, for me -dev is enough too
20:03:02 <misc> I would be more in favor of doing topic related ml ( ie, one for kde, one for gnome, etc )
20:03:03 <ennael> misc: packaging pb, policies, upgrade pb...
20:03:37 <Anssi> ennael: those belong to -dev I think
20:03:39 <ennael> misc: it's not always that separated
20:04:03 <misc> ennael: indeed, and quite often, it is not :)
20:04:10 <dmorgan> misc: for the begining i think this is just "too much"
20:04:21 <ennael> so ok for using mageia-dev?
20:04:25 <misc> ok to use it
20:04:32 <Anssi> a separate ml would be for admin stuff, like requests to fix broken bs / broken /home, etc :p
20:04:41 <misc> Anssi: we have sysadm
20:04:46 <Nanar> no maintainers list for list
20:04:53 <Nanar> for me
20:04:55 <misc> and well, we do not intend to broke nothing :p
20:04:57 <Anssi> but I agree that no reason to create another list, not yet anyway
20:05:20 <ennael> #action mageia-dev will be used for packaging
20:05:30 <t_m_b> yeah, and by using -dev people will that there are some progress...
20:05:40 <ennael> yep
20:06:10 <dmorgan> t_m_b: really nice point
20:06:22 <ennael> anything else on this?
20:06:23 <t_m_b> (and its "free learning" for all that reads it)
20:06:34 <misc> on ml, nope
20:06:42 <Nanar> maybe
20:06:58 <dmorgan> neither am i for ML
20:07:01 <Nanar> iurt was used to error mail to mainainers@
20:07:19 <Nanar> what do we do for bot's mail ?
20:07:34 <misc> KIWF
20:07:38 <misc> ( kill it with fire )
20:07:42 <ennael> :)
20:07:47 <Nanar> ok
20:07:48 <boklm> maybe we can send them to -dev, and split later if it becomes too noisy
20:08:08 <Anssi> well, I had a procmail rule forwarding them to an unmonitored mailbox :/
20:08:10 <ennael> 30 mails from dkms builds ? :)
20:08:16 <Nanar> this will bother everyone
20:08:28 <misc> sure, so we will fix the ml to not be noisy
20:08:54 <misc> no need for mail when everything goes well :/
20:08:57 <Anssi> IMO it is enough to send the rejection message to submitter (and possibly maintainer)
20:09:02 <Nanar> having a better reporting from iurt is also a valid option
20:09:15 <dmorgan> Anssi: yes i agree
20:09:20 <Nanar> Anssi: I do agree
20:09:43 <Nanar> it seems we all agree ML must not receive bot's mails
20:09:55 <boklm> it depends which bots
20:10:16 <dmorgan> Nanar: iurt errors
20:10:20 <dmorgan> sorry boklm
20:10:21 <misc> boklm: users are not bots :p
20:10:22 <Anssi> well, no youri REJECTED messages
20:10:37 <ahmad78> the [REJECTED] ones were set to "skip inbox, mark as unread"
20:10:43 <ahmad78> dkms ones were a pita
20:10:44 <ahmad78> :)
20:10:46 <misc> same as ahmad78
20:10:55 <boklm> ah, yes, [REJECTED] were annoying
20:10:57 <misc> ( and if Nanar didn't spoke of it, i would have forgotten )
20:10:59 <t_m_b> but I guess maintainer needs to get mails if the automatic dkms builds fail, so he can fix package if needed...
20:11:04 <Nanar> never took time to create the filter
20:11:34 <misc> ok so we all agree that automatic mail are bad, mkay, so we can speak of next topic ?
20:11:47 <t_m_b> yep
20:12:05 <misc> #agreed automatic mail should be reduced and do not add noise to the ml
20:12:28 <ennael> bugzilla mails on separate ML as in mdv ?
20:12:35 <misc> yup
20:12:38 <ahmad78> definitely yes
20:12:41 <misc> ( and svn-commit too )
20:12:45 <ennael> ok
20:12:49 <Nanar> can be the same
20:12:49 * boklm agrees for separate MLs for this
20:12:50 <dmorgan> ennael: agree too
20:12:57 <t_m_b> yeah for both
20:12:58 <Anssi> yep
20:13:03 <ennael> #action specific ML for bugs and svn commits
20:13:03 <Nanar> I mean one ml for svn + bugzilla
20:13:23 <ahmad78> (I have 800 unread gmail "conversations" from mdv bugzilla ATM, so about 1000+ emails)
20:13:25 <Anssi> I prefer separate ones
20:13:36 <boklm> maybe some people only want bugs and no commits
20:13:36 <t_m_b> Nanar: that would be a mess to read
20:13:45 <dmorgan> Nanar: i don't agree on this point, i prefer separate ones too
20:13:56 <ahmad78> I agree with Anssi, svn commits are a lot on their own, let alone bug mail
20:14:09 <Nanar> ok so 1 ML for bugs, one for commit
20:14:19 <misc> well, i would prefer to have relevent commit to be mailed to me directly :)
20:14:23 <boklm> and changelog mailing list, to announce updated packages ?
20:14:25 <misc> ( but that would requires some work )
20:14:27 <Nanar> I don't really care, and never really read thoses messages ;))
20:14:32 <dmorgan> boklm: yes
20:14:39 <boklm> misc: yes, also
20:14:44 <dmorgan> 3 ML  : Bugzilla, svn-commit  changelog
20:14:54 <misc> the current division seems fine, no one complained as far as I remember
20:15:34 <maat|alt> could we imagine some kind of automatic subscribing based on regexp (like .*kde.* for neoclust)
20:15:36 <maat|alt> ?
20:15:43 <ahmad78> (I usually read them all, for tips about patches and workarounds)
20:15:54 <misc> maat|alt: neoclust is not on mageia
20:15:59 <maat|alt> yep
20:16:02 <maat|alt> i know
20:16:05 <boklm> maat|alt: I don't understand what you mean
20:16:10 <Nanar> maat|alt: I'd like to this
20:16:16 <ahmad78> maat|alt: well, email filters work
20:16:18 <Anssi> one problem with mailing lists, which might be off-topic, is that stable users don't have any way of getting informed about backports etc, without subscribing to full changelog@
20:16:19 <misc> maat|alt: and .*kde.* is not a good idea, as this may match too much and not enoug packages
20:16:26 <maat|alt> but that's an obvious example
20:16:28 <Nanar> eg having a subscribed announcement based on tags
20:16:43 <misc> i would prefer to deduce this from maintainersship information
20:16:51 <Nanar> not complicated to do, but need time as everything
20:17:06 <misc> ( ie send commit on pacakge I ma listed as maintainer )
20:17:09 <Anssi> (same for contrib/updates, but as we won't likely have contrib...)
20:17:10 <Nanar> it's the 456s project on my TODO list
20:17:22 <misc> Anssi: mhh, that's one goal of mageia-app-db but that's a good remark
20:17:24 <maat|alt> well the idea is that people can define what packages they are concerned about
20:17:42 <maat|alt> soi that they receive bugs and/or commits
20:17:45 <Nanar> maybe sophie will do
20:17:50 <boklm> we had a mailing list for main/updates (security updates)
20:18:08 <boklm> maybe one too for backports ?
20:18:08 <ennael> 21:15 < Anssi> one problem with mailing lists, which might be off-topic, is that stable users don't have any way of getting informed about backports etc, without subscribing to full changelog@
20:18:13 <ennael> yep :)
20:18:17 <Nanar> (if university allow me to send hundred of mails)
20:18:28 <ennael> could interest end users
20:18:33 <misc> i think we will discuss of stable and update once we will at least have a cauldron distro ?
20:18:43 <Anssi> yeah, makes sense
20:18:50 <misc> ( ie, can we get back on topic of setting packager team first ? )
20:19:07 <maat|alt> boklm: did i make myself clearer ?
20:19:16 <boklm> maat|alt: ok
20:19:26 <ennael> next topic ?
20:19:30 <misc> yup
20:19:32 <ennael> #topic packaging policies: start from blank or reuse mandriva one
20:19:55 <misc> reuse mandriva one ?
20:20:04 <ennael> wiki pages I mean
20:20:05 <Nanar> do we have something against mandriva's one ?
20:20:07 <dmorgan> ennael: for perl, naming, etc ?
20:20:19 <dmorgan> i think mdv ones are good so we could reuse them
20:20:49 <boklm> pages from http://wiki.mandriva.com/en/Policies
20:20:58 <ennael> Nanar: not about having something against :
20:21:00 <ennael> :)
20:21:06 <ennael> just make things clear to start
20:21:10 <Anssi> no need to start from blank IMO
20:21:19 <dmorgan> i agree with Anssi
20:21:26 <misc> well, we can start with them
20:21:36 <misc> then review them, and then make them official
20:21:38 <Anssi> if there is something wrong, it can always be changed quite easily
20:21:39 <Nanar> ennael: that's the point, if nobody have something against mdv's policies, then we can use it
20:21:50 <ennael> t_m_b: agree ?
20:21:52 <misc> ( i am for example concerned with ruby policy )
20:21:52 <t_m_b> and fix the "draft" part of python and ruby..
20:22:00 <ennael> ok :)
20:22:24 <Nanar> the harder task is to find the proper way to change it later
20:22:27 <Anssi> of course, we might want to create a process for making policies official or making changes to them... or do we?
20:22:32 <misc> Anssi: +1
20:22:37 <Nanar> maybe out off topic right now
20:22:40 <ennael> yep
20:22:42 <misc> yup, too
20:22:47 <Anssi> again :p
20:22:51 <ennael> :)
20:22:56 <Anssi> but yes, not really first priority
20:23:10 <misc> just say we can think of it to make proposal later
20:23:13 <ennael> well I guess it should be read once at first at least before being imported
20:23:42 <Anssi> would be good
20:23:48 <ennael> anyway it will have to be adapted to remove mdv tags
20:24:00 <misc> yup so any volunteer on reviewing them ?
20:24:03 <Nanar> s/mdv/mga/g
20:24:10 <ennael> I will make a list of these pages. Would be nice to have one guy/page
20:24:13 <Nanar> nothing a regexp can't solve
20:24:25 <misc> ok so let's addd Nanar as reviewer
20:24:31 <ennael> will put it on wiki
20:24:54 <ennael> #action Mageia will resuse mandriva linux policies to start with
20:25:23 <ennael> #action list all policies pages on wiki and get reviewers for each
20:25:24 <ahmad78> I volunteer for that too (at least I'll read them once in my life :))
20:25:29 <rtp> resuse ? touchpad again ? :)
20:25:44 <ennael> /o\
20:25:46 <Nanar> ahmad78: :)
20:25:56 <Nanar> ennael: #undo iirc
20:26:01 <misc> nope
20:26:03 <ennael> anything to add on policies side
20:26:05 <ennael> ?
20:26:10 <misc> you can only undo the last one
20:26:12 <ennael> Nanar: undo is for last action
20:26:18 <Nanar> arg
20:26:19 <Nanar> well
20:26:30 <misc> ennael: would be good to compare our policie to the one of other distribution, see if we can find some common ground, etc
20:26:35 <Nanar> so who review policy ?
20:26:45 <misc> Nanar: everybody ?
20:26:52 <ennael> misc: yep sure
20:26:54 <misc> ( ie, 1 person per policy )
20:27:05 <ennael> will be done on wiki not tonight
20:27:12 <ennael> unless you want 3h meeting more
20:27:24 * Nanar is hungry
20:27:32 <ennael> so we agree :)
20:27:45 <ennael> #topic first planning for contributions
20:27:48 <ahmad78> (poor rabbit)
20:27:54 <ennael> all is in title
20:28:04 <ennael> can we provide a first planning for this?
20:28:12 <Nanar> I don't think so
20:28:18 <misc> not yet :/
20:28:30 <Nanar> because we need a basesystem before
20:28:39 <Nanar> and there is a lot of work to do
20:29:00 <Nanar> I am think to rpm/rpm-mdv-setup/mnb/gcc etc...
20:29:23 <misc> well, at least, we can provides a roadmap, i assume
20:29:38 <ennael> roadmap would be good to give some ideas
20:29:40 <t_m_b> well, technically rpm cleaning and importing to svn could start , but no submissions...
20:30:49 <boklm> we can also start to make the list of people who will be maintainers, who will be apprentice, who will be mentors
20:30:49 <ennael> misc: any comment on t_m_b suggestion ?
20:31:05 <ennael> yep sure, it was planned
20:31:13 <misc> ennael: nope
20:31:24 <ennael> can we start mentoring on packaging side
20:31:31 <ennael> meaning everything except bs
20:31:37 <misc> ennael: but without submission, I fear that import will not be much work
20:31:58 <misc> ie, we can import, but if we don't build, then that's almost no work :)
20:32:05 <ennael> sure
20:32:51 <ennael> ok
20:33:02 <ennael> misc, boklm : can you propose a roadmap ?
20:33:21 <misc> ennael: mhh, I doubt to be able to do it before next week
20:34:05 * boklm will be away the next days (until monday)
20:34:21 <misc> ennael: for when will you need it ?
20:34:39 <ennael> not an emergency just try to plan it
20:34:43 <ennael> next week is ok
20:34:51 <misc> ok so for the 8 ?
20:35:02 <ennael> #action packaging roadmap planned for 8th of december
20:35:03 <ennael> yep
20:35:24 <t_m_b> btw, should we do the mgasys import *.src.rpm and remove any mdv stuff from it, or unpack, clean and commit to svn ?
20:35:37 <misc> t_m_b: import to keep changelog ?
20:36:12 <t_m_b> well changelog can be committed separate too if needed...
20:36:17 <boklm> I think it's ok to import and clean after
20:36:41 <t_m_b> well, that will be easier...
20:36:41 <dmorgan> boklm: except for some rpms with mandriva in its name
20:36:57 <boklm> ah, yes
20:37:20 <boklm> renaming rpms after importing is less simple
20:37:55 <t_m_b> otoh, unpacking rpm, fixing it, doing rpmbuild -bs and import the fixed srpm would also work.
20:38:15 <dmorgan> t_m_b: i would prefer your last idea
20:38:41 <misc> we can decide to import rpm that will not cause troule and fix those that will
20:39:10 <misc> if we do not change ( and we will likely not on most of them ), there is no us to unpack
20:39:13 <misc> use
20:40:10 <t_m_b> true, I was only thinking of "problematic" rpms, but the maintainer who reviews them probably already know if they are problematic...
20:40:31 <boklm> we can make a list of all rpms with mandriva in their name
20:40:55 <t_m_b> and mandriva related stuff in them...
20:40:59 <rtp> boklm: mandriva and manbo maybe ?
20:40:59 <misc> what would we renamed them too ?
20:41:16 <ennael> mandriva => mageia ?
20:41:18 <dmorgan> mageia
20:41:27 <t_m_b> manbo -> mageia too...
20:41:28 <boklm> rtp: manbo is only in suffix I think
20:41:32 <misc> wouldn't it be the occasion to not use the distro name ?
20:41:33 <boklm> ah, maybe not
20:41:40 <boklm> misc: in some cases maybe
20:41:48 <ennael> misc: if it's all specific...
20:42:01 <rtp> boklm: you have things like rpm-manbo-setup iirc
20:42:08 <boklm> rtp: ah yes, I forgot
20:42:14 <misc> ennael: technically, everything is specific :)
20:42:31 <Nanar> there rpm-mambo-setup + rpm-mdv-setup
20:42:40 <Nanar> I do think both have to be merged
20:42:42 <misc> and if mandriva did like this, we would not have to rename everything, so we can try to think to people who will do a fork of our distro
20:42:42 <t_m_b> kernel also have the mandriva stars patch :)
20:43:00 <ennael> misc: well we speak about 3 or 4 packages
20:43:22 <Anssi> rpm-manbo-setup + rpm-mandriva-setup => rpm-setup? :)
20:43:33 <misc> ennael: weren't you the one to speak of "blank mark" some time ago too ?
20:43:35 <Nanar> rpm-mdv-setup is interally called rpm-setup iirc
20:43:55 <Nanar> notice it depend of mandriva-release
20:44:00 <rtp> t_m_b: you propose yourself to update the patch with mageia's logo ? :)
20:44:11 <boklm> for the packages that don't need their name changed, I think the changes can be done after importing
20:44:18 <Nanar> it is possible changing mandriva-release will change everything magically
20:44:21 <t_m_b> rtp: why not :)
20:45:04 <ennael> ok any other topic to propose ?
20:45:15 <misc> nothing on this topic
20:45:22 <t_m_b> distro tag
20:45:24 <boklm> about importing, do we import everything, or only what is needed while we rebuild packages one by one ?
20:45:39 <misc> boklm: only what is needed, imho
20:45:54 <Nanar> let's people do themself mass importing
20:46:04 <misc> well,
20:46:06 <t_m_b> boklm: only whats needed to get rid of some old stuff ..
20:46:13 <Nanar> (like I'll probably do for perl-Catalyst...)
20:46:14 <misc> we need to have a maintainer database
20:46:19 <Nanar> Hum
20:46:24 <boklm> ok, I agree
20:46:28 <Nanar> we have a question to reply
20:46:51 <ennael> #topic maintainer database
20:46:55 <Nanar> do we keep mdv compatibility or do we profit the change to clean things
20:47:01 <Nanar> like epoch ?
20:47:12 <misc> we promised to let people do a upgrade from mdv
20:47:17 <Nanar> ok
20:47:21 <Anssi> I think we want to keep compatibility, yes
20:47:22 <ennael> yep
20:47:29 <misc> so if we do the cleaning, we will also have to kill all people who know we promised it
20:47:30 <dmorgan> i think this is important to be compatible to at least mdv2010
20:47:31 <ennael> at least with 2010.1
20:47:36 <misc> ( another type of cleaning )
20:47:43 <ennael> :)
20:48:23 <misc> I think we should however decide of a compatibility policy, ie X years after EOL, we can clean compatibility ( Obsoletes, etc )
20:48:29 <misc> but that's a topic for later
20:48:48 <ennael> 21:46 < adamw> is there going to be an upgrade path from mdv to mageia btw?
20:48:50 <t_m_b> we remove all old mdv version checks atleast older that 2010.0 from specs
20:48:52 <ennael> 21:47 < adamw> if so i'll probably update my mdv servers to mageia when possible
20:48:57 <ennael> here is a guy to kill
20:49:33 <ennael> thanks misc
20:49:41 <ennael> so about maintainers database
20:49:55 <misc> we can 1) reuse the one written by vdanen
20:49:59 <misc> 2) let rda rewrite it
20:50:03 <ennael> han :)
20:50:06 <misc> 3) let our mad perl coder rewrite it
20:50:15 <misc> 4) a mix of the 3
20:50:17 <Nanar> 1) which language ?
20:50:24 <ennael> could we use for now the existing one
20:50:35 <ennael> and reuse database for new app later
20:50:55 <boklm> yes
20:50:59 <dmorgan> this could make us avoid to waste time now
20:51:01 <misc> yup
20:51:02 <Nanar> what is the language of 1) ?
20:51:06 <misc> Nanar: php
20:51:06 <boklm> Nanar: php
20:51:07 <ennael> php
20:51:09 <misc> Nanar: and mysql
20:51:09 <dmorgan> php
20:51:14 <Nanar> ah
20:51:21 <misc> did I mention there no tarball
20:51:24 <misc> nor documentation
20:51:28 <boklm> it's on svn
20:51:35 <misc> ( at least, we know where it is in the svn )
20:51:36 <Nanar> and it's php
20:51:42 <ahmad78> (why am I seeing a lot of php up there??)
20:51:49 <ennael> :)
20:52:06 <ennael> misc: should not be that difficult I guess
20:52:21 <Nanar> what does the app exactly ?
20:52:26 <misc> ennael: sure, but touching php make me do a anaphylactic shock
20:52:31 <ennael> :)
20:52:44 <Nanar> list maintainer, allow to take maintainer ship
20:52:47 <Nanar> else ?
20:53:00 <ennael> or let down maintainership
20:53:09 <misc> yup
20:53:13 <ahmad78> yes, that's it
20:53:17 <boklm> and youri automatically add maintainers for new packages
20:53:26 <ahmad78> also list packages depending on repo
20:53:29 <misc> by directly writing to the db, i assume
20:53:32 <Nanar> we need to be abl to change it
20:53:42 <ahmad78> (note to self, don't forget to tell them to make bugzilla recognize the SRPM name even with .src.rpm in the "RPM Package" field to auto-assign bug reports to maintainers)
20:53:50 <boklm> misc: hmm, maybe loading an http URL, I'm not sure
20:53:56 <ennael> so do we agree to start with it and think about something better later ?
20:54:10 <Nanar> ok
20:54:24 <boklm> ok
20:54:25 <t_m_b> ok
20:54:28 <ennael> or start now on specifications but at least we have something to start with
20:54:28 <Nanar> in this case, should we work on something else ?
20:54:28 <misc> ok
20:54:58 <misc> ennael: let's start with the current application, and later we will see if this can goes with others application
20:55:03 <ennael> #action use mdv maintainer database php app and start working on specifications for new app
20:55:25 <Nanar> beside this I can work on a new apps
20:55:34 <Nanar> at least start to work
20:55:39 <boklm> later we'll probably want to add ldap support, if we don't write a new app
20:55:41 <ennael> Nanar: only if find designers :)
20:55:52 <ennael> we
20:56:03 <Nanar> but we have to think to what need before woding
20:56:05 <Nanar> coding
20:56:07 <boklm> yes
20:56:13 <Nanar> ennael: catdap is not my apps
20:56:20 <misc> epoll :)
20:56:28 <ennael> see "start working on specifications for new app
20:56:29 <ennael> "
20:56:39 <ennael> not code on new app :)
20:56:43 <Nanar> misc: because you touched it
20:56:58 <ennael> ok
20:57:08 <ennael> other topics ?
20:57:23 <misc> nope
20:57:32 <dmorgan> i think we spoke of all
20:57:35 <t_m_b> rpm tag for first release
20:57:36 <ennael> comments ?
20:57:57 <Nanar> t_m_b: ie ?
20:57:57 <t_m_b> I'm not sure I like the mga_0 idea...
20:58:16 <misc> t_m_b: the 0, or the _ ?
20:58:21 <ennael> #topic rpm tag
20:58:31 <Nanar> do we really want to have mga in rpm's release tag ?
20:58:37 <t_m_b> the both...
20:59:13 <t_m_b> people usually dont like version 0
20:59:27 <misc> then start at 1 :)
20:59:30 <dmorgan> Nanar: yes i think this is better for users to know for which distro is done the rpm
20:59:31 <boklm> Nanar: why not ?
20:59:48 <dmorgan> misc: yes 1 for start is better for normal people
20:59:53 <Nanar> was just a question
20:59:56 <misc> pascal coders...
21:00:07 <t_m_b> and the _ hurts my eyes, but maybe thats just me...
21:00:13 <ennael> :)
21:00:19 <Nanar> mga1 ?
21:00:23 <misc> t_m_b: then why do you have so many _ in your nick :) ?
21:00:29 <Nanar> then mga2, mga3... etc
21:00:40 <t_m_b> misc: since tmb was taken :)
21:00:48 <ahmad78> misc: to make is share his pain?
21:00:51 <ahmad78> us
21:00:56 <t_m_b> (I now got it, but back then...)
21:00:57 <ennael> :)
21:01:03 <dmorgan> Nanar: mga1, ... seems nice
21:01:30 <Nanar> will we have subrelease (1.1, 1.2) ?
21:02:02 <misc> mga.1 ?
21:02:15 <Nanar> I rather mean mga1.0, mga1.1
21:02:26 <t_m_b> If we skip subrelease we will catch opensuse fast...
21:02:28 <t_m_b> :)
21:02:33 <ennael> :)
21:02:38 <misc> what about doing like latex
21:02:44 <boklm> 3.14.... ?
21:02:46 <Nanar> ie ?
21:02:55 <boklm> Nanar: using Pi as release number
21:03:08 <boklm> (adding one number for each release)
21:03:26 <Nanar> may I suggest "no"
21:03:29 <ennael> so...
21:03:41 <misc> we can do a vote
21:03:44 <Nanar> or taking the magic number
21:03:46 <misc> so we can test epoll
21:03:56 <misc> ( because yesterday attempt showed a bug )
21:03:59 <t_m_b> what does others think ?
21:04:07 <t_m_b> * you
21:04:18 <boklm> we don't know Mageia release numbers yet
21:04:22 * misc prefer a separation between number and prefix
21:04:24 <dmorgan> maybe we can't avoid doing hard things, mga1 was simple
21:04:25 <Nanar> mga1, mga2, mga3 seems ok for me
21:04:45 <Nanar> the exception is if we do fixed release
21:04:50 <ennael> same as misc
21:04:56 <Nanar> for which 1.1 has more sense
21:05:21 <dmorgan> yes same as Nanar
21:05:41 <Nanar> no fixed release 1, 2, 3
21:05:49 <Nanar> otherwise 1.0 2.0 3.0
21:06:13 <boklm> misc: separation between package release number, mga, and mageia version number ?
21:06:50 <Nanar> so somthing like: rpm-5.0.1-1mga1.i586.rpm
21:06:54 <misc> boklm: yeah, a -, a ., a _ between mga and the number
21:07:14 <Nanar> (a message were sent in the example)
21:07:24 <misc> but on the other hand, that doesn't shok me on fedora or mandriva, so I may be wrong
21:07:35 <t_m_b> iirc rpm does not like -
21:07:36 <Nanar> '-' is denied in version/release tag
21:07:48 <ahmad78> .
21:08:01 <ahmad78> looks good here: ftp://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/13/Everything/x86_64/os/Packages/
21:08:03 <ahmad78> :)
21:08:03 <misc> let's go for $prefix$version
21:08:23 <Nanar> hum
21:08:25 <Nanar> no sure
21:08:27 <boklm> something like packagename-3.3-1.mga.1.i586.rpm ?
21:08:40 <Nanar> a simple '.' split the number
21:09:01 <Nanar> 1.mga1
21:09:11 <misc> maybe that's because it is hard to find the 1 when reading mga1 vs mga.1, as this is important number ( ie, we need to tokenize visually the name of the rpm )
21:09:13 <ahmad78> packagename-3.3-1.mga1.i586.rpm
21:09:34 <Nanar> misc: buy glasses
21:10:30 <ennael> misc: I guess I had same reaction
21:10:36 <ennael> now checking mdv...
21:10:51 <ennael> packagename-3.3-1.mga1.i586.rpm looks  ok
21:10:56 <ennael> we could start at 100
21:10:58 <ennael> :)
21:12:15 <Nanar> fine for me
21:12:16 <Anssi> I agree . looks nice there
21:12:25 <misc> ok
21:12:44 <misc> and if this is not ok, we will fix in 10 yeas, next time we fork again the distro
21:12:50 <boklm> ok for packagename-3.3-1.mga1.i586.rpm
21:12:53 <ennael> #action tag distro will be mga%[tagdistro}
21:12:54 <t_m_b> yeah, I think thats ok
21:13:02 <boklm> ennael: #info ?
21:13:03 <ennael> misc: sure :)
21:13:08 <ennael> yep
21:13:10 <ennael> #undo
21:13:10 <Inigo_Montoya> Removing item from minutes: <MeetBot.items.Action object at 0x85727cc>
21:13:10 <Nanar> ennael: .mga%{tagdistro}
21:13:21 <Nanar> ennael: notice the dot
21:13:24 <ennael> #info tag distro will be .mga%[tagdistro}
21:13:39 <boklm> %{releasenum}.mga%{distroversion}
21:13:51 <ennael> boklm: do it yourself :)
21:13:57 <boklm> I think I'm not chair
21:14:07 <misc> you can do #info without being chair
21:14:12 <boklm> ah ok
21:14:13 <misc> you can't change the topic
21:14:17 <boklm> #undo
21:14:18 <ahmad78> we will have that working automatically anyway by the rpm macros :)
21:14:33 <ennael> boklm: ahah does not work :)
21:14:36 <ennael> #undo
21:14:36 <Inigo_Montoya> Removing item from minutes: <MeetBot.items.Info object at 0x852deac>
21:14:49 <ennael> #info tag distro will be %{releasenum}.mga%[tagdistro}
21:14:59 <boklm> :)
21:15:14 <ennael> nearly 2h :)
21:15:29 <ennael> any other comments ?
21:15:29 <Nanar> and I am hungry
21:15:35 <misc> nope
21:15:39 <t_m_b> nope
21:15:53 <ennael> #endmeeting