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